We have already discussed optimizing passkey creation flows, the critical first step toward successful passkey adoption. However, after creation, ensuring users consistently choose passkeys as their preferred login method is essential. In this article, we shift our focus to improving passkey login rates - the key to achieving meaningful passkey adoption in practice. Specifically, we will answer the following questions:

• What are the best practices for optimizing passkey login rates?
• How can enterprises effectively encourage consistent passkey usage at scale?

You’ll learn proven strategies and practical approaches tailored to enterprise environments, enabling your organization to successfully transition users from passwords to passkeys. While our previous article addressed passkey creation and initial enrollment, this article specifically targets strategies designed to optimize ongoing passkey usage, ensuring that passkeys become the primary authentication method for your users over time.

Achieving high passkey enrollment is only one piece of the puzzle; the passkey login rate - the proportion of total sign-ins that occur via passkeys rather than fallback methods offers the most accurate reflection of true passkey usage. A system that generates passkey registrations but fails to see those passkeys used in everyday authentication falls short of delivering the promised security and convenience benefits. Below are key considerations for understanding why usage is just as critical as creation:

While new passkey registrations matter, organizations should measure adoption success by how many logins actually happen via passkeys. A high passkey usage / passkey login rate percentage correlates directly with fewer password resets, lower OTP costs, and improved user satisfaction.

Even if a platform reports hundreds of thousands or millions of passkey credentials, these raw numbers don’t necessarily translate into strong day-to-day passkey activity. The core metric is passkey login rate which is the share of total signins with passkeys.

Each passkey login workflow, whether it’s auto-launching the passkey prompt (identifier-first) or offering a separate passkey button, can significantly impact user uptake. Some flows demand more effort to drive up the passkey login rate.

While the initial user journey (prompting, messaging, ceremony design) is important for passkey enrollment, maintaining momentum requires carefully optimized post-enrollment flows. It’s not enough to have passkeys “on file” - continuous nudges, device coverage reminders, and a frictionless login experience are necessary to keep usage levels high, but the most important factor is to push for login with passkeys conveniently.

Many solution providers quote impressive creation or “undefined adoption numbers”, but the key question is how efficiently their systems convert new passkey enrollments into everyday passkey logins. In some cases, absolute usage volume can be high due to a large user base, but the percentage of total logins attributed to passkeys remains low. In this article, we’ll highlight the critical strategies to ensure your passkey login flows translate into genuine, ongoing passkey utilization as preparation go compeltely passwordless.

In short, boosting the passkey login rate is what ultimately is the success of any passkey project. By applying well-planned login flows, consistent user reminders, and careful fallback management, enterprises can elevate passkey usage to 50% and higher paving the way tp truly replace passwords and experience the benefits of a passwordless ecosystem.

Before diving into best practices for optimizing passkey login adoption, it's important to briefly outline the different technical approaches available for integrating passkey-based authentication into your login flows. Each method has distinct strengths and considerations that influence overall adoption rates, user experience, and security effectiveness. Understanding these options sets the stage for effectively applying best practices tailored to your specific use case.

Conditional UI allows an existing passkey to be automatically suggested during the login prompt, significantly reducing friction, particularly on mobile platforms. This approach leverages native platform capabilities, enhancing user experience by minimizing the steps required to initiate passkey-based authentication. However, it has limitations, especially when multiple accounts are associated with the same platform. Users might encounter confusion about which account the offered passkey belongs to, potentially causing hesitation or aborted logins. Additionally, while conditional UI integrates smoothly with password managers, it isn't universally adopted. Users may abort conditional UI prompts to manually verify credentials, indicating the need for additional clarity or assurance in the login flow. Conditional UI is not a standalone authentication mechanism it is considered an addon and must be combined with the Automatic Login with Passkeys or the Passkey Button Approach.

In identifier-first flows, users enter their identifier (such as email or username) and, if a valid passkey is available, the login process initiates automatically. We’ll refer to this method also as automatic triggering. This method significantly reduces friction, making login nearly effortless for users with a registered passkey accessible on their current device. However, implementation complexity arises when determining passkey availability across different devices and browsers, as the WebAuthn standard does not directly support passkey detection on the web. Consequently, providers often simplify detection mechanisms or prompt users every time, causing user frustration when confronted with inaccessible options such as unnecessary QR codes, especially problematic for use-cases where users have multiple devices and combination of mobile devices, private & work notebooks and family devices. A full dedicated article to Identifier-First Flows can be found here.

