Passkey adoption stalls when UX patterns break trust and discoverability

At a glance

What this is: This is an analysis of the passkey UX patterns that influence whether WebAuthn adoption keeps growing or stalls after the initial rollout.

Why it matters: It matters because identity teams need to align authentication UX, credential lifecycle handling, and fallback behaviour so passkeys reduce friction without weakening trust in the login flow.

By the numbers:

• As of June 2026, Conditional Create is supported in Safari 18+ on macOS, browsers on iOS/iPadOS 18+, Chrome 136+ on desktop, and Chrome 142+ on Android.
• Air New Zealand saw over 30% of customers opt into passkeys on prompt and call center volume drop 5 to 10% after rollout.

👉 Read Authsignal's analysis of passkey UX patterns that drive adoption in 2026

Context

Passkey adoption is less constrained by the WebAuthn ceremony itself than by the surrounding identity workflow. When users do not see passkeys at the right moment, encounter rejected authentications, or keep seeing stale credentials, they revert to passwords and the programme loses trust.

For IAM teams, that makes passkey implementation a lifecycle and experience problem as much as an authentication one. The key question is whether the login flow, credential manager, and backend state stay aligned enough for the user to trust the new method the first time it appears.

Key questions

Q: How should security teams implement passkeys without hurting login conversion?

A: Start with autofill in the existing sign-in form, then use immediate credential flows only where user intent is obvious. Keep a password or alternative fallback available, and measure passkey creation, sign-in success, and fallback rates together. Conversion improves when the new method feels like part of the current flow, not an extra decision point.

Q: Why do passkey programmes stall after an initial rollout?

A: They stall when users cannot see the credential at the right moment, when stale credentials still appear, or when failures make the method seem unreliable. Adoption depends on consistency across browser, provider, and backend state. If any one of those layers is out of sync, users fall back to passwords.

Q: What do security teams get wrong about passkey recovery and upgrade flows?

A: Many teams treat passkey enrolment as a one-time event instead of a lifecycle. Recovery, backend revocation, and automatic upgrades all need state synchronization so the user only sees valid choices. Without that, the credential manager keeps offering stale options and the organisation creates avoidable sign-in friction.

Q: How do teams know whether passkeys are actually working?

A: Look at passkey creation rate, passkey sign-in success rate, fallback rate, and unknown credential errors together. A healthy programme shows increasing successful use without a rising support burden. If users keep falling back or encountering invalid credentials, the authentication experience is not yet trustworthy.

Technical breakdown

WebAuthn conditional mediation and passkey autofill

Conditional mediation lets the browser surface a passkey inside the existing credential chooser instead of forcing a separate modal. In practical terms, the site starts a credential request, then waits until the user interacts with the username or email field. The autocomplete token with webauthn is what makes passkeys eligible for that surface. This matters because adoption is driven by visibility and timing, not just by cryptographic support. If the passkey appears where the user already expects credentials, the flow feels natural and repeatable.

Practical implication: place passkeys inside the default login path rather than asking users to choose a new flow upfront.

Immediate credential availability and intent-aware sign-in

Immediate credential flows try to use a credential already available on the device before showing account-picker style UI. That is useful when user intent is clear, such as returning to an app, signing in at checkout, or stepping up before a sensitive action. The design pattern reduces latency and avoids unnecessary prompts, but only when the product can fall back cleanly if no passkey exists. This is not about forcing passwordless login everywhere. It is about shortening the path when the user has already signalled they want to authenticate now.

Practical implication: reserve immediate credential flows for high-intent moments and keep a normal fallback when nothing is available.

Signal API synchronization and automatic passkey upgrades

Passkey providers do not know when a server-side credential was deleted, renamed, or invalidated unless the relying party signals that state back. The Signal API gives the provider enough information to stop presenting credentials that will fail, which prevents users from learning that passkeys are unreliable. Automatic upgrades take the same idea further by creating a passkey after a successful password login when conditions are met. Together, these patterns treat passkeys as a managed identity state, not a one-time registration event.

Practical implication: synchronize credential state after failed verification and promote eligible password users quietly when the environment supports it.

NHI Mgmt Group analysis

Passkey adoption is a trust problem before it is a standards problem. The article shows that users abandon passkeys when the browser surface, backend acceptance rules, and recovery experience are out of sync. That is not a cryptographic failure, it is an identity lifecycle failure in the login path. Practitioners should treat passkey trust as a stateful user expectation that can be damaged by one bad experience.

Credential visibility is now part of authentication governance. If a passkey is available but not surfaced, or surfaced at the wrong time, the user experiences the system as unreliable. That means authentication teams need to govern discoverability and fallback behaviour with the same seriousness they apply to assurance levels and recovery policy. The practical conclusion is that UX is part of control effectiveness, not decoration.

