Passkey Enrollment, Recovery & Rollout Strategy

Passkey Enrollment, Recovery, and Rollout

Passkeys — discoverable WebAuthn credentials — replace passwords with public-key cryptography bound to the website's origin. They resist phishing, cannot be reused across sites, and are faster to use than passwords plus one-time codes. Platforms sync them across a user's devices through iCloud Keychain, Google Password Manager, and third-party password managers, which solves the biggest problem of earlier hardware-only approaches: losing the one device that could sign you in.

Implementing the WebAuthn ceremony is the easy part. The hard parts are product and operational: when to ask people to create a passkey, how sign-in works across devices and browsers, what happens when someone gets a new phone or switches ecosystems, and — above all — account recovery, which can quietly reintroduce the phishable methods passkeys were meant to replace. A good rollout treats passkeys as a journey with metrics, not a feature flag.

TL;DR

Synced passkeys follow users across devices in one ecosystem; device-bound passkeys (security keys) never leave the hardware.
Offer enrollment after a successful sign-in and in account settings; consider automatic passkey upgrades where supported.
Let users have multiple passkeys, name them from the provider (AAGUID), and manage or remove them.
Use autofill (conditional UI) sign-in, cross-device sign-in via QR codes, and identifier-first flows as fallbacks.
Store credential ID, public key, sign count, backup flags, transports, and AAGUID; keep providers in sync when credentials are removed.
Design account recovery to stay strong — additional passkeys, recovery codes, and verified, rate-limited flows — and measure enrollment, success, and fallback rates.

Quick Example

Passkey sign-in through browser autofill, with the input field marked for WebAuthn:

What the server stores per credential:

The parseRequestOptionsFromJSON and toJSON helpers are part of newer WebAuthn versions; libraries such as SimpleWebAuthn provide equivalents for older browsers.

Core Concepts

Synced and Device-Bound Passkeys

The backup eligible and backed up flags tell the server which kind it received. High-assurance environments may require device-bound credentials with attestation; consumer services usually accept any passkey.

Enrollment

After sign-in: offer a passkey right after a successful password or code sign-in, explaining the benefit in one sentence.
Account settings: a clear "Passkeys" section to add, name, and remove passkeys.
Automatic upgrades: where browsers and credential managers support conditional creation, a passkey can be created automatically after password sign-in with the password manager's consent flow.
New accounts: offer passkey-first signup with alternatives for people who cannot use passkeys yet.

Encourage at least two sign-in methods that are hard to phish — for example passkeys in two ecosystems, or a passkey plus a security key — so losing one does not trigger weak recovery.

Sign-In Flows

Keeping Providers in Sync

When users delete a passkey on your site, the credential still sits in their password manager, which leads to confusing failures. The WebAuthn Signal API lets sites tell credential managers about unknown, removed, or renamed credentials and updated user details, where supported. Also verify rpId and origins carefully when you have multiple domains; related origin requests allow sharing passkeys across related domains.

Account Recovery

Recovery is where phishing resistance is usually lost. A strong design:

Notify users on every recovery and credential change, require re-authentication for adding or removing passkeys, and invalidate sessions after recovery. Avoid SMS-only recovery for high-value accounts. See MFA.

Rollout

Pilot with employees or opt-in users; measure success rates per platform and browser.
Offer passkeys broadly after sign-in and in settings, with clear help content.
Prefer passkeys at sign-in for enrolled users (autofill, identifier-first).
Reduce passwords: let users remove passwords once they have enough passkeys and recovery options; consider passwordless-only accounts for those who opt in.
Support: train support staff on device changes, cross-device sign-in, and recovery; publish help articles.

See Authentication and Password Security.

Best Practices

Ask at the Right Moment

Offer passkeys right after successful sign-in and in context, not as a blocking wall.

Plan for More Than One Credential

Encourage multiple passkeys and keep strong recovery options so device changes are routine.

Make Recovery as Strong as Sign-In

Avoid recovery paths that bypass phishing resistance, and notify users of every change.

Measure by Platform

Track enrollment, success, and fallback per operating system, browser, and credential manager.

Common Mistakes

Recovery Through SMS Alone

One Passkey Per Account

Stale Credentials in Password Managers

FAQ

What is a passkey?

A discoverable WebAuthn credential — a public-private key pair bound to a website — used to sign in without a password. It resists phishing because it only works on the origin it was created for.

What happens to passkeys when a user gets a new phone?

Synced passkeys appear on new devices signed in to the same credential manager account. Device-bound passkeys do not transfer, so users need another passkey or a recovery method.

Should passkeys replace passwords immediately?

Usually not. Offer passkeys alongside existing methods, prefer them at sign-in, and allow users to remove passwords once they have reliable passkeys and recovery options.

How should account recovery work with passkeys?

Through layered options — additional passkeys, recovery codes, and carefully verified, rate-limited recovery with notifications — rather than weak fallbacks such as SMS alone for high-value accounts.

What should a server store for each passkey?

The credential ID, public key, signature counter, backup eligibility and state flags, transports, the provider's AAGUID, a user-visible name, and creation and last-use times.