From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
If a bank's passkey rollout is stuck in the low double digits of enrollment, the most likely cause is not strategy. It's the sign-in form. Specifically, it's whether that sign-in form invokes conditional UI properly across every browser the bank's customers actually use.
Conditional UI is the WebAuthn capability — exposed through the mediation: "conditional" parameter on navigator.credentials.get() — that lets passkeys appear as autofill suggestions on the username field, alongside the user's saved usernames and email addresses. It is the difference between "passkey sign-in is a button I have to click" and "my passkey is the first thing I see when I tap the username box." Corbado's Passkey Benchmark 2026 puts numbers on the gap: a settings-only rollout produces a passkey login rate below 1%, a simple post-login nudge lifts it to 4–5%, an optimized device-aware enrollment reaches 23%, and a passkey-first return flow with conditional UI in place climbs past 60%. The plumbing on the sign-in form is the lever between those tiers.
And it is genuinely hard to ship cleanly. Browsers diverge. Password managers compete for autofill real estate. Edge cases multiply. This post is the honest engineer's tour of where conditional UI works, where it doesn't, and what the deployment patterns look like for a bank trying to ship it in 2026.
The technical mechanism is simple. The page calls navigator.credentials.get() with mediation: "conditional". The browser silently looks for a passkey associated with the relying party's origin. If one exists, the browser surfaces it in the autofill suggestions for any input field with an appropriate autocomplete attribute — username, email, or webauthn. The user taps the suggestion, the platform authenticator prompts for biometric or PIN, and the credential is signed and returned to the page.
The user experience is fast. There is no separate "sign in with passkey" button to find. The passkey behaves like a remembered username — but with cryptographic proof attached. For users who already enrolled, signing in is effectively a tap.
The cost is that conditional UI requires the page to set up the request before the user interacts with the form, hold the resulting promise open, and handle the response asynchronously. It also requires the form's autocomplete attributes to be set correctly, and it requires the browser to actually surface the suggestion — which is where the divergence starts.
Safari on iOS handles conditional UI well. Apple shipped it as a first-class platform feature, and on iOS 17 and later the behavior is consistent. Passkeys created in iCloud Keychain surface promptly in the username field's autofill suggestions, and the Face ID or Touch ID prompt fires reliably.
Safari on macOS is similar, with the same iCloud Keychain integration. The main divergence is when a third-party password manager (1Password, Dashlane) is installed and competing for autofill — the suggestions can be split or one source can win in unpredictable ways. Most banks address this by adding clear UI affordances ("Sign in with your saved passkey") alongside the autofill flow.
Chrome on Android works well when the user is signed into Chrome and the passkey is in Google Password Manager. Cross-account scenarios — a corporate Chrome profile, a guest profile, a managed device — can produce inconsistent suggestion behavior.
Chrome on desktop is the trickiest surface. Behavior depends on the OS (macOS, Windows, ChromeOS), whether the passkey is in Google Password Manager or the OS keychain, and whether a third-party password manager is installed. The deployment pattern that ships reliably is: detect Chrome desktop, prepare both conditional UI and a visible "Sign in with a passkey" affordance, and let the user reach for either.
Edge behaves close to Chrome but with its own quirks around the Microsoft Account / Windows Hello pathway. The Windows Hello prompt itself is reliable; the question is whether the conditional UI suggestion surfaces before the user types.
Firefox support has improved through 2025 and 2026 but still trails the others. Banks deploying conditional UI as a first-class flow should detect Firefox and provide an explicit passkey button as a parallel path.
Mobile is where conditional UI pays the largest dividend, and where the patterns are most stable. iOS Safari and Chrome on Android together represent the majority of consumer banking traffic, and both handle conditional UI well. A bank that gets these two surfaces right captures most of the adoption upside on mobile alone.
The pattern that works: set the form's autocomplete="username webauthn" attribute, invoke navigator.credentials.get() with mediation: "conditional" on page load (not on focus or click), keep the promise open until the form is submitted, and gracefully fall through to the password path if the user types instead of tapping a suggestion. Avoid running conditional UI inside an iframe — cross-origin iframe restrictions can break the flow.
Successful bank deployments tend to converge on a small number of patterns.
First, set up conditional UI on every sign-in surface where it's supported, and provide a visible passkey affordance everywhere. Don't bet on autofill alone. The button is a fallback for users whose browser, password manager configuration, or mental model doesn't lead them to the suggestion.
Second, treat conditional UI as a progressive enhancement. If the request fails, if the browser doesn't support it, if the user doesn't have a passkey enrolled — none of those cases should prevent the password flow from working. Wrap the call in feature detection and graceful fallback.
Third, monitor conditional UI invocation as a metric. The bank should know how often conditional UI is being invoked, how often a suggestion is shown, how often the user accepts it, and how often they fall through to password. These four numbers, broken down by browser and device, are the diagnostic that tells the bank whether the surface is actually working — or whether enrolled customers are still typing passwords because they never see the prompt.
Ideem's Passkeys+ ships a conditional UI handler that adapts the flow to the browser and device it detects. The handler manages the timing of the navigator.credentials.get() call, sets up the right autocomplete attributes, handles the cancellation and re-arming cases, and provides the metrics the bank's product team needs to see whether conditional UI is converting. Banks don't have to write per-browser code — the platform takes care of the divergence.
Conditional UI is the unglamorous plumbing that decides whether a passkey rollout reaches 20% or 80% enrollment. The banks that have moved fastest in 2026 are the ones who treated it as a first-class engineering project — and the ones who measure it know exactly where their adoption is leaking. The rest will spend the rest of the year wondering why their numbers stalled.
Most orgs running OTP-based MFA have 3–4 exploitable gaps they don’t know about. Our Authentication Assessment takes 2 minutes and shows you exactly where you stand — plus a phased migration roadmap.
Take the Assessment →Built by Ideem
Device-bound passkeys and A2A payment authentication. One SDK. No OTPs, no redirects.
Our 2-minute assessment scores your authentication setup and shows you exactly where the improvements are.
See Your Score →