Automatic upgrade changes the operational meaning of password migration. The article makes clear that passkeys can be created quietly after successful password authentication when conditions are met. That shifts migration from a campaign into an ongoing control pattern. Teams should therefore measure how often eligible users are actually converted, because the gap between eligibility and conversion is where adoption stalls.

Synced passkeys only work when the credential manager and relying party stay in lockstep. The Signal API exists because stale credentials create failed sign-ins, and failed sign-ins create distrust. This is the same lifecycle truth that appears across NHI governance: a credential that survives past its valid state becomes a reliability problem before it becomes a security problem. Practitioners should view stale passkey presentation as a governance defect, not just a support issue.

Passkey rollout programmes need a named concept: credential trust continuity. That is the expectation that a user sees only credentials the backend will accept, at the moment the user expects them. The article’s configurations all support that continuity, while stale or hidden credentials break it. The implication is simple: adoption grows when identity state remains coherent across browser, provider, and server.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The same lifecycle discipline applies to passkeys, so review Ultimate Guide to NHIs , The NHI Market for the governance context behind credential state and lifecycle control.

What this signals

Passkey rollout should now be treated as a credential-state programme, not just an MFA alternative. The important signal is whether your browser, provider, and backend all agree on what is valid at the moment of sign-in, because that coherence is what users experience as reliability.

Credential trust continuity: when a user only sees credentials the server will accept, adoption grows and support friction falls. That same principle appears across identity lifecycle work, including the NHI lifecycle patterns described in the Ultimate Guide to NHIs , The NHI Market.

The programme metric that matters is not just enrollment, but the rate at which valid credentials remain visible and usable over time. When stale entries linger, users learn to distrust the login method, and recovery volume rises even if the underlying cryptography is sound.

For practitioners

• Add passkey autofill to the existing sign-in field Use conditional mediation on the username or email form so passkeys appear in the browser's existing autofill surface instead of a separate modal. Keep the webauthn autocomplete token in place and test the flow in the browsers your users actually use.
• Limit immediate credential flows to high-intent moments Use immediate availability checks only where the user has already signalled intent, such as returning to the app, checking out, or performing a step-up action. Keep a normal fallback route when no credential is immediately available so the user does not hit a dead end.
• Signal stale or unknown credentials back to the provider After a failed passkey verification for an unknown credential, call the signal path so the provider stops offering credentials your backend will reject. That reduces repeated failure loops and keeps the chooser aligned with server truth.
• Promote eligible password users quietly after success Trigger automatic passkey creation after a successful password login when the platform supports conditional create and the user is eligible. Treat aborted creation, unsupported browsers, and duplicate credentials as quiet failures, not user-facing incidents.

Key takeaways

• Passkey adoption stalls when discoverability, fallback behaviour, and credential state drift break user trust.
• The strongest evidence in the article is operational, not theoretical: browser support is broadening and conversion improves when passkeys are surfaced quietly in the right moments.
• Teams should govern passkeys as a live credential lifecycle, with synchronization, signalling, and measured upgrade paths.

Key terms

• Conditional Mediation: A WebAuthn pattern that lets the browser offer a passkey inside the existing sign-in experience rather than forcing a separate prompt. It improves discoverability and reduces friction because the user encounters passkeys where credentials already live, not as a new login method to learn.
• Signal API: A WebAuthn mechanism for sending credential state back to the passkey provider after server-side changes or failed verification. It helps keep the credential picker aligned with backend truth so users are less likely to see stale or invalid passkeys at sign-in.
• Automatic Passkey Upgrade: A migration pattern that creates a passkey after a successful password login when the browser and provider can support it. It turns enrolment into background lifecycle work, which means adoption can rise without adding another explicit registration step for the user.
• Credential Trust Continuity: The condition where the user sees only credentials that the backend will accept, at the exact moment they are offered. It is not a formal standard, but it is a useful operational concept for understanding why passkey adoption succeeds or fails in practice.

What's in the full article

Authsignal's full blog post covers the implementation detail this post intentionally leaves for the source:

• Code-level WebAuthn examples for conditional mediation, including the exact browser request pattern.
• Platform-specific behaviour differences for Chrome, Safari, iOS, Android, and credential providers.
• Operational guidance for signalUnknownCredential, signalAllAcceptedCredentials, and signalCurrentUserDetails.
• A rollout checklist that ties creation rate, success rate, fallback rate, and error handling to production monitoring.

👉 The full Authsignal post covers the WebAuthn patterns, signaling logic, and rollout checklist in implementation detail.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.