Conditional Mediation

What Conditional Mediation Does in WebAuthn

Conditional mediation is a browser-mediated WebAuthn pattern that makes a passkey available inside an existing sign-in flow instead of forcing a separate authentication prompt. The practical effect is better discoverability and less friction, because the browser can surface the credential where users are already entering login details.

The key idea is that the browser, not the site, decides when to offer the passkey option and when to keep the experience unobtrusive. That makes it different from a separate “use your passkey” button or modal, and it is one reason the pattern is closely associated with smoother passkey adoption.

How the Browser Fits Into the Sign-In Experience

Conditional mediation works as an interaction model, not a new authentication factor. The relying party still uses WebAuthn, but the browser presents the passkey option contextually, often alongside username entry, so the user does not have to switch mentally between “password login” and “passkey login.”

That browser-led mediation matters because passkeys often fail at the last mile of adoption, not at the cryptographic layer. Users may not know the option exists, may not realise their device can use it, or may assume it is a separate account setup step. Conditional mediation reduces those usability gaps without changing the underlying authenticator model.

For broader identity design, this is a reminder that authentication success depends on both protocol strength and user-path design. A strong authenticator can still underperform if the sign-in journey hides it or makes it feel like a different product.

Why Conditional Mediation Matters for Passkey Adoption

Conditional mediation is valuable because it meets users at the point of intent. When the browser offers the passkey inside the same form where a user would normally sign in, the credential becomes visible at the moment it is most relevant, which can improve completion rates and reduce repeated password fallback.

It also helps organisations introduce phishing-resistant sign-in without demanding a hard switch in user behaviour. That transition path is important in mixed environments where some users have passkeys, others still rely on legacy methods, and the service needs to support both during migration.

From an implementation perspective, the pattern can be especially useful where account recovery, device replacement, and first-time login journeys already create friction. Conditional mediation does not solve those lifecycle issues by itself, but it can remove one of the most common usability barriers to passkey uptake.

Implementation and UX Trade-Offs

Conditional mediation depends on browser support and on a sign-in flow that is designed to present the credential choice at the right moment. If the page structure, field focus, or login sequence is inconsistent, the browser may not surface the passkey option in a way that feels natural to the user.

Teams should treat it as a user-experience decision with security consequences. A passkey flow that is too hidden will be ignored; one that is too prominent or poorly timed can confuse users who still expect the traditional sign-in path. The design goal is to lower friction without making the interaction ambiguous.

It is also worth separating conditional mediation from broader passkey policy. The pattern improves discoverability, but it does not itself decide whether a service should require passkeys, allow fallback methods, or enforce step-up verification for sensitive actions.

Practitioner Guidance

Why practitioners should care: Conditional mediation is most useful when passkeys already exist in the account model but are underused because users do not notice them in the login flow. In that case, the browser-mediated prompt can materially improve adoption without redesigning the entire authentication system.

What to watch for: If users still default to passwords after passkey enrolment, the problem may be discovery rather than capability. That usually points to a sign-in journey that does not make the passkey option visible at the point of intent, or to inconsistent browser support across the user base.

Practitioner takeaway: Treat conditional mediation as a usability lever for WebAuthn, not as a substitute for good account design, recovery planning, or consistent authentication policy.

Related resources from NHI Mgmt Group

• When does agentless access control make more sense than proxy-based mediation?
• Why do conditional approval flows create governance risk?
• How should security teams choose between secrets management and access mediation?
• How should security teams use MDM to enforce conditional access?