The passkey button approach involves providing a dedicated, separate button beneath traditional login methods, explicitly prompting users to manually initiate passkey authentication. This method effectively addresses account enumeration concerns because authentication ceremonies proceed only if a valid passkey exists on the user’s device, thereby preventing leaks regarding account or credential existence. While straightforward and secure, the primary drawback is limited usage by consumers. Without automatically initiating passkey login, users typically default to familiar password-based methods. Enterprises adopting this approach should pair it with strategic messaging, such as prompts or banners, to direct users’ attention toward passkey usage and clearly communicate the convenience and security benefits passkeys provide. Corbado leverages Passkey Intelligence and a One-Tap passkey button to ensure high passkey login adoption, even in this scenario - but more on that later in the article.

This method integrates passkeys as an additional factor after the user has initially authenticated via password. Upon successful password entry, the user chooses between passkeys and traditional second factors like SMS or authenticator apps. The main advantage of this approach is minimal disruption to the existing login process, making it easier for enterprises to gradually introduce passkeys without requiring significant user behavior changes. However, it offers little UX improvement and keeps customers anchored to password-based authentication, thus limiting the transition towards a truly passwordless environment. Consequently, this approach is most suitable for conservative or compliance-driven scenarios where introducing passkeys gradually is preferable.

The mobile-first approach exclusively leverages synced passkeys available on mobile devices. When logging in from desktops, users typically authenticate by scanning QR codes displayed on their screens to initiate passkey creation or login via mobile. This strategy is particularly appealing to mobile-native institutions or neo-banks aiming to reduce complexity by aligning closely with their existing mobile-centric user experience. However, it significantly places responsibility on users, requiring them to consistently use their mobile device for authentication, which can introduce friction. The QR code dependency is also unintuitive for many users, potentially hindering broader adoption unless complemented by clear, supportive user guidance and education. This approach has until today only be used in smaller deployments no in large scale deployments.

Now that we’ve explored the technical approaches for integrating passkeys into login flows, let’s analyze how major organizations like Amazon, Microsoft, Google, and myGov have successfully implemented passkeys at scale. By examining these large-scale examples, we’ll identify best practices and practical insights that can guide your enterprise toward achieving high passkey adoption and a consistently high passkey login rate.

• Automatic Login with Passkeys: After users enter their email, Amazon automatically initiates a passkey flow if a valid passkey is likely available on the device. As visible in the screenshots above, initially, there is no button to start the login with a passkey; it appears later.
• User Abort Handling: When a user cancels or the passkey prompt fails, the login flow reverts to displaying a visible passkey button or a password fallback. Users can retry the passkey at any time by clicking “Use passkey” or continue with existing password flows if truly necessary.
• Conditional UI: All screens support autofill and Conditional UI, but as we’ve observed, some users skip autofill and manually enter their identifier instead.

• Defaulting to Passkey: Once a user enters their email, Microsoft checks if a passkey is stored for that platform. If likely available, the system automatically prompts for a passkey - auto-triggering the WebAuthn ceremony (automatic login).
• Aborted Flow & Password Backup: If a user aborts the passkey prompt or doesn’t have a valid passkey on that device, the system does not transmit to a fallback automatically it shows the passkey error page where additional options can be used.
• Conditional UI: On live.com, Microsoft currently does not implement Conditional UI, likely due to the complexities associated with Conditional Access within the underlying Entra system.

• Automatic Login with Passkeys: After users enter their email, Google also automatically initiates a passkey flow if a valid passkey is likely available on the device. The automatic login is not triggered in all relevant cases, QR code login is avoided.
• User Abort Handling: When a user cancels or the passkey prompt fails, the login flow reverts to an informational error page that nudges the user to retry the login. Users can retry the passkey only after the second abort, at which point Google enhances the error messaging and includes a short survey. We have dedicated an entire article to the best fallback mechanisms.

• Conditional UI: All screens now support Conditional UI, although Google initially launched without it.

