Passkey Fallback & Recovery: Identifier-First Approach

Passkeys have grown to a real alternative to traditional authentication methods, with passkey-ready devices being nearly 95%. However, even the most advanced systems require effective fallback and recovery strategies to address scenarios where passkeys are not accessible (Fallback) or are even lost (Recovery). This guide aims to explore the various scenarios where fallbacks and recoveries are necessary and discuss how possible solutions look like.

When thinking about fallback & recovery methods, it’s important that the strength of those match that of the primary authentication method. This guide will distinguish between different usages of passkeys, particularly focusing on contexts where passkey are used as self-contained MFA, to tailor fallback and recovery methods appropriately.

Key Questions:

• Which Fallback Scenarios Exist? What are the potential fallback scenarios that could occur with passkey systems, and how should they be handled to maintain security?
• How Should Recovery Be Handled? Depending on the usage patterns of passkeys, particularly in environments using MFA, how should recovery processes be designed to ensure they secure?

Through the exploration of these questions, this guide will provide product managers and developers with the necessary insights to design, implement, and manage passkey systems effectively, ensuring that security does not come at the expense of user experience.

Before diving into fallback and recovery strategies, it's important to establish a clear understanding of some foundational terms we will use.

In most business and consumer systems, authentication relies on three primary identifiers: email, phone number, and username.

The vast majority of systems use email as the primary identifier, particularly in web-based applications. Mobile-first or app-first platforms, however, often prefer to use the phone number as an identifier due to the ease of pre-filling an SMS-based OTP (One-Time Passcode), which can be automatically inserted. In some cases, users may also be required to set up a username in addition to these identifiers, primarily for platforms that require a unique display name. There is also a growing trend, especially on larger platforms, to allow the use of both email and phone number for added flexibility.

During initial sign-up, these identifiers are typically verified either via a confirmation link / OTP (for email) or an OTP (for phone number), ensuring that the identifier belongs to the correct person. In the event that access is lost, proving control over the previously verified email or phone number is usually sufficient to restore account access. Since these identifiers are the most reliable forms of communication with users, phone numbers are often collected for MFA (Multi-Factor Authentication) purposes, with SMS being a commonly used second factor.

Usernames are often employed to provide an additional layer of user identity in systems where public-facing identifiers are required, such as social media, forums, or certain professional platforms. While they do not serve the same functional role in authentication as email or phone numbers, usernames provide users with a recognizable identity in public or peer-to-peer contexts. However, they introduce an additional complexity as users can often forget them, and in most cases, another identifier is required alongside the username. Therefore, in this article, we will not focus on usernames.

Other 2FA options, such as authenticator apps (which generate TOTP codes), do not rely on an identifier but are often more complex to set up for an average user. Passkeys have also introduced the possibility of working without an identifier (usernameless authentication), a feature becoming increasingly popular in the crypto space. However, for both consumer and business solutions, the need to communicate with users (often via email) for fallback or recovery purposes makes usernameless systems less practical.

Single Factor Authentication (SFA) systems are those that rely on one form of authentication to verify the user's identity. Commonly, this single factor is a password, but it can also be a social login, email OTP or any method that requires just one type of proof. Most systems on the web today are SFA-systems. However, there is a well known trade-off with security. When integrating passkeys, these typically serve either as an add-on or a replacement for traditional passwords, enhancing the system's convenience. It's common for such systems to still allow fallback options like email OTPs or social logins, which improves the user experience by reducing passwords but does not elevate the security of the system to beyond SFA.

Multi-Factor Authentication (MFA) involves two or more independent factors for verifying a user's identity; this is what makes it more secure than SFA. These factors can include something the user knows (password or PIN), something the user has (a security token or a mobile phone app), and something the user is (biometric verification like fingerprints or facial recognition). MFA systems are designed to protect against specific vulnerabilities that SFA systems can't defend against, such as phishing attacks or password breaches. When using passkeys within an MFA system, they are generally utilized as a self-contained MFA option. In these cases, it’s crucial that any fallback or recovery methods maintain the same level of security as passkeys.

