Passkeys and WebAuthn: How Passwordless Login Works

WebAuthn stopped being a standards-track work in progress in August 2026, when the W3C published Level 3 of the specification as a full Recommendation. The mechanism underneath it is unglamorous and effective: a fresh key pair for every site, with the private half never leaving the authenticator, and a signature that commits to the exact origin asking for it. What passkeys do not fix is the account-recovery path sitting behind them, which is where most rollouts still leak.

What a passkey actually is

A passkey is a WebAuthn public key credential that a user can discover and select without typing an identifier first. The authenticator (your phone’s secure element, a laptop’s TPM, a hardware key) generates an asymmetric key pair scoped to one relying party. The server stores the public key and a credential ID. There is no shared secret on the server, so a database dump yields nothing an attacker can replay.

The Web Authentication Level 3 specification reached Recommendation status on 25 August 2026, following Candidate Recommendation snapshots earlier in the year. Level 3 is an incremental revision rather than a redesign, which matters commercially: implementations written against Level 2 keep working.

The two ceremonies, step by step

WebAuthn defines exactly two operations. Registration creates a credential; authentication proves possession of one.

1. Registration begins when your server issues a random challenge and the page calls navigator.credentials.create() with PublicKeyCredentialCreationOptions, including your relying party ID.
2. The client picks an authenticator matching the criteria you asked for (platform, cross-platform, resident credential, user verification required).
3. The user performs an authorization gesture: a fingerprint, a face scan, a device PIN. This is user verification, not identification.
4. The authenticator generates the key pair, stores the private key, and returns the public key plus authenticator data and, where supported, an attestation statement.
5. Your server verifies and stores the public key, credential ID, signature counter and flags against the user account.
6. Authentication starts with a new random challenge and navigator.credentials.get().
7. The authenticator signs a hash of the client data JSON plus authenticator data, and returns an assertion.
8. Your server checks the signature against the stored public key, confirms the challenge matches the one it issued, and confirms the origin and RP ID hash are yours.

Why the phishing resistance is structural

The client data JSON that gets signed contains the operation type, the challenge, the serialized caller origin, a cross-origin flag and, in cross-origin contexts, the top origin. The browser fills in that origin field. The page cannot lie about it, because the browser is the one writing it.

On top of that, the RP ID must equal the caller’s effective domain or be a registrable domain suffix of it. A credential registered for example.com cannot be exercised by example.com.attacker.net. There is nothing for a user to get wrong and nothing for a reverse proxy to relay, which is what separates passkeys from TOTP codes and push approvals. An adversary-in-the-middle kit that happily harvests one-time codes gets a signature bound to its own hostname, which your server rejects.

Level 3 also broadens what a single credential can cover. Reporting on the specification notes that related origin requests let one passkey serve a set of related domains, which is useful if you run country-code variants of the same product.

Synced versus device-bound, and where attestation fits

WebAuthn describes credentials as either multi-device or single-device, signalled by two flags in authenticator data: backup eligibility, fixed at creation, and backup state, which changes as the credential is actually replicated. Synced passkeys are the multi-device case, replicated by Apple, Google or a password manager through their own cloud channels.

Attestation is the part teams most often misread. FIDO’s own guidance is explicit that synced passkeys do not currently provide attestations. Enterprise attestation, which returns a persistent authenticator identifier you can inventory, has to be burned into the device at manufacture, and the same paper states that authenticators carrying it “must not be sold on the open market and may only be supplied directly from the authenticator’s manufacturer to the RP.” If your compliance story depends on proving which physical device holds a key, you are buying hardware through a procurement channel, not enabling a flag.

What large deployments have published

The FIDO Alliance launched its Passkey Index on 14 October 2025, pooling data from Amazon, Google, LY Corporation, Mercari, Microsoft, NTT DOCOMO, PayPal, Target and TikTok. Across those deployments an average of 93% of accounts were eligible for passkeys, 36% had one enrolled, and 26% of all sign-ins used one. Passkey sign-ins showed a 93% success rate against 63% for other methods, averaged 8.5 seconds versus 31.2 seconds, and participants reported an 81% reduction in login-related help desk incidents.

Run the arithmetic on a mid-sized service handling 500,000 sign-in attempts a month. At a 63% success rate, roughly 185,000 attempts fail and get retried, reset or abandoned. Move all of that volume to a 93% success rate and failures drop to about 35,000. That 150,000-attempt swing is the entire business case, and it shows up in support cost and conversion before it shows up in a breach report.

Availability across the wider web is thinner. A census of the Tranco top 100,000 sites, measured as of March 2025, found 11.3% supported passkeys, rising to 20% among the top 100 and falling to 6.9% in the 50,000 to 100,000 band. Three-quarters of that support came via external identity providers rather than first-party WebAuthn, and only 4.5% of sites exposed a visible passkey button. The researchers stress that passkeys are overwhelmingly offered alongside passwords, not instead of them.

The recovery problem nobody has solved

A passkey removes the phishable secret from the sign-in flow. It does not remove it from the account. If a user who loses every device can get back in with an emailed link and a birthdate, the account’s real security level is the security of that link. Microsoft’s identity team has argued the same point publicly, framing passkeys as a start rather than the finish line and pointing at fallbacks and recovery as the unfinished work.

Per the FIDO Alliance Passkey Index, “passkey sign-ins have a 93% success rate, compared to 63% for other methods” across the nine participating deployments.

Practical friction is real too. Enrolment discovery is poor when the only affordance is a button below the password field. Cross-ecosystem movement, an Android user switching to iOS, still depends on provider tooling rather than the spec. Shared accounts, kiosk devices and support staff who legitimately need to act on a customer’s behalf all fit the password model better than they fit the passkey model. And the backup state flag can flip: a credential created as backup-eligible may sit on exactly one device until the user signs into their platform account somewhere else.

A sane rollout order for a small product team

Ship passkeys as an additional factor first, on top of existing sign-in, and instrument enrolment. Read the backup eligibility and backup state flags and store them, because you cannot reason about recovery risk without knowing whether a user has one copy of their key or several. Prompt for enrolment after a successful sign-in rather than during it. For admin, billing and production-access accounts, require device-bound authenticators and buy the hardware. Then, before you talk about going passwordless, rebuild recovery: identity verification proportionate to what the account controls, a second enrolled passkey on a different device as the default answer, and an explicit decision about whether emailed magic links stay in the flow at all. Until recovery is as strong as the front door, a passkey rollout has moved the attack rather than ended it.

Sources

• W3C — Web Authentication: An API for accessing Public Key Credentials Level 3
• W3C — Invitation to implement WebAuthn Level 3
• FIDO Alliance — FIDO Alliance Launches Passkey Index
• FIDO Alliance — Attestation white paper (Enterprise Deployment Working Group)
• arXiv — State of Passkey Authentication in the Wild: A Census of the Top 100K Sites
• Microsoft Entra blog — Passkeys aren’t the finish line: eliminating fallbacks and fixing recovery
• PPC Land — WebAuthn Level 3 and related origin requests