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.
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:
- 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. - 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.
- 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
Auth0
Auth0 remains the safest mid-market default for B2C plus B2B Enterprise SSO when developer velocity matters more than long-run TCO. Below 50k MAU it is hard to beat. Above 500k MAU, cost and Actions-driven lock-in make alternatives like FusionAuth (self-host), Cognito (AWS-native), or Stytch plus Corbado (passkey-first) increasingly attractive.
Clerk
Clerk is the default for Next.js and React teams under 100k MAU who care about time-to-first-login and polished UI more than federation breadth. Above 100k MAU and into enterprise SSO breadth, Auth0 still leads. For passwordless and B2B Organizations under that ceiling, Clerk is among the strongest in the market.
Corbado
Corbado is the deepest passkey-specialist orchestration layer in 2026, focused exclusively on driving passkey adoption on top of any underlying CIAM, with adoption analytics, A/B testing, and recovery-flow tooling that no full-platform vendor ships. For teams running Auth0 / Cognito / Keycloak who want to fix passkey adoption without changing primary CIAM, Corbado is the singular pick alongside Authsignal. Not a full CIAM, pick one of those first if greenfield.
Hanko
Hanko is the open-source passkey-first CIAM in 2026, orchestration quality at the level of Stytch, but with AGPL self-host as an option and EU data sovereignty by default. For B2C consumer apps where passkey adoption is the goal and B2B Enterprise SSO is not the priority, Hanko is one of the strongest picks. For B2B SaaS or compliance-heavy workloads, the narrow scope shows.
Stytch
Stytch is the strongest passkey-first CIAM in 2026 by orchestration quality, not raw feature count. Twilio acquired it on October 30, 2025; the product runs as a Twilio subsidiary with its own API surface, SDK family, and pricing, distinct from Twilio Verify. Post-acquisition the platform combines Stytch's modern auth with Twilio's communications infrastructure, repositioning it as a credible Auth0 alternative for developer-focused teams. Below 500k MAU the case is strong for both B2C and B2B SaaS; beyond that, gaps on FedRAMP, FGA, and adaptive MFA depth narrow it.
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