Fallbacks are used in all systems where multiple authentication methods coexist. They are used when the primary methods are unavailable – often the user has a choice at the beginning how to sign up (e.g. social login vs. password). A fallback could involve alternative authentication strategies such as OTPs via email, passwords, social logins with matching emails, native app pushes, QR codes, or security keys. Each of these fallback methods varies in security quality, and selecting the appropriate fallback option is critical in balancing user convenience with security requirements.

In environments utilizing passkeys as part of a Multi-Factor Authentication (MFA) system, these fallback methods must be carefully considered to ensure they provide multi-factor security comparable to passkeys. Recovery processes become important when users lose access to all established authentication measures that meet the required security standards (SFA or MFA). This is less critical in single-factor systems, where multiple recovery options may be available, such as resetting a password via an email OTP, which effectively validates the user's control over an associated identifier. However, recovery is particularly challenging in 2FA/MFA systems because these systems inherently rely on multiple factors for verification. In scenarios where a user switches mobile operating systems – e.g. iPhone to Android phone - and loses associated passkeys & the phone number - the remaining factors (e.g., just a password) can not satisfy 2FA requirements. Recovery in these instances might necessitate creating new proofs of identity, which can involve manual support requests or more innovative solutions which we will cover later.

When implementing a passkey solution, one of the first decisions to be made is the approach for passkey login. Depending on the use case, manual login might be sufficient for smaller platforms, but for larger UX-oriented companies, an Identifier-First Approach is recommended, that offers passkey login after the primary identifier (most likely email) has been entered.

On smaller platforms or platforms that do not focus on high passkey login rate, the user-initiated approach involves a separate "Sign in with passkey" button. In this approach, the responsibility for using passkeys is fully placed on the user. After adding a passkey to their account, the user must remember to click "Sign in with passkey" to log in using it.

The screenshot shows the passkey implementation of https://my.gov.au, which uses the manual passkey login approach. While this approach is easier to implement because the backend does not need to determine whether a passkey login is possible, it typically leads to much lower passkey login rates. This is because it relies heavily on user initiative, and consumers might not remember or be sure on which platform or cloud storage their passkeys reside. This approach makes the user think. Lets take a look what possible fallback opportunities exist with this approach in the next section.

Fallbacks are essential in any system where there are possibilities of failed passkey access. In the manual passkey login approach, dialoges and fallbacks cannot be managed individually because all login options are display at the same time and passkeys are chosen at the user discretion. This leads to several challenges:

• Unintuitive Errors: The error messages users encounter when passkeys are unavailable or incorrectly set up are often unclear and can cause confusion. Users might not understand why they are unable to use the passkey or what went wrong, leading to frustration.
• Dead Ends: Users may find themselves at dead ends where they cannot proceed. If passkeys are missing or inaccessible, users may not be given any clear guidance on how to proceed or recover access, causing them to abandon the login process.
• Not Guiding: In these situations, the system cannot provide helpful instructions to guide users towards an alternative authentication method. Users are left to figure out on their own how to resolve the issue, which diminishes the user experience.

The example above shows, how confusing Windows 11 error messages are, when passkeys are not found on the platform authenticator. The system may assume that the passkey resides on a security key or another device. This process can be confusing for users who are unfamiliar with such authentication flows, particularly if they have never used a security key before or have never created a passkey.

If no passkeys are found on the platform authenticator, the operating system & browser assume they must exist elsewhere, leading to further confusion if the user has not created a passkey yet. Conditional UI can help by displaying existing passkeys, but this only helps if passkeys actually exist. For the best passkey experience, the backend should decide if a passkey login should be triggered after the user has provided their primary identifier.

In the identifier-first approach, users are prompted to provide their primary identifier, such as an email or phone number, before the system determines whether a passkey login is possible. After the identifier is verified, the system automatically suggests the most appropriate login method, including passkeys if they are available & accessible. This approach is more user-friendly because it eliminates the need for users to remember to select the "Sign in with passkey" option and enhances the adoption rate by streamlining the process.

