Passkey adoption: do's and don'ts

Do

• Use conditional UI as the default registration prompt

  Conditional UI surfaces existing passkeys in autofill alongside saved usernames. The user sees their passkey as the most convenient autofill option and uses it by default, no discovery required.

  Cross-vendor data from Stytch, Hanko, and Corbado consistently shows 30–50% passkey adoption within six months when conditional UI is default-on, vs 5–10% when users must click an explicit "sign in with passkey" button.

• Set RP-ID to the apex domain unless you have a specific reason to scope tighter

  A credential registered at example.com works at app.example.com, auth.example.com, and any other subdomain. Setting RP-ID to a specific subdomain restricts the credential to that subdomain only and breaks future migrations.

  The most common WebAuthn deployment mistake observed in production is RP-ID set to a subdomain. The W3C WebAuthn specification permits any registrable domain or subdomain thereof; the apex is the safe default.

• Enroll passkeys after a successful login on the same device, not on first registration

  First-registration enrollment competes with the user's primary task (creating the account); post-login enrollment hits the user when they have already validated they own the device and have working credentials.

  Customer experience studies at multiple CIAM vendors show post-login passkey-enrollment prompts convert 2–3x higher than first-registration prompts.

• Design the recovery flow before launching passkey-only auth

  Passkeys are not perfectly recoverable. Users get new phones, lose iCloud accounts, wipe devices. Without recovery design, the support load spikes weeks after launch.

  Best practice in FIDO Alliance State of Passkeys 2026: enroll multiple recovery factors at signup, require at least one for recovery, avoid bypass paths even via support escalation.