• Separate Passkey Button: The login screen features a discrete “Sign in with passkey”. While simple to implement, this approach relies on users noticing and choosing the passkey option. Recently moved passkey login option up to increase user awareness.
• Turning Off Passwords: After creating a passkey, users can disable passwords entirely a big security advantage. However, the login flow defaults to SMS OTP if passkeys aren’t explicitly triggered and can cause confusion.
• No Conditional UI: myGov does not currently leverage passkey autofill (conditional UI) on its web or native apps, missing out on the frictionless “one-click” sign-in experience for passkey-ready devices, which is especially important when employing the Passkey Button approach. We also have a full analysis for the myGov Passkey Implementation.

Below is a concise comparison of how Amazon, Microsoft, Google and myGov structure their passkey login flows, focusing on whether they autotrigger passkeys (automatic login) or rely on a separate passkey button, the intelligence used to check credential availability, whether an extra factor is applied, support for Conditional UI, and the overall level of passkey adoption each approach achieves.

Takeaways

1. Automatic Passkey Logins Increase Adoption
   Amazon, Microsoft and Google confirm that once the user has typed an identifier, automatically prompting for a passkey yields higher passkey login rates - especially on mobile. myGov, by contrast, sticks to a separate passkey button, reducing daily passkey usage. This probably due to a more conservative approach to Account Enumeration.
2. Fallback Handling
   All solutions revert to fallback options if the passkey prompt fails or is aborted, but details vary (e.g., Amazon provides a clear passkey button; Microsoft shows an error page). This fallback logic must remain intuitive to maintain user trust.
3. Conditional UI
   Google & Amazon uses Conditional UI to reduce friction by automatically suggesting passkeys. Microsoft does not implement it due to internal Entra complexities. myGov does not incorporate any passkey autofill UI.
4. Impact on MFA Requirements
   All examples exept Amazon rely on passkeys as self-contained MFA factor. The only other large company going down treating Passkeys as single factor was Paypal but has changed course in the USA due to much lower fraud rates with passkeys. Although in their case they did not treat it as replacement for the first factor (password) but as replacement for the second factory (SMS OTP).
5. Adoption Results
   Amazon, Microsoft and Google each exhibit high passkey login rates. myGov’s usage lags behind, hindered by a discrete passkey button without automatic passkey login.

By combining automatic detection, fallback intelligence, and optional conditional UI, Amazon, Microsoft, and Google demonstrate how to consistently push passkeys as the primary login method. Meanwhile, myGov offers a cautionary example of how a simpler security-first button-based approach could look like.

When integrating passkeys into your login flows, two primary options stand out for day‑to‑day authentication: automatic login (an identifier‑first approach) and a dedicated, separate passkey button. Each method offers distinct advantages, trade‑offs, and user experiences. After implementing successful passkey enrollment flows, the next step is to ensure users sign in with passkeys rather than defaulting to fallback credentials. Below, we explore both approaches in more detail before introducing Corbado’s One‑Tap solution.

Users enter their identifier (e.g., email or username), and if the system detects that a valid passkey is likely available on this device or platform, it automatically initiates the passkey flow. Instead of requiring manual selection (e.g., “Click here to use a passkey”), the user is smoothly guided to sign in with biometrics (or a PIN) if the passkey is available and accessible.

Advantages

1. Seamless SignIn: Automatic login drastically reduces the friction of passkey use - users simply type their email, and a passkey prompt appears.
2. High Passkey Login Rate: Because passkey usage is the default when available, the daily share of logins via passkeys tends to be high (50% - 80% or more).
3. Reduced SMS OTP Costs: By encouraging passkey usage for daytoday authentication, reliance on costly SMS or email OTPs diminishes, saving operational costs.

Challenges

• Complexity of Detection: Determining whether a passkey truly exists for a given user on a specific device can is complex because WebAuthn does not directly provide passkey availability checks. Many solutions revert to always attempting an auto flow, which can cause confusion if the user does not actually have a passkey on this device leading to dead ends in operating system prompts:

• Account Enumeration Risks: By requesting the user’s identifier first, you must mitigate the risk of revealing whether that email is registered or not. Implementing bot detection, ratelimiting, and consistent “errorhandling” messages helps address this.

