Passkeys 101: What they are and when to ship them

Problem statement

Passwords are the largest single source of account compromise. Passkeys replace shared secrets with public-key credentials bound to a device and a user verification step.

How they work

A passkey is a WebAuthn credential. Registration creates a key pair, the public key goes to the server, the private key stays on the authenticator. Authentication is a signed challenge.

When to ship

Ship passkeys behind a feature flag, alongside passwords, with a clear recovery path. Do not force passkeys until your recovery flow is honest about lost devices.

Synced vs device-bound

This is the decision that matters most and the one rollout plans skip. A synced passkey lives in a platform credential manager (iCloud Keychain, Google Password Manager, a password manager) and follows the user across their devices. That is what makes consumer adoption possible, because nobody buys two hardware keys for a shopping account.

A device-bound passkey never leaves the authenticator, typically a hardware security key or a platform authenticator with attestation. It cannot be synced, which means it also cannot be recovered from the sync fabric if the device is lost.

Research published in August 2026 sharpened the trade-off. In Pass the Passkey (August 3, 2026), Unit 42 showed that the Security Domain Secret protecting Google Password Manager passkeys in Chrome on Windows remains accessible in Chrome's process memory, and that "there is no way to rotate or revoke the SDS." Every presented attack relies on malware already on the victim's device, so this is not an argument against passkeys, but it is an argument for tiering: synced passkeys for consumers, device-bound authenticators for administrators and anyone with production access.

Server-side validation that actually matters

The relying party controls the assurance level, and getting these wrong produces a passwordless flow with a password's security:

• Validate userVerification server side. If you request preferred and accept an assertion with the flag unset, you have possession without user presence. Use required for anything sensitive and check the flag on the server, not in the client.
• Pin your relying party identifier early. The RP ID fixes the origin a credential will sign for, and changing it later invalidates every enrolled credential. Decide the domain before launch.
• Check the signature counter where the authenticator provides one, as a cloning signal. Under the WebAuthn spec, authenticators that do not implement a counter leave signCount "constant at zero", and synced passkeys commonly report 0 (SimpleWebAuthn notes Touch ID on macOS always does), so treat zero as "no counter" rather than a failure.
• Use attestation if you need to enforce a specific class of authenticator, for example requiring hardware keys for admins. Most consumer deployments should not.

The recovery problem

Recovery is where passkey projects fail, because removing the password also removes the fallback everyone quietly relied on. Three rules:

1. Enrol at least two credentials per account. Prompt for a second device at the first successful sign-in rather than at registration, when the user is already invested. WhatsApp added support for more than one passkey per account on August 25, 2026, so people who use both Android and iOS devices can enroll a credential on each.
2. Do not fall back to SMS. An account protected by a phishing-resistant credential with an SMS recovery path is protected by SMS.
3. Be honest in the UI about what happens when every device is gone. For consumer products that usually means identity verification. For workforce, a help desk process that does not rely on caller-supplied facts, which is the exact path Scattered Spider exploits.

A rollout sequence that works

1. Ship passkeys as an option alongside passwords, behind a flag, for internal users first.
2. Measure enrolment and successful authentication rates before promoting the option.
3. Prompt existing users to enrol after a successful password sign-in, not before.
4. Once enrolment is high enough, stop offering passwords to enrolled users.
5. Only then consider removing passwords entirely, with a tested recovery path in place.

Where to start

Work through the passkey rollout checklist, read the WebAuthn and FIDO2 standard page for the protocol detail, and follow the add passkeys with WebAuthn recipe for implementation. For the vendor shortlist see best passwordless CIAM providers and best phishing-resistant MFA.