Google Identifier-First Sign-In

Google Passkey Sign-In

The above screenshots show the login behavior of a Google login for an account where a passkey is associated on a macOS device. Google also follows the Identifier-First approach and determined that passkey login will very likely be possible:

1. Passkey platform support: The underlying platform supports a platform authenticator therefore a login can be possible.
2. Passkey is accessible: The passkey will very likely be accessible on this client (macOS) because it was created on a macOS system.

Consequently, a passkey login is automatically started, guiding the user to the best experience possible. This follows the "don't make me think" strategy.

The system determines whether a passkey login is possible. In case:

• No passkey exists: The user has not created a passkey yet for his account
• Passkeys are not accessible: The passkeys the user has created are very likely not available on this Client (for example user only has a MacOS Passkey and now loggs in from Windows).
• Passkey authentication not supported: The current client does not support platform authenticators and is also very unlikely to support Cross-Device-Authentication via QR Code

the decision will be that a successful passkey login is unlikely and therefore the fallback options will be provided automatically without triggering a passkey login. This approach is much more user-friendly because it eliminates the need for users to remember to select the "Sign in with passkey" option, enhances the adoption rate by streamlining the process, and avoids the worst-case scenario where a confusing dead end is shown to the user.

In the example above, the login falls back to a password and will then continue to ask for further authentication factors based on the status and security of the account, because the client is a Windows 11 device, which is unlikely to have access to the macOS passkeys. Depending on the security requirements of your authentication system, you have full control over which authentication method to trigger in such a case (e.g., the last successful non-passkey authentication option).

When a user encounters an authentication screen during a web login, they may be surprised or overwhelmed, especially if it is one of their first times using passkey-based authentication. This can lead to users aborting the authentication process, not due to a failure, but simply because they are unsure about what is happening. It is crucial to plan for this behavior and treat the first abort as a normal event rather than an error:

The first abort screen should clearly explain what is happening in a calm and reassuring way, recommending that the user retry the process (see Google example above). This screen should be designed to minimize anxiety, treating the abort as a regular, expected part of the user experience. Many users might abort simply because they did not recognize the authentication screen or were unfamiliar with the process. Therefore, a retry should be the default suggestion.

If a second abort occurs, however, the situation should be treated differently. The second abort could indicate that something has genuinely gone wrong - whether it's an issue with the platform authenticator, the user being unable to find an appropriate passkey, or a technical failure in the WebAuthn ceremony. At this point, the system should present a different screen explaining that an issue has occurred and suggesting fallback options a bit more:

The second abort screen should encourage the user to switch to an alternative authentication method. It should ensure user can still successfully log in without causing further frustration. As we can see on the screen above, Google still suggest “Try again” but at the same time shows the user that something probably went wrong.

The following table helps to compare the different approaches by summarizing the most important characteristics:

Do-it-yourself approaches usually follow the Manual Passkey Login approach and rely on Conditional UI and the user to opt-in to passkeys, which results in very low passkey login rates and frustrated users. The Identifier-First approach requires establishing well-thought-out device logic on top of Conditional UI, which is where Corbado can help you. Building your own device logic and passkey intelligence is not recommended, as this ruleset requires constant tweaking and adjusting to new devices, new WebAuthn & cloud sync functionality (e.g. GPM passkeys).

Passkey recovery is a crucial aspect of maintaining security and user experience when users lose access to their passkeys. This is particularly important in systems that rely on MFA. In MFA cases, recovery processes must ensure that security is preserved while allowing users to regain access to their accounts. The recovery approach must be tailored based on the level of authentication used in the system.

To maintain security in SFA systems, recovery generally involves proving control over an identifier such as an email address or mobile phone number.

• Email OTP: An OTP is sent to the user's registered email address. Once verified, this allows the user to regain access and create a new passkey.
• SMS OTP: Similar to email recovery, an OTP is sent to the registered mobile phone number. The user can use this OTP to regain access to their account.

While these methods are straightforward, they rely on keeping the user's contact information up to date. Therefore, it's essential to prompt users regularly to verify their email and phone number during routine logins.

