Skip to content
authentication

Passkeys Explained: How Synced Credentials Replace Passwords

Updated 2026-05-06 · 11 min read · By @guptadeepak

Key takeaways

  • A passkey is a WebAuthn credential that syncs across the user's devices via iCloud Keychain, Google Password Manager, or 1Password.
  • Passkeys are phishing-resistant by construction: the credential is bound to the relying party origin, so AitM proxies cannot replay it.
  • Synced passkeys clear AAL2 in NIST SP 800-63-4; device-bound FIDO2 keys clear AAL3.
  • Adoption above 30% requires conditional UI plus device-aware prompting plus a recovery flow design, not just protocol support.
  • Cross-platform sync is solved (Apple, Google, Microsoft + 1Password). Cross-cloud-provider transfer is the remaining gap.

What a passkey actually is

The passkey brand was introduced jointly by Apple, Google, and Microsoft in 2022 as the user-facing name for cross-device synced WebAuthn credentials. The protocol pre-dated the brand by years; what changed in 2022–2024 was the cloud-sync layer and the consumer-facing UX patterns.

How sync works

When a user creates a passkey on iPhone, the credential is generated locally on the Secure Enclave and written to iCloud Keychain. The same iCloud account on the user's MacBook reads the credential. The same logic applies on Android with Google Password Manager and on Windows with 1Password or Microsoft Authenticator.

The cryptographic material is end-to-end encrypted in the cloud. Apple, Google, and Microsoft cannot read your private keys, they hold encrypted blobs the user's device decrypts locally. This is structurally different from a password manager that holds plaintext credentials.

How authentication works

The browser exposes navigator.credentials.get(). The relying party server issues a challenge; the browser asks the user to consent (Face ID / Touch ID / device PIN); the authenticator signs the challenge with the private key; the browser returns the signature; the server verifies it against the stored public key. The signed payload includes the origin the browser saw, so an attacker proxy at attacker.com cannot forge a signature for example.com.

Passkey registration: the relying party never sees the private key. The authenticator signs an attestation that proves possession; the public key is what gets stored.
Passkey registration: the relying party never sees the private key. The authenticator signs an attestation that proves possession; the public key is what gets stored.

Why adoption stalls without orchestration

Most CIAM vendors in 2026 ship competent WebAuthn primitives. Adoption rates vary by an order of magnitude, some deployments hit 50%+ within six months, others plateau at 5–10%. The differentiator is orchestration:

  1. Conditional UI, mediation: "conditional" surfaces existing passkeys in browser autofill alongside saved usernames. The user clicks autofill and is signed in. Without conditional UI, users must discover a "sign in with passkey" button.
  2. Device-aware prompting, after a successful login on a new device, ask if the user wants to enable a passkey here. Don't ask on every device every time; gate by device fingerprint and a 30-day cooldown.
  3. Recovery as a first-class flow, synced passkeys are recoverable through the cloud account, but cloud-account loss happens. Enroll secondary recovery factors at signup; require at least one for recovery.

Vendors with explicit orchestration (Stytch, Hanko, Corbado, Descope, Authsignal, Beyond Identity) deliver materially higher adoption than vendors with raw WebAuthn support and bare default UI (Auth0 default, Cognito, most OSS CIAM).

Cross-cloud-provider transfer

The remaining 2026 gap is moving passkeys between Apple, Google, Microsoft, and 1Password ecosystems. The FIDO Alliance Credential Exchange Protocol (CXP) is the emerging standard; partial support exists in late 2025 / early 2026 implementations but isn't yet seamless. For most deployments this is a long-tail concern; users who switch ecosystems re-enroll passkeys at the new device.

When passkeys aren't enough alone

Passkeys eliminate credential-stuffing and phishing-proxy ATO classes. They don't eliminate:

  • Session hijacking, a stolen session token after passkey auth still grants access until expiry.
  • Recovery flow abuse, if recovery flows quietly skip MFA, attackers exploit those instead.
  • Insider abuse, admins with permission to reset auth factors.

The full stack remains layered: passkeys plus short-lived sessions plus rigid recovery design plus admin policy.

Vendor support snapshot

The CIAM with the strongest 2026 passkey orchestration: Stytch, Hanko, Corbado, Descope. Auth0 ships passkeys but with bare default UI; pair with Authsignal or Corbado for orchestration. Beyond Identity provides hardware-attested device-bound credentials beyond stock WebAuthn for high-assurance deployments.

Related vendors

FAQ

Is a passkey the same as WebAuthn?
Passkey is the user-facing brand name; WebAuthn is the underlying W3C standard. Every passkey is a WebAuthn credential, but not every WebAuthn credential is a passkey, device-bound FIDO2 hardware keys are also WebAuthn credentials but do not sync.
Can passkeys be phished?
No, in the conventional sense. The browser refuses to assert a passkey for a relying party other than the origin where it was registered. AitM phishing proxies that defeat SMS OTP and TOTP cannot defeat passkeys because the signature is bound to the origin.
What happens if I lose all my devices?
Synced passkeys live in your cloud account (Apple ID, Google Account, 1Password). Recovering the cloud account recovers the passkeys. Production deployments should also enroll secondary recovery factors (alternate verified email, TOTP, backup codes) so cloud-account loss isn't unrecoverable.
Can I move passkeys between cloud password managers?
Cross-provider passkey transfer (Apple → Google, 1Password → Apple) is partial in 2026, credential export is supported but import behavior varies. The FIDO Alliance Credential Exchange Protocol (CXP) is the emerging standard for portable transfer.

Sources

  • FIDO Alliance State of Passkeys 2026
  • W3C WebAuthn Level 3 specification
  • FIDO Alliance Credential Exchange Protocol (CXP) draft
  • Apple, Google, Microsoft passkey documentation
Last reviewed 2026-05-06.