Start with Identity
← Guides
Authentication · Beginner

Passkeys 101: What they are and when to ship them

By SWI Community Team · Updated 2026-08-29 · 10 min

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 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.
  • 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 shipped multiple passkeys per account in August 2026 for exactly this reason.
  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.

Last reviewed By SWI Community TeamSuggest a correctionHow we research