Conditional UI for passkeys tightens human sign-in without extra friction

At a glance

What this is: This is a practical guide to conditional UI for passkeys, showing how browsers surface passkeys in autofill alongside passwords and how that reduces sign-in friction.

Why it matters: It matters because IAM teams can improve passkey adoption without redesigning login flows, but they still need to preserve clean fallback handling and avoid confusing authentication states.

Context

Conditional UI is a WebAuthn sign-in pattern that places passkeys inside the browser’s autofill experience instead of forcing users through a separate login choice. That changes the authentication problem from persuading users to adopt a new path to making the existing path capable of supporting both passwords and passkeys cleanly.

For identity teams, the governance question is not whether passkeys work, but whether the sign-in journey stays coherent while password and passkey methods coexist. The article focuses on how conditional UI reduces friction, what it changes in the login experience, and how teams can implement it without adding unnecessary state handling.

Key questions

Q: How should teams implement passkeys in customer IAM without breaking existing sign-in journeys?

A: Start with the journeys that create the most friction, then define where passkeys are primary, where fallback is allowed, and which recovery paths remain acceptable. The goal is not to remove every alternate method immediately, but to ensure the safer path is the simplest path for most customers.

Q: Why does a separate passkey button create adoption friction?

A: A separate button forces the application to decide who should see passkeys and who should not, which often means extra state management or confusing dead ends for users without registered passkeys. Conditional UI avoids that by letting the browser expose the option only when it exists, inside the familiar autofill path.

Q: What signs show that a passkey rollout is becoming too complex?

A: If you need user-specific logic to decide when the passkey option appears, or if password fallback starts producing inconsistent screens and error messages, the rollout is drifting away from a clean migration model. That usually means the sign-in experience is carrying more policy logic than the browser can handle naturally.

Q: What should identity teams do when passkeys coexist with password-era workflows?

A: Decide which legacy flows will be retired, which will be time-limited, and which will be prohibited entirely. Then align security, support, and product ownership so the default journey favours passkeys and the exception paths do not reintroduce phishable access.

Technical breakdown

How conditional UI uses browser autofill for passkeys

Conditional UI, also called passkey autofill or conditional mediation, tells the browser to surface passkeys only when the user interacts with a username or password field. The browser checks whether a passkey is registered for that site and then offers it alongside saved passwords in the autofill dropdown. If the user selects a passkey, WebAuthn hands off verification to the platform authenticator such as Face ID, Touch ID, or Windows Hello. The important architectural point is that the browser, not the application, manages discovery and selection inside the familiar credential prompt.

Practical implication: design the login form so the browser can do the discovery work without custom UI branching.

Why separate passkey buttons create migration friction

A separate passkey button forces the application to decide who should see it, which means tracking passkey state before sign-in or accepting that some users will click into a dead end. That creates avoidable complexity because the application has to infer readiness, while the browser already knows whether a passkey exists for the site. Conditional UI removes that split by letting passkey users and password users share one entry point. In practice, this makes passkey adoption a transition problem rather than a parallel-authentication problem.

Practical implication: avoid custom method-selection logic unless you have a very specific reason to override the browser’s autofill path.

How WebAuthn conditional mediation fits the sign-in flow

Implementing conditional UI means setting the autocomplete token so the browser can include WebAuthn in autofill suggestions, then starting a WebAuthn request with mediation set to conditional. That request waits quietly until the user interacts with the autofill menu, then returns a token for server-side validation. The server still has to verify the challenge and create the session, so conditional UI changes how the credential is presented, not how authentication trust is established. This is why it works well with standard username and password forms but is less suitable for heavily customised flows.

Practical implication: keep the form simple and initialise the conditional request early so browser discovery can happen before user interaction.

NHI Mgmt Group analysis

Conditional UI turns passkey adoption into a browser-mediated identity journey, not a custom application decision. That shifts the control boundary from the login page to the browser’s native credential chooser, which reduces the number of places where teams can mis-handle passkey state. The practical consequence is that sign-in governance improves when the browser owns discovery and the application owns validation.

The real problem conditional UI addresses is not passkeys themselves, but the failure mode created by dual-path sign-in. Separate buttons, method selection screens, and user-specific branching all create avoidable inconsistency in the authentication experience. When a password and a passkey must coexist during migration, the cleanest path is the one that lets the browser present both without forcing the user to make an early decision.

Passkey rollout should be treated as an authentication migration, not a UI experiment. Teams that focus only on visible friction miss the downstream governance issue: the fallback path still needs clear ownership, policy consistency, and predictable recovery handling. The implication is that identity architects should measure whether the transition preserves control clarity as well as user convenience.

Conditional UI is a useful pattern for human sign-in, but it does not change the underlying assurance model. The browser can make passkey use feel seamless, yet the application still needs a server-side challenge check and a coherent account recovery stance. That makes this a usability and adoption control, not a substitute for authentication policy.

Passkey autofill creates a better migration surface, but not a more permissive one. The article shows how the browser can expose a passkey when available and disappear when not, which is exactly the right behaviour for gradual adoption. For practitioners, that means the governance question moves to whether the surrounding identity journey remains understandable when one method is present and the other is silently available as fallback.

From our research library:

• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
• Read next: Passwordless and Passkeys Guide

What this signals

Conditional UI reduces the cost of passkey migration because the browser, not the application, decides when a passkey can be offered. That matters for programme design: every custom decision point you remove lowers the risk of inconsistent fallback handling and makes the authentication journey easier to govern.

Passkey adoption is easier to sustain when the existing password path remains intact and predictable. IAM teams should watch for sign-in flows that become more fragile as passkeys are introduced, because friction often reappears in the fallback experience rather than the passkey step itself.

For practitioners

• Use conditional UI as the default passkey entry pattern Add the WebAuthn autofill token to standard username or password fields so the browser can present passkeys alongside saved passwords without a separate sign-in button.
• Keep the sign-in form simple Use conditional UI with a conventional login flow, because complex multi-step flows can interfere with the browser’s autofill behaviour and reduce passkey visibility.
• Validate the passkey challenge on the server Treat the browser token as the start of authentication, then verify the challenge server-side before creating the session or upgrading the sign-in state.
• Preserve password fallback without extra branching Let users without passkeys continue through the existing password path so adoption can grow without forcing account-specific UI logic or error states.

Key takeaways

• Conditional UI makes passkey adoption less disruptive by letting browsers present passkeys and passwords in the same autofill flow.
• The main governance issue is not the browser feature itself, but whether teams preserve a clear authentication path while both methods coexist.
• Identity teams should keep sign-in forms simple, validate challenges server-side, and avoid custom branching that undermines fallback clarity.

Key terms

• Conditional UI: Conditional UI is a WebAuthn pattern that lets the browser surface passkeys inside the normal autofill experience. It reduces sign-in friction by making passkey selection feel like part of standard credential entry, while authentication still depends on browser-mediated challenge handling and server-side verification.
• Passkey Autofill: Passkey autofill is the user experience where a passkey appears in a browser’s saved-credentials dropdown alongside passwords. It is not a separate authentication system. It is a discovery and selection mechanism for phishing-resistant authentication that still requires proper WebAuthn validation on the server.
• 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.
• WebAuthn: WebAuthn is a browser and platform standard for phishing-resistant authentication using public-key cryptography. It binds the authenticator to the origin and signs a challenge instead of sending a reusable code, which makes replay and relay attacks far harder.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.