In Multi-Factor Authentication systems, recovery becomes more complex. Since MFA relies on multiple independent factors (e.g., passkeys, social login, and OTPs), users should not lose access just because one factor (like a passkey) is unavailable.

• Using alternate factors: If the passkey is lost, the user can authenticate using two other factors, such as a password + SMS OTP or an authenticator app. Once they are authenticated, they can create a new passkey.
• Using other passkeys: In case the user has other devices with passkeys, they could use those to regain access with apropriate hints (e.g. requesting the use of a passkey from an iPhone).
• Create new passkeys: After authenticating with the recovery method, the user should be guided to crate a new passkey to ensure the MFA setup remains intact.

For both SFA and MFA systems, the key is ensuring that recovery processes are robust and secure while minimizing friction for the user.

It is important to keep in mind that because passkeys are synchronized in the cloud, the MFA recovery costs are much lower over a period of 36 months, as changing the mobile phone number is much more frequent than switching from Apple to Android or vice versa. In the event of a phone of phone contract change passkeys will be restored.

Therefore, losing access to synced passkeys will happen less frequently than losing access to the mobile number, which causes most of the recovery pain for traditional consumer-oriented MFA systems.

Nevertheless with growing user base such cases still cause significant manual support costs and should be handeled with a digital solution, which we will take a look at in the next section.

In systems handling sensitive personal data, regulated industries, or government services, standard email OTP and mobile number OTP may not always be sufficient or available for recovery. In such cases, smart MFA recovery mechanisms offer advanced methods for account recovery that maintain high security standards while offering users a seamless experience.

One of the most effective methods is selfie identification with a liveness check. This process involves the user taking taking photos of their ID. In addition, a selfie liveness check ensures that the selfie is being taken in real time, confirming that the user is physically present & matches with the phographed ID therefore preventing fraud using static images or stolen IDs. Depending on the technology used, a liveness check is either done by recording a short video in which the distance is changed to the camera or the head is turned by 180 degress (e.g. Apple Face ID).

This method can be particularly useful when traditional recovery methods such as email or SMS OTPs are unavailable or outdated also. For example, here is an example of taking a selfie which is then followed by a liveness check from onfido:

Example: Selfie Ident with liveness check from onfido

• Government systems, regulated industies or big commercial services have personal data available that can be used to verify information available on the ID. In case e.g. birthdate is not available the information gathered via the ID can be used as an factor in the manual recovery process.

Additionally, other smart recovery methods can include:

• Cross-device recovery: If a user has a trusted secondary device, they can recover their account by scanning a QR code.
• Known environments: Users who have still access to the same device they had successfully used in the past, can use provide additional ensuring factors by using this device and therefore providing proof that they are actine from the same device, provider and location to help the manual recovery process. A approach Google uses for Gmail Account Recovery.

Smart MFA recovery methods aim to offer users secure, intuitive ways to regain access to their accounts, especially when dealing with highly sensitive or regulated information. These approaches ensure that even in cases where traditional methods like email or phone recovery are not available, users can still restore their access securely and efficiently. Smart recovery helps to drive down costs of MFA recovery.

It is important to keep in mind that because passkeys are synchronized in the cloud, the MFA recovery costs are much lower over a period of 36 months, as changing the mobile phone number is much more frequent than switching from Apple to Android or vice versa. In the event of a phone of phone contract change passkeys will be restored.

Therefore, losing access to synced passkeys will happen less frequently than losing access to the mobile number, which causes most of the recovery pain for traditional consumer-oriented MFA systems.

Nevertheless with growing user base such cases still cause significant manual support costs and should be handeled with a digital solution, which we will take a look at in the next section.

When integrating passkeys into your authentication system, it’s crucial to carefully plan both fallback options and recovery strategies to maintain a high level of security while ensuring a seamless user experience. To maximize the login rate of passkey login, consider the following recommendations:

