FIDO2 and passkeys explained — phishing-resistant authentication, finally usable

How passkeys differ from "regular" FIDO2

A FIDO2 credential is a public/private keypair scoped to one website. Originally the private key lived only on one device (a YubiKey, a phone) — losing the device meant losing access. Passkeys add cross-device sync via the platform credential manager:

• Discoverable credential — the credential is identified by the user's account, not by a username typed in. Enables one-tap sign-in.
• Backed-up + synced — Apple syncs via iCloud Keychain; Google via Password Manager; Microsoft via Windows Hello + cloud account; 1Password / Dashlane / Bitwarden also support sync.
• Cross-device authentication — sign in on a laptop using the passkey on your phone via a QR code + Bluetooth handshake.

The flow, in 4 steps

A typical passkey sign-in:

1. Site renders sign-in page. JavaScript calls:
     navigator.credentials.get({
       publicKey: {
         challenge: <random bytes from server>,
         rpId: "example.com",
         allowCredentials: [...]  // empty for discoverable credentials
       }
     })

2. Browser shows the OS-native passkey UI. User selects credential
   + provides local user verification (Face ID, Touch ID, Windows Hello PIN).

3. Authenticator signs the challenge with the private key.
   Returns signed assertion + credential ID.

4. Server verifies the signature against the registered public key.
   Issues a session cookie. Done.

Why phishing becomes structurally impossible

A FIDO2 credential is bound to the relying party origin. The browser refuses to use the credential on any site whose origin doesn't match. Even if the user is tricked into visiting `evil.example.com`, the browser will not present the `example.com` credential. There is nothing the user can do to override this — no equivalent of "typing the password into the wrong site." The phishing attack has to compromise the device itself (a much higher bar) to extract the credential.

Implementation considerations for relying parties

If you're adding passkey support:

• Use a library. SimpleWebAuthn (TS/JS), webauthn-server (Java), py_webauthn (Python). The spec is detailed; library bugs are someone else's problem.
• Allow multiple passkeys per account. Users register one on their phone, one on their laptop. Plus a hardware security key as a recovery credential.
• Discoverable credentials by default. Skip the "type your username" step — go straight to the passkey picker.
• Don't over-attest. Only require platform attestation if you're a high-stakes service (banking, government). For consumer products, attestation is privacy-leaking and rarely needed.
• Account-recovery flow. What happens when the user loses all their devices? Avoid email-only fallback that downgrades the security posture — pair with backup codes or hardware security key.

Where passkeys leave gaps

Real considerations that aren't solved yet:

• Cross-vendor sync. A passkey created on iPhone doesn't automatically appear on a non-Apple device. Cross-platform sync via 1Password / Bitwarden bridges this, but isn't universal.
• Account recovery. If you lose all your devices, the relying party still has to authenticate you somehow. The replacement-credential flow is on the RP, not on FIDO.
• B2B-managed authenticators. Workforce IT wants to revoke a credential when an employee leaves. Synced passkeys complicate this (they're in the user's personal iCloud). Solution: workforce uses hardware security keys or platform passkeys bound to managed accounts.