FIDO2 and Passkeys: How Phishing-Resistant Authentication Works

FIDO2 replaces the shared secret at the center of authentication with a key pair. The private key never leaves the authenticator, the server stores only the public key, and the browser refuses to use a credential on any site other than the one it was created for. Those three properties together are what make it phishing-resistant, and that phrase means something specific rather than "very secure."

Why shared secrets fail

A password is a secret both sides know, so it can be stolen from either side, guessed, reused across sites, and — most importantly — typed into the wrong site by a user who believed they were somewhere else.

One-time codes improve matters but keep the same shape. A code is still a secret the user reads and transmits, so a user on a lookalike site will enter it, and an attacker relaying the login in real time uses it within its validity window. Push approvals fail differently: repeated prompts eventually get approved by a tired user. Neither TOTP nor HOTP codes solve the fundamental problem, because the user remains the transport for the secret.

What FIDO2 actually does

FIDO2 is two specifications working together. WebAuthn is the browser API that websites call, and CTAP is the protocol between the browser and an external authenticator such as a security key or a phone.

At registration the authenticator generates a key pair specific to that site, keeps the private key, and sends the public key to the server. At authentication the server sends a random challenge, the authenticator signs it with the private key, and the server verifies the signature against the stored public key. Nothing reusable crosses the network in either direction.

The phishing resistance comes from origin binding. The browser includes the actual origin in what gets signed and will only offer a credential registered for that exact origin. A lookalike domain is a different origin, so the credential is simply not available — the user cannot make the mistake, because the browser enforces it rather than asking. This is the property that survives a convincing credential harvesting page, and no code-based factor has it.

Server-side breach exposure also changes. A stolen database of public keys is worthless; there is nothing in it to replay or crack.

Passkeys and what they changed

A passkey is a FIDO2 credential that can be synchronized across a user's devices through a platform account, rather than living on one piece of hardware.

That solves adoption. The original model required buying security keys and registering a backup, and losing the key meant an account recovery process — friction that kept adoption low outside high-security environments. Synchronized passkeys arrive on every device the user already has, with the platform handling backup and recovery.

The trade-off is honest and worth knowing for the exam. A device-bound credential on a hardware key never leaves that hardware, which is the stronger guarantee. A synchronized passkey is only as protected as the platform account holding it, so compromise of that account is compromise of the credentials. High-assurance environments still specify device-bound authenticators; most organizations correctly choose the synchronized version because it is what people will actually use.

Single factor or multi-factor

An authenticator can require user verification — a PIN or a biometric — before it will sign. When it does, one interaction supplies two factors: possession of the authenticator and knowledge or inherence proving the user is present. That is why signing in with a passkey and a fingerprint is genuine multi-factor authentication despite feeling like one step, and it maps cleanly onto the authentication factor categories.

Without user verification, the authenticator proves possession only, which is single factor.

Deployment realities

Registration and recovery are where the security actually lives. An attacker who can register their own authenticator during account recovery bypasses everything above, so recovery must be at least as strong as the primary method — a second registered passkey is far better than a fallback to email or SMS, which reintroduces exactly the weakness you removed.

Require at least two registered authenticators per user. Keep legacy fallbacks available only during migration and then remove them, because a phishable fallback that remains enabled is the path the attacker will take.

Coverage is the other issue: browser and platform support is broad, but legacy applications, some enterprise software, and non-browser clients still need a bridge. In federated environments the usual answer is to require FIDO2 at the identity provider and let applications consume the resulting assertion, which is the practical argument for consolidating on federation first.

Exam angles

Know FIDO2 as WebAuthn plus CTAP, using public key cryptography with the private key held by the authenticator. Identify origin binding as the mechanism that defeats phishing, and be able to explain why one-time codes and push approvals do not have it. Distinguish device-bound security keys from synchronized passkeys and state the trade-off. Recognize that user verification is what makes a single interaction multi-factor, and that account recovery is the weak point to design around.