Overall, an identifier-first flow that automatically attempts a passkey signin is the single biggest driver of high passkey login rates. If user friction is your top concern and your platform can support advanced logic to handle the “no passkey found” scenario gracefully, this approach is often bestinclass.

A separate “Sign in with Passkey” button (or link) appears alongside legacy credentials. Instead of automatically launching a passkey flow, the system waits until the user clicks the passkey button. Only then does the passkey ceremony commence, verifying whether a passkey exists on the user’s device.

Advantages

1. Simplicity to Implement: You can add a passkey button under or near the username/password fields with minimal disruption to existing flows.
2. No Identifier Step: Users who prefer passkeys can proceed directly with passkey authentication, sidestepping the email/username entry.
3. Avoids Extra Complexity: You don’t need advanced device or passkey detection logic, as the user is explicitly choosing passkey login.

Challenges

1. Lowest Passkey Usage: In practice, many users skip the passkey button out of habit or unfamiliarity, defaulting to known password or OTP flows—thus passkey usage remains low.
2. Less SMS OTP Savings: Because passkeys remain optional or “hidden,” your cost savings from decreased OTP usage will be minimal.
3. Reduced Security Gains: The system continues to rely on fallback methods even when a passkey might exist, failing to push new behaviors toward passwordless usage.

In short, passkey buttons are straightforward to roll out but typically yield low passkey login rates. However, they can serve as a transitional measure or a fallback approach for organizations concerned about account enumeration or lacking the infrastructure to autodetect passkeys.

When integrating passkeys, many enterprises get stuck between two imperfect extremes:

• Automatic passkeys login on every email / username entry, which can lead to false prompts, user confusion and QR Codes.
• Offering only a separate passkey button that users consistently bypass out of habit, resulting in minimal daily passkey usage.

Corbado bridges this gap with Passkey Intelligence and One-Tap Passkey Buttons, two proprietary enhancements for large scale deployments that elevate passkey usage from single digit percentages to over 50% and often +80% of all logins and at the same time drives login success rate close to 100%.

The biggest challenge with the automatic approach is deciding when to initiate an automatic login, as this depends on many factors. Corbado solves this with its Passkey Intelligence Engine.

Passkey Intelligence is a dynamic layer that predicts whether a user’s passkey is likely available on the current device or environment. Using signals such as:

• Device & Browser Data: Operating system version, browser capabilities, known passkey support.
• User History: Past successful passkey logins, fallback usage, skip patterns for this environment and device.
• Risk Indicators: Attempt frequency, IP signals, or user agent changes.

Corbado’s engine decides whether to:

1. Auto-trigger a passkey login (similar to the identifier-first approach).
2. Revert gracefully to fallback flows if we detect the passkey flow is unlikely to succeed (e.g. current device does not have a passkey and device is not capable to use cross-device authentication).

This eliminates guesswork. Instead of blanket “always try passkeys,” your system gently nudges users with passkeys only when success is likely, reducing frustration and boosting acceptance.

In real-world deployments, Passkey Intelligence has shown to reduce error rates on passkey logins by over 95% compared to a simple approach that starts automatic every time.

The biggest challenge with the separate passkey button approach is the extremely low usage rate. Users simply continue using the familiar conventional login form. This problem is difficult to solve because this approach is often chosen to avoid exposing whether an account exists, for security purposes (account enumeration). Corbado leverages Passkey Intelligence to solve this with our One-Tap Passkey Button.

1. Login with Separate Passkey Button: If a user logs in with a passkey, Corbado will activate One-Tap Passkey Button for the next login. One-Tap Passkey Button is also activated if a user creates a passkey after signing in with conventional login methods. One-Tap Passkey Button is like “remember my e-mail address” for passkeys.
2. Login with Password: We have discussed that one major drawback of separate Passkey Button approach is that users do not pro-actively use it. In case that happens Passkey Intelligence detects that a login could have been made with a passkey and (re-)activates One-Tap Passkey Button. That helps spread One-Tap Passkey Button also on new devices.
3. Subsequent Logins: One-Tap Passkey Button automatically appears - no separate email entry or manual passkey button needed. Users simply tap once, scan a biometric, and are logged in.

User frustration is minimized with fewer canceled login ceremonies and 95% fewer aborts compared to traditional identifier-first methods.

