A practical passkey rollout checklist
Passkeys replace passwords with a sign-in flow that is both faster and harder to phish. Moving from theory to deployment, however, requires attention to a handful of integration details that determine whether users actually adopt the new credentials — or get stuck with a broken sign-in path.
This checklist is aimed at developers and product teams who are implementing passkeys in an existing authentication system. Use it to validate work against current UX best practices, to spot required versus optional elements, and to run a final review before shipping.
Registration: build the right first step
The core registration flow is covered in the passkey creation guide, but several supporting details deserve explicit checks.
Pin the authenticator attachment to "platform". Pass "platform" as the authenticator attachment value to navigator.credentials.create() when you want to promote passkey creation. This keeps the prompt focused on the device the user is already holding.
Re-verify the user with the strongest available method before creating a passkey. If you skip re-authentication, an attacker who has hijacked a session can register their own passkey and cement that access.
Prevent duplicate passkeys per provider. Many passkey providers only store one passkey per account and RP ID. Use excludeCredentials to stop users (or attackers) from creating redundant credentials on the same provider.
Name credentials with the AAGUID. Use the AAGUID to identify the passkey provider and build a human-readable name for the credential. This makes the management page far more intuitive.
Signal unknown registration attempts. If the server fails to store a new passkey, call PublicKeyCredential.signalUnknownCredential() so the provider can clean up the orphaned credential.
Notify the user after registration. Send a confirmation when a passkey is created on an account. This matters particularly if the creation was triggered by someone other than the account owner. Details are in the registration notification guide.
Authentication: serve both password and passkey users
The recommended path for a site transitioning away from passwords is form autofill with passkeys. That keeps the password field working while surfacing passkeys as a silent, frictionless option.
Signal missing credentials. When a passkey received from the client has no matching public key on the backend, call PublicKeyCredential.signalUnknownCredential(). This lets the provider delete the stale passkey instead of showing it to the user again.
Actively encourage passkey creation. If a user signs in but has no passkey, prompt them to create one manually.
Offer conditional create. For users who authenticate with a password plus a second factor, you can automatically create a passkey after sign-in. This dramatically accelerates adoption.
Handle the cross-device case. If a user signed in with a cross-device passkey, prompt them to create a local passkey afterward. This removes the QR code step from future sign-ins; the pattern is covered in the form autofill guide.
Sync passkey state after sign-in. Signal the full list of available passkeys and any updated user details such as username or display name to the provider after authentication completes. Keeping this state in sync avoids confusing stale entries in the browser UI.
Management: give users visibility and control
A dedicated passkey management page is the centerpiece of a responsible deployment. Users need to see what exists, understand what it does, and be able to revoke it.
Support multiple passkeys per account. Registering more than one passkey is necessary to let users avoid lockout without falling back to a weaker authentication method.
Make it easy to add new passkeys. The management page itself should let users create additional credentials of different types.
Show meaningful names. Display the registered passkey name, derived from the AAGUID, so users can recognize each credential at a glance.
Distinguish syncable from non-syncable passkeys. Flag credentials that stay on a single device so users are not surprised when a passkey fails to appear on another machine.
Support deletion end-to-end. Allow users to remove a public key from the server, then signal the updated passkey list to the provider so the local copy is removed too.
Additional system hygiene
Two edge cases still need attention outside the main flows:
- Propagate user detail changes. When a user updates their username or display name, send the updated details to the provider so credential metadata stays correct.
- Repurpose the password recovery path. When a user clicks “forgot password,” consider creating a passkey instead of resetting to a new password. The pattern is documented in the passkey design guidelines.