• Opt for the Identifier-First Approach: This approach is more user-friendly and reduces friction in the login process. By asking users to input their primary identifier first (e.g., email or phone number), the system can automatically determine if a passkey login is possible. This ensures a smooth, intuitive login experience without relying on the user to manually choose a passkey option.
• Use explatory Abort Screens for better User Experience: While security should be the top priority, it’s essential to design a process that helps the user adopt passkeys. Ensure that first-time ceremony aborts are treated as normal, and give clear guidance to retry.
• Keep Fallback and Recovery Options Secure: Ensure that fallback methods (such as email OTP and/or SMS OTP) match the security level of the primary authentication method. For example, in an MFA system that uses passkeys, the fallback should also require multiple factors to maintain the same security standard.
• Automate Regular Recovery Prompts: Regularly prompt users to verify their contact information (email address or phone number) during login to ensure that recovery options remain up to date when they use passkeys. This reduces the chances of users being locked out of their accounts due to outdated recovery methods.
• Consider Smart Recovery Methods for Enhanced Security and Reduced Support Recovery Costs: For regulated industries or systems having access to personal data to check against online identification, consider advanced recovery methods like selfie identification with liveness checks. This method can provide additional layers of security while keeping the recovery process intuitive and user-friendly depending on your security requirements.

Maximizing passkey login rate depends on how well you implement these elements. Ensuring smooth fallback and recovery options will give users confidence in using passkeys as their primary authentication method.

Corbado provides everything necessary to implement the identifier-first approach for greenfield projects that need a complete new authentication system and for existing projects that need to add passkeys to an existing authentication system.

Both products offer UI components which can be tailored to your needs:

1. Corbado Complete: Start your project with passkey-first authentication
   This is our full authentication system, which includes a seamless identifier-first approach to streamline the login process. Corbado Complete enables a secure and user-friendly experience by automatically determining whether passkey login is possible after the user provides their identifier. This reduces friction and ensures a smooth login experience, which is crucial for maximizing passkey adoption.
2. Corbado Connect: Add passkeys without migration to any app
   For businesses that already have established authentication processes and want to add passkeys as an enhancement, Corbado Connect offers an add-on solution for Single-Factor and Multi-Factor-Strategies. This approach complements your existing infrastructure by seamlessly integrating passkeys as a secure and convenient option, allowing users to authenticate via passkeys without overhauling your current system. For example, Corbado Connect can seamlessy be embedded into Amazon Cognito.

We strictly align our methods with industry leaders such as Google and other prominent players in the big tech space, especially tailored for consumer-oriented companies.

Our goal is not just to maximize passkey adoption (i.e., the creation of passkeys) but also to ensure these passkeys are actively used to drive high login rates (and therefore increase security and reduce SMS OTP costs). Our UI components are build with the Identifier-First approach in mind and are directly connected to our Passkey Intelligence, that decides about passkey availability & accessibility based on the client environment and existing passkeys. They support all discussed fallbacks and recovery functionalities. The following screens shows our abort & retry logic:

First Passkey Abort

Second Passkey Abort

By focusing on both passkey adoption and passkey usage, we help you achieve a balance between security and user experience, ensuring that users continue to engage with passkeys in a frictionless manner.

In this guide, we have explored the various fallback and recovery strategies following the integration of passkeys into an authentication system. Key questions posed in the introduction were addressed throughout:

• Which fallback scenarios exist? Several fallback scenarios can occur, such as missing passkey support or passkeys not being accessible on a particular device. To maintain security and provide a smooth UX, fallback options such as email or SMS OTP should be available when passkey login is not possible.
• How should recovery be handled? Recovery processes should be designed to match the security level of the authentication system. In SFA systems, email or SMS OTP can suffice, while in MFA systems, alternate factors must be used to regain access and create a new passkey. In highly regulated or sensitive environments, smart recovery methods such as selfie identification with liveness checks provide additional security.

By following the best practices outlined in this guide, product managers and developers can design robust passkey-based authentication systems that provide users with a secure yet seamless login experience. Security does not have to come at the cost of user experience - both can be achieved with thoughtful design and planning.