What is Passkey Authentication?

Where the word came from

"Passkey" emerged from Apple's 2021 WWDC announcement of a consumer-friendly term for synced FIDO2 credentials. The major platforms — Apple, Google, Microsoft — coordinated through the FIDO Alliance to support cross-device synchronization through 2022 and 2023. By 2024 the major password managers (1Password, Bitwarden, Dashlane) had also added passkey support, and by 2026 most consumer sites that support phishing-resistant authentication describe it to users as a "passkey" regardless of the underlying implementation.

Relationship to FIDO2 and WebAuthn

Underneath, a passkey is a FIDO2 credential created and exercised via the WebAuthn browser API. The cryptography is identical to what hardware security keys have done since the mid-2010s. What changed is the user experience: instead of plugging in a YubiKey, the user authenticates with the same biometric they use to unlock their phone, and the credential lives in a platform secure enclave that the user does not have to consciously manage. The synchronization layer (iCloud Keychain, Google Password Manager, etc.) means the credential is available across the user's devices without the user explicitly enrolling each one.

Synced vs device-bound

The FIDO specs distinguish two flavors. Multi-device passkeys (the typical consumer experience) are synced — the same credential is usable across all the user's devices that share the same platform account. Device-bound passkeys live on a single device and cannot be moved; this is the model used by hardware security keys and by some high-assurance enterprise deployments where keys are explicitly per-device. From the server's perspective the protocol is the same — the difference is the authenticator's attestation about whether the credential is synced or hardware-bound. Enterprise security teams sometimes restrict to device-bound for the highest-tier accounts.

The recovery problem

Designing the recovery path is the hardest part of a passkey rollout. With synced passkeys, recovery is usually "sign in to your iCloud / Google / password manager again" — the credentials come back along with everything else. That covers the majority case but assumes the user can still access their platform account. For higher-risk products (banks, healthcare portals, admin consoles) the right answer is usually a combination of passkeys plus a secondary recovery method — backup codes, a second passkey on a different device, or an out-of-band human verification process. Skipping this design step is how a passkey rollout becomes a customer-support nightmare three months in.

At QUANT LAB

We ship passkey support as a first-class option in our SaaS platforms and custom builds. The typical implementation uses SimpleWebAuthn or a managed provider (Clerk, Stytch, Auth0) and supports passkey-only flows for new users, passkey-as-second-factor for users who still want a password, and explicit registration of additional passkeys for users who want multi-device redundancy without relying on cloud sync.

For healthcare and fintech products we usually layer device-bound passkeys for administrative accounts on top of synced passkeys for end users. Our pen-testing team tests the implementation end-to-end, because a misconfigured WebAuthn flow that falls back to password silently is worse than no passkey at all. Book a call if you are planning a rollout.