Passkeys

A passkey is a cryptographic key pair that replaces the password. The private key stays on your device, in a secure element or a platform credential store; the public key is registered with the service. Logging in means proving possession, not proving knowledge.

Why this is a real improvement

Phishing stops working. The credential is bound to an origin. A page at evil-example.com cannot present a credential registered for example.com, so a perfectly convincing clone of a login page harvests nothing.

There is no secret to reuse or leak. A database breach exposes public keys, which are not secret and not useful. The class of credential stuffing effectively disappears for passkey accounts.

No shared secret to phish. There is nothing for a proxy to relay, so a real-time phishing proxy cannot produce a valid challenge response.

Nothing to type, nothing to reuse. The friction that caused people to work around password managers largely goes away.

How it works, briefly

1. The site issues a challenge scoped to its origin.
2. Your authenticator signs it with a private key held in a secure element, after a user verification step — a fingerprint, a face, a device PIN.
3. The site verifies the signature against the registered public key.

The private key never leaves the authenticator and is not exportable, which is what makes device loss a real risk.

Where it currently hurts

Account recovery is the weak point. If every device holding your passkeys is lost, recovery is the one thing passkeys were supposed to remove. In practice this means:

• platform-bound passkeys depend entirely on the platform account’s recovery
• hardware keys are the strongest option, and you need two of them, stored separately
• sync-based passkeys introduce a company into the trust chain that was supposed to leave

Cross-platform movement is immature. Moving from one ecosystem to another is still awkward, and this is the main reason adoption is uneven.

Shared and work accounts are poor fits. Anyone with the credential can authenticate; there is no way to say “read only”, and no per-person revocation short of regenerating.

Enterprise attestation features have privacy trade-offs. Device posture and organisation binding can be valuable for a company and a data source for anyone else.

Adoption advice

1. Enable passkeys where offered, keeping the password as a fallback initially.
2. Register a hardware key as a second method on anything high-value.
3. Test recovery on a device that is not the one you registered on.
4. Store any recovery codes in your password manager.
5. Expect the support experience to be worse than password login for a while. It is early.

Sources

• Web Authentication Level 3 — the current specification, including resident credentials and attestation policies.
• Web Authentication Level 2 — the level most deployed today, useful for understanding what is actually implemented.
• FIDO passkey developer documentation — the ecosystem’s own description of synchronisation, device binding, and recovery.
• RFC 8555 — PKCE, the related mechanism that stops an authorisation code being redeemed by the wrong client.