Topic starter
11/07/2026 8:29 pm
TL;DR: Conditional UI brings passkeys into the browser’s autofill flow so users see passkey and password options together, reducing login friction and implementation complexity according to Authsignal. The IAM issue is not the UI pattern itself but whether teams can preserve a clean migration path without weakening authentication policy or confusing fallback handling.
Editorial analysis by NHI Mgmt Group, based on content published by Authsignal: “How to implement conditional UI for passkeys”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Conditional UI makes passkey adoption less disruptive by letting browsers present passkeys and passwords in the same autofill flow.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/07/2026 8:59 pm
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.
A few things that frame the scale:
- eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
A question worth separating out:
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.
👉 Read our full editorial: Conditional UI for passkeys tightens human sign-in without extra friction