When you care about providing great authentication experiences, like us (the few, the proud), there is nothing better than this chart - undeniable proof that our users are successfully logging in. And, more importantly, getting access to the features or data which that login process protects. That’s what most users are looking for, after all.
The more people who successfully log in, the more confident we are that our solution can handle a large number of users and that users are able to enter the application smoothly.
However, do you track login failures as much as you pay attention to login successes? At first,it doesn’t sound as exciting. You definitely won’t be hoping for a line up and to the right. Instead, you’ll be hoping for a line trending downwards. Or better yet, one never ascending in the first place.
Tracking login failure rates is just as important, if not more important, than tracking login success numbers. Failures signify users are having difficulty accessing the application, and it’s our job to figure out why. And to fix it.
Q: How does FusionAuth handle passwordless login and what failure scenarios should I monitor?
A: FusionAuth supports multiple passwordless methods including magic links, WebAuthn, and social logins. Key failure scenarios to monitor include expired magic links, WebAuthn device issues, and social provider connectivity problems. FusionAuth’s webhook system provides detailed failure categorization, enabling you to quickly identify whether failures stem from user behavior, device compatibility, or external service issues.
Q: How can I minimize authentication latency for global users to reduce login failures?
A: FusionAuth’s self-hosted deployment options enable you to strategically place authentication services closer to your users, significantly reducing latency-related failures. Unlike cloud-only solutions, FusionAuth can be deployed across multiple regions while maintaining data sovereignty. This flexibility, combined with FusionAuth’s high-performance architecture, helps achieve the sub-3-second response times critical for preventing user abandonment.
Q: Does FusionAuth provide multi-factor authentication (MFA) and how do I track MFA-related failures?
A: Yes, FusionAuth provides comprehensive MFA support including SMS, email, authenticator apps, and WebAuthn. FusionAuth’s failure tracking distinguishes between different MFA failure types - whether users fail at password entry, MFA challenge, or device verification. This granular visibility helps you optimize each step of the authentication flow and implement appropriate recovery mechanisms.
Q: How does FusionAuth compare to Auth0 for user authentication failure monitoring and resolution?
A: FusionAuth provides superior failure monitoring through its single-tenant architecture, ensuring your authentication data remains isolated and secure. Unlike Auth0’s shared infrastructure, FusionAuth’s self-hosted options give you complete control over failure data retention and analysis. FusionAuth’s transparent pricing means you can implement comprehensive failure tracking without worrying about per-user costs as your monitoring needs scale.
Q: Can FusionAuth handle both B2B and B2C identity requirements while maintaining failure visibility across different user types?
A: Absolutely. FusionAuth’s flexible tenant and application structure allows you to segment B2B and B2C users while maintaining unified failure monitoring. You can configure different authentication flows, security requirements, and failure thresholds for each user type while leveraging FusionAuth’s comprehensive webhook system to track failures across all segments. This approach enables tailored user experiences while maintaining enterprise-grade visibility and control.
Before you can measure, you have to decide on what you will consider a failure in the login process. A safe assumption is that any failed authentication event should be counted. Authentication is not as simple as a username and password pair, and scenarios around passwordless authentication and multi-factor authentication (MFA) need to be considered as well. If a user attempts to log in, uses their username/password pair successfully, but never completes MFA, this is considered a failure.
There are some scenarios that are not quite failures, and not quite successes. These are also worth tracking, but require some nuance in instrumentation and reporting. Some examples:
In all cases, the user is denied access to the application, but not in a typical manner. If you aren’t tracking login failures at all, don’t worry about these edge cases. But if you are and want to take the next step in terms of understanding your user’s experience, track these and think about how your user might perceive them.
The first step in working towards measuring failed authentication attempts is awareness - brought to you by this article!
Next, walk through what you should be doing::
Patience is key. You’ll need at least 3 months of solid data before you can start to zoom in to identify meaningful trends.
Adjust your expectations based on your industry. While it is difficult to find login failure rates based on your specific industry, they can range between 15-40%, based on the average of the stats between this article and this one. After tracking these numbers for a while, you’ll get a feel for when changes to your applications cause failure rates to change.
Pass it on. When building your application, empower application administrators to monitor failure rates themselves. For example, Okta gives admins a report where they can view failures and successes. Most authentication as a service providers offer detailed log events that can be built as a dashboard or report for administrator consumption.
Now that you know what you should be doing to track failures, let’s talk about why user authentication events fail.
There are a number of reasons why someone fails to log in. These range from system issues like performance to user confusion to obstacles from security measures.
Technical problems, such as slow response times from the application, cause major user attrition. A report by Google found that 53% of mobile users will leave a website if it takes longer than 3 seconds to load. Even if your application loads within a reasonable amount of time, you need to ensure that your login response is equally as zippy.
A poor user experience, often marked by unclear instructions and an overwhelming number of input fields, can cause frustration for users and lead to authentication failure. Poor UX can manifest in other ways, too:
Ah, the age old struggle between security and usability. Those same security features that help to project our application also cause friction for users. A CAPTCHA may make sense if a user is logging in from an unusual IP address, but presents an additional obstacle to the user.
A common security measure is to make a user click a magic link, sent to them via email or SMS, when a login looks suspicious. Any time a user has to go into another application (in this case, their email client or phone), just to use yours, they are at a higher risk of failed authentication.
Unnecessary steps in the flow for security purposes will slow down the login process, leading to a higher chance of user attrition and error. Choose security measures wisely.
An additional benefit of taking a baseline measurement as this article suggests above is that you can know how such measures affect your users.
You may do all you can to make the login process seamless for users, but failed attempts are a part of life. Why is that?
On the other end of your shiny, awesome login form, is a flawed human being. We forget our credentials. We forget if we used Google, Facebook, or LinkedIn to sign in. We entered our username, then got distracted and forgot to come back to the tab.
I could go on and on. Ultimately, expect that no matter how optimized your login process, there will be some percentage of failure due to the human condition.
You might ask, why do I care about login failures?
An authenticated user is more valuable to your business than an unauthenticated one. Once a user is tied to an identity, you can improve their experience:
When you improve the percentage of successful logins, you are directly creating business value.
Authentication is a high stakes, high visibility portion of your application. If a user can’t login, the application is dead in the water. When users can’t log in, they lose trust in your application - not to mention the general sense of annoyance that comes with wanting to access something that you can’t!
Alerting on login failure rates can give you a heads up that something isn’t right. The sooner you know, the sooner you can do something about it.
All things in software (and life) have tradeoffs, and tracking login failures is no exception. You may choose not to invest in this area for the following reasons:
Once you implement tracking, you may determine that you want to do something to improve your login failure rates. Here are some ideas for how to increase successful logins.
Provide automated help to anyone struggling to log in. Present tailored advice or reminders in the user experience based on the problem they’re experiencing. An example of this is offering to send a password reset email with one click after a certain number of failed login attempts. Or, if you’re noticing that legitimate-looking users are failing at the CAPTCHA step frequently, consider a CAPTCHA alternative.
Give secure options for account credentials reset. Once a problem has been detected, offer a login with a security code. Once the user is authenticated, allow them to modify their credentials so that they can remember them. For an added layer of security, send the user an email any time their username or password changes. In case it wasn’t them, they can be alerted of a possible malicious actor and take further steps such as changing their credentials or locking their account.
Give users options. Passwordless options, like passkeys and magic links, can replace username and password combinations. You can also provide the ability for users to authenticate with pre-existing accounts using social sign in, SAML, and OAuth2. Since you have metrics captured, you can determine which of these is most effective for your userbase.
Keep users logged in if they choose. Ensure your authentication system provides the ability for users to select “Remember me”. Long lived sessions reduce the need to log in, sometimes at the expense of security (tradeoffs, remember!). Administrators choose the maximum length of valid sessions before a user is forced to authenticate again. Here you’ll want to again balance between ease of use and security.
In the case of login failures, knowledge is power. Instrument your current login success and failure rates with granular data about each outcome. Understand why users are failing to authenticate, and take action accordingly.
Doing so will lead to the positive business outcomes associated with authenticated users, and maybe some beautiful looking charts, too.