Conditional UI Login Completion
Conditional UI Login Completion compares the pre-server login path when users type an identifier versus when field-level passkey help is available. It shows why server-side passkey success can look near-perfect while real Conditional UI performance depends on field wiring, user choice, final login completion and speed.
Where Conditional UI actually breaks: the three measurement points
Conditional UI (CUI) usually gets reported as one number: the server-side success rate. That number sits at the very end of the flow and looks close to perfect. The two earlier numbers, where users actually drop out, are below.
This is the pre-server moment: the suggestion is visible, the user chooses it and the browser verification finishes. Drop-off here means users dismiss the prompt, switch accounts, cannot unlock locally, have no usable credential on the device or abandon before a signed request exists.
The login eventually succeeds, sometimes after another CUI attempt, autofill or typed fallback. This is the user-facing completion number.
This number is useful for server reliability, but it starts after the Conditional UI user experience already worked.
Where Conditional UI Turns Into Adoption
The decisive number is not whether the browser supports Conditional UI. It is how often a real user sees the right passkey suggestion at the right moment, then reaches the login without account confusion, password-manager detours or manual fallback.
| Platform | Passkey suggestion share | What it means |
|---|---|---|
| macOS | High | Suggestions are visible on most assisted entries. |
| Windows | Low | Fewer desktop users have a usable local passkey, so CUI fires less often. |
Use these signals to read your own deployment.
Look for missing credential coverage, passkeys on another device, incorrect field wiring, password-manager overlays, RP/account-context mismatches or a rollout that has not built enough credential base yet.
Users still sign in, but not directly. The optimization target is speed and directness: reduce identifier detours, support recovery and use recognized-device or one-tap entry where the context is strong enough.
- Final login completion is merged across follow-on interactions within the same login process: users can switch accounts, dismiss a prompt, retry CUI or fall back to typing before the login eventually completes.
- A valid Conditional UI assertion is almost always accepted server-side; the measurement gap sits before the assertion exists. Server-only reporting therefore looks healthier than the real login-entry experience.
- Conditional UI share within assisted entry depends on the deployment’s device mix and how long the product has been live. Windows desktop deployments often show a smaller local suggestion base because many users hold their usable passkeys on phones rather than the current device.
- Healthy autofill behavior is a prerequisite for healthy Conditional Create. See Conditional Create Rate for the inverse view, where autofill quality predicts how often a passkey gets created automatically after a successful password login.
Further Reading
Curated Corbado research and primary references.
- Sign in with a passkey through form autofill Google's implementation guide for conditional UI in existing username and password forms.
- WebAuthn Conditional UI Passkeys & Autofill A practical explanation of passkey autofill, conditional mediation and identifier-field wiring.
- Passkey Device Support Compatibility matrix for passkey autofill and sign-in behavior across platforms and browsers.