Conditional UI lets your login form show saved passkeys in the browser's autofill list. You start a WebAuthn request with mediation set to conditional, tag the username input with the webauthn autofill token, and let the user pick a passkey as they would a saved password. Check feature support first.
What problem it solves
Without it, a site must ask "Do you want to sign in with a passkey?" and open a modal prompt, even for users who have none. With conditional mediation, the request waits quietly. If the user clicks the username field and has a discoverable passkey for your site, the browser lists it. If not, nothing interrupts a password or other path.
The W3C WebAuthn Level 3 Recommendation, dated 25 August 2026, describes it: by setting mediation to conditional, a relying party indicates that a prominent modal UI should not be shown unless credentials are discovered.
The steps
- Check support. The spec says the relying party should first call
isConditionalMediationAvailable()orgetClientCapabilities()and look for theconditionalGetcapability, to avoid a user visible error when it is missing. - Tag the input. Add the
webauthnautofill detail token to the username field. The spec says it must appear right after the last other autofill token, for exampleusername webauthn. - Start the request on page load. Call
navigator.credentials.get()withmediation: "conditional"and a server generated challenge. Do not wait for a click. - Leave allowCredentials empty. The spec's algorithm empties it for conditional requests, which means non discoverable credentials cannot be used here.
- Handle the result. If the user picks a passkey, send the assertion to your server and verify it as usual.
- Keep a fallback. Offer the password field or a "use another way" button for users without passkeys.
- Abort cleanly. Use an
AbortControllerto cancel the pending request if the user switches to another sign in method.
Why discoverable credentials matter
Because the browser must list credentials without you naming them first, conditional UI works only with discoverable credentials, which are stored with a user handle. The spec says the user handle must always be populated for discoverable credentials. If you create credentials as non discoverable, autofill will not find them.
Design notes
- The request has no timeout in the usual sense: the spec sets the lifetime to infinity so the user has the whole life of the page to interact. Make sure your challenge handling copes with that, and refresh the request if the challenge expires on your server.
- Do not hide the password field until you know passkeys work. Keep both paths until you have confidence in coverage.
- Treat the autofill path like any other sign in. Rate limit, log, and run the same assertion verification.
Conditional create
The spec also defines conditional creation, where the browser can register a passkey without a prominent prompt if the user has already consented. Check the conditionalCreate capability first. When used, the client sets user presence and verification requirements to false unless they are performed during the ceremony, so decide whether your policy allows that.
Quick check
Does conditional UI work for every browser?
No. Feature detect with isConditionalMediationAvailable or the conditionalGet capability and fall back when absent.
Can users with only a security key use autofill?
That depends on whether the key stores a discoverable credential. Non discoverable credentials cannot be used with conditional requests.
Safeguard's SBOM and dependency scanning shows which authentication libraries you ship, which helps you track updates as passkey support changes. There is a free scan.
Sources
Last reviewed: 19 October 2026.
