Identity & Access · Chapter 12 of 16
Passwordless: FIDO2, WebAuthn and passkeys
The first authentication technology that makes phishing structurally impossible rather than merely harder — and the honest trade-off inside the passkey.
Every authentication factor before this one shares a fatal property: the user can be persuaded to give it to the wrong party. A password, an OTP from an app, a code by SMS, a push approval — all of them can be relayed by a proxy sitting between the user and the real site. Modern phishing kits do exactly this, in real time, and they defeat every form of MFA in that list.
WebAuthn is different in kind, not in degree, and the reason is worth understanding precisely because it is the single most consequential development in authentication in twenty years.
How it actually works
Registration. The server sends a challenge and its own identifier — the relying party ID, essentially the domain. The authenticator — a security key, a phone's secure enclave, a laptop's TPM — generates a brand new key pair specific to that site and that user. The private key never leaves the authenticator. The public key goes to the server.
Authentication. The server sends a challenge. The browser assembles client data that includes the challenge and the actual origin of the page the user is on. The authenticator requires a user gesture — a touch, a biometric, a PIN — and signs. The server verifies against the stored public key and checks that the origin in the signed data is its own.
Why this defeats phishing, stated precisely
On rnicrosoft.com, one of three things happens, and all three are safe.
The authenticator has no credential registered for that origin, so there is nothing to offer and the user cannot proceed.
Or, if an attacker relays the challenge from the real site, the authenticator signs over rnicrosoft.com because that is the origin the browser reports — and the real server rejects the signature because the origin does not match.
There is no secret for the user to type and no code for a proxy to forward. The origin binding is enforced by the browser, which is not susceptible to being convinced that a lookalike domain is the real one. This is why WebAuthn is called phishing-resistant and why OTP-based MFA is not, and it is the distinction worth being able to draw cleanly in any security interview.
Device-bound keys versus synced passkeys — the real debate
The original FIDO2 model kept the private key permanently inside one piece of hardware. That is the highest assurance available and it has an adoption problem: users lose keys, and buying two hardware keys for every employee is a real cost.
Passkeys solve adoption by syncing the private key through a platform account — iCloud Keychain, Google Password Manager, or a third-party password manager. Your credential follows you to a new phone. Adoption rose dramatically as a result.
| Device-bound (security key) | Synced passkey | |
|---|---|---|
| Private key location | Never leaves the hardware | Encrypted, synced through a platform account |
| Assurance | Highest | Depends on the platform account's own security |
| Recovery | Requires a second key or an account-recovery process | Automatic on a new device |
| Adoption | Poor without a mandate | Good |
| The honest risk | Loss and lockout | Your authentication is now only as strong as the Apple or Google account it syncs through |
| Where each belongs | Administrators, privileged access, high-assurance systems | The general workforce and consumers |
The mature position, and a good thing to say out loud: synced passkeys are a very large improvement over passwords and a step down from device-bound keys, and that is an acceptable trade for most users and not for privileged ones. Enterprises that require device-bound keys for administrators and allow synced passkeys for everyone else are making a deliberate, defensible distinction rather than a compromise.
Attestation, and why enterprises care about it
During registration an authenticator can present an attestation statement — cryptographic evidence of what kind of device it is. This lets an enterprise require that credentials come from an approved authenticator model rather than from anything at all.
Note the tension, which is genuine: attestation is a privacy concern for consumer services, because it identifies the device model, and platform authenticators frequently provide little or no attestation for exactly that reason. So an enterprise wanting strict authenticator control is generally pushed toward hardware keys, which do attest. That is a real constraint on policy and it is the sort of detail that separates someone who has deployed this from someone who has read about it.
Deployment realities, which is where these programmes fail
Account recovery is the whole problem. If a user loses every authenticator, how do they get back in? Whatever that path is, it becomes the weakest link — and if recovery falls back to an emailed link or a helpdesk call, you have reintroduced everything WebAuthn removed. Deploying phishing-resistant authentication and leaving a phishable recovery path is a very common and self-defeating outcome.
The workable answers are: enrol two authenticators from the start, and make helpdesk recovery a high-assurance, in-person or video-verified process with its own controls. Both cost money and both are the actual programme.
Legacy applications that only speak passwords or LDAP binds cannot consume WebAuthn. The usual bridge is to put them behind an access proxy or an IdP that does WebAuthn at the front and passes a session backward. That works and it means the underlying password still exists — so it must be randomised, long, and unknown to the user.
Attacker adaptation. As phishing-resistant authentication spreads, attackers move to what is left: session-token theft after authentication, consent phishing for OAuth scopes, help-desk social engineering, and device enrolment abuse. Several major intrusions in recent years went through the help desk precisely because the authentication was too strong to attack directly. Strengthening authentication moves the attack; it does not end it, and saying so is what marks a realistic security practitioner.
Check yourself