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. Unit 42 recovered synced private keys from Chrome's Google Password Manager on Windows by extracting the Security Domain Secret from process memory, and there is no rotation mechanism for that secret. Every published attack started from malware already on the endpoint, 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
userVerificationserver side. If you requestpreferredand accept an assertion with the flag unset, you have possession without user presence. Userequiredfor 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.
- 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:
- 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 shipped multiple passkeys per account in August 2026 for exactly this reason.
- Do not fall back to SMS. An account protected by a phishing-resistant credential with an SMS recovery path is protected by SMS.
- 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
- Ship passkeys as an option alongside passwords, behind a flag, for internal users first.
- Measure enrolment and successful authentication rates before promoting the option.
- Prompt existing users to enrol after a successful password sign-in, not before.
- Once enrolment is high enough, stop offering passwords to enrolled users.
- 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.
Related on Start with Identity
- GuideImplementing Passkeys in the Enterprise
A practical guide to deploying passkeys across your enterprise, covering WebAuthn integration, device attestation policies, account recovery workflows, and stra
- GuideIdentity Federation Implementation Guide: Protocols, Trust, and Cross-Domain SSO
A step-by-step guide to implementing identity federation covering SAML, OIDC, and WS-Federation protocols, trust relationship configuration, attribute mapping,
- GuideMFA Implementation Best Practices
A complete guide to implementing multi-factor authentication, comparing MFA methods, deploying phishing-resistant MFA, balancing security with user experience,
- GlossaryPasskey
A passkey is a WebAuthn public-key credential that replaces a password. Possession of the authenticator plus a user verification step proves identity, with no s
- Blog94 percent of enterprises say they can revoke access in 24 hours. 35 percent found out they couldn't.
FIDO Alliance and HID surveyed 500 IT and security decision-makers for The State of Physical and Digital Identity in the Enterprise. The headline gap: near-univ
- BlogAmazon says 175 million customers now sign in with passkeys
Amazon reports more than 175 million customers have enabled passkeys, signing in six times faster, with passkeys now the default on mobile for anyone who has se