This approach is a game-changer for adoption in with the separate Passkey Button approach. In typical separate passkey button implementations, passkey usage might stall on 5%.

With One-Tap Passkey Buttons driven by Passkey Intelligence, that same flow can surpass 50% passkey login share within months with mandated passkey migration. Internal data shows that 97% of users who see a One-Tap Passkey Button stick with it, rarely reverting to passwords or MFA codes.

Other solutions may handle passkey creation well but fail when it comes to everyday usage, leaving organizations stuck with adoption rates too low to justify phasing out passwords and without realized benefits. Corbado solves both ends - seamless passkey enrollments plus compelling daily usage with industries highest passkey login rate - all while respecting user autonomy and fallback needs.

Key Takeaways:

• Separate Passkey Button without Corbado: Offers security but very limited login adoption and minimal user experience improvements.
• Automatic Passkey Login without Corbado: Improves usage but causes confusion by starting passkey prompts on devices that do not have access to the users passkeys, leading to confusion, QR codes and dead ends.
• Corbado’s One-Tap Passkey Button + Passkey Intelligence: Delivers the industry’s highest login rates, dramatically reduces user friction, increases passkey stickiness for both automatic login and passkey button.

Leveraging Passkey Intelligence combined with One-Tap Passkey Button, Corbado transforms passkey deployments from mere checkboxes into highly effective solutions that deliver measurable value and enhanced security at scale.

We are strong believers that only adoption makes a passkey project successful, therefore we strongly recommend evaluating vendor and in-house solutions based on their guarantees regarding two key metrics: User Activation Rate and Passkey Login Rate. These KPIs provide direct insight into real-world adoption and ongoing user engagement with passkeys, ensuring your chosen solution delivers the security and convenience benefits promised. We have included the most important KPIs also here as an overview, going into detail is not part of this article, more details can be found in our Buy vs. Build Guide.

If you need help benchmarking your current solution or are unsure about which KPIs to target, reach out to us for a free consultation.

Passkeys hold tremendous promise for creating seamless, secure authentication experiences, but simply offering them does not ensure widespread adoption. Achieving a high passkey login rate calls for a strategic approach of smart user flows, welltimed nudges, and technology that eliminates friction during daily signins. With the right approach, enterprises can readily surpass 50% passkey login usage and often climb toward 80% or more.

• What are the best practices for optimizing passkey login rates?
  High passkey login rates hinge on reducing user friction and maximizing visibility. Techniques like autotriggering passkeys (identifierfirst), contextual passkey prompts and offering OneTap signins all help drive daily passkey usage.
• How can enterprises effectively encourage consistent passkey usage at scale?
  Consistent usage thrives on carefully managed fallbacks, user education, and strategic technology. By analyzing devices, user history, and risk signals (as Corbado’s Passkey Intelligence does), you can gently guide users to passkeys whenever it’s likely to succeed - boosting ongoing adoption.

Corbado’s Edge: A Unified Approach to Adoption

Most passkey solutions merely ensure correct WebAuthn registration. Corbado closes the loop by combining:

1. Passkey Intelligence
   Smart prompts detect when a user’s device is has passkeys available and accessible, automatically initiating passkey flows only when success is probable eliminating false starts and confusion.
2. One-Tap for Identifier-First and Passkey Button Flow
   Users no longer have to “choose passkeys.” After a conventional login, Corbado seamlessly transitions future signins to a singletap, biometric authentication. Realworld data shows over 97% of users continue with OneTap after seeing it once.

The result? 50–80% of logins with passkeys within months, dramatically lowering OTP usage, cutting phishing vectors, and offering the user experience advantage that passkeys promise.

Ready to Transform Your Login Experience?

Corbado’s Enterprise Platform and handson expertise equip you to:

• Deploy passkeys without disrupting existing workflows.
• Optimize daily passkey usage through intelligent prompts and OneTap.
• Validate ROI via measurable jumps in passkey login rate and fewer SMS OTP.
• Migrate your user base away from passwords while preserving necessary fallbacks.

If you’re looking to escape singledigit passkey login rate and permanently reduce costly SMS OTP overhead, we’re here to help. Reach out today for a consultation, and let’s move your organization closer to a truly passwordless future - powered by Corbado’s proven passkey adoption strategies.