Passkeys, Explained: Why the Server Can No Longer Hold a Copy of Your Password

The original sin of passwords: the server must hold something that can verify you

The fundamental flaw of passwords isn't weak choices — it's the model. To verify you, the server must hold an equivalent of your secret (even hashed). So every database leak instantly feeds a billion credentials into credential-stuffing dictionaries, and every phishing page harvests the secret straight from your hands. The password generator and strength checker only address "can the secret be guessed" — "can the secret be stolen" was never solved.

Passkeys replace the model itself: the server no longer holds any version of your secret.

How it works: one asymmetric signature at registration, one per login

Passkeys stand on two standards: W3C's WebAuthn (the browser API) and the FIDO Alliance's CTAP2 (the device protocol). Two flows:

Registration (once)

1. The device generates an asymmetric key pair inside a secure chip (TPM / Secure Enclave)
2. The private key never leaves the chip; the public key plus a credential ID go to the site for storage

Login (every time)

1. The server issues a random challenge
2. After the browser confirms the domain, the device asks for user verification (fingerprint / face / PIN)
3. The device signs "challenge + domain hash" with the private key
4. The server verifies the signature with the stored public key

No shared secret ever travels, and no replayable credential exists — a stolen signature can't forge the next one, and a stolen database can't produce a login.

Phishing resistance is structural, not probabilistic

TOTP codes can be relayed in real time by a phishing page (the attacker just asks you for "the 6 digits"). Passkeys can't be phished for a reason baked into the cryptography: the signature covers the target domain's hash (rpIdHash). A passkey registered on github.com simply refuses when invoked from githsb.com — the browser sees the domain mismatch and declines to produce a signature at all. Not "hard for the attacker" — the signature mathematically does not exist.

Capability table across three auth methods

The last row is where passkeys intersect the post-quantum migration: their asymmetric foundation faces the same algorithm rotation, and fortunately WebAuthn's algorithm registry is extensible — a textbook case of crypto-agility.

Synced passkeys vs. device-bound passkeys

• Synced passkeys: the private key syncs across devices via platform keychains (iCloud / Google Password Manager) with end-to-end encryption — you keep your keys when you switch phones, at the cost of trusting the platform account
• Device-bound passkeys: the private key lives in exactly one security key or device, never syncing — the choice for banking and high-security contexts, at the cost of losing the device meaning losing the credential

The three enterprise hurdles

Passkey users passed a billion in 2026 and authentication volumes doubled year-over-year — but enterprise friction isn't about "does it work", it's about operations (the three issues named in KuppingerCole's 2026 report):

1. Enrollment: how to guide existing accounts into adding a passkey (the natural window: password resets)
2. Multi-device: cross-ecosystem sync (Android ↔ iPhone) still relies on QR scans / Bluetooth bridging
3. Recovery: if the account recovery path degrades to SMS or email, that's the weakest link of the whole chain — recovery must match the strength of the primary authenticator

Implementer's note

Writing the site's TOTP tool made me acutely aware of the words "shared secret": TOTP's security depends on the server and client holding the same seed, with the 30-second window acting as a delay lock on top; passkeys dismantle that sharing entirely, at the price of moving trust into hardware. The other realization is the collapse of the strength-scoring mindset: password strength talks about entropy and dictionary attacks, but a passkey has no "guessable space" dimension at all — asymmetric signature security is measured by algorithm and key length, with nothing the user chose involved. That's why NIST-era password guidance shifts wholesale to hardware-side metrics like authenticator assurance levels in the passkey world.

Related reading

• Password generator guide (the previous chapter of the 2FA strength ladder)
• TOTP guide
• Post-quantum migration self-check (the algorithm layer of passkeys)
• JWT vs. sessions (after authentication: how to manage sessions)