Passwordless Authentication: FIDO2, WebAuthn and Passkeys Explained

Every password-based system shares the same structural flaw: the secret has to travel. The user types it, the browser sends it, the server stores a representation of it. Each of those steps is a place it can be stolen, and no amount of policy tuning removes them.

Passwordless authentication removes the shared secret entirely. That is the whole idea, and everything else follows from it.

What Passwordless Actually Means

The term gets stretched. A magic link emailed to you is not passwordless in any meaningful sense — it relocates the secret to the mailbox. Neither is a password plus an SMS code; that is multifactor authentication with a password still in it.

True passwordless means no shared secret exists between the user and the service. The standards-based form of this is FIDO2, which has two parts:

• WebAuthn — the browser API that lets a website request authentication from an authenticator.
• CTAP (Client to Authenticator Protocol) — how the browser talks to an external authenticator such as a security key over USB, NFC or Bluetooth.

How the Key Pair Works

At registration, the authenticator generates a new public and private key pair, unique to that site. The private key never leaves the authenticator. The public key goes to the server.

At login, the server sends a random challenge. The authenticator signs it with the private key after the user proves presence — a touch, a fingerprint, a PIN — and returns the signature. The server verifies it against the stored public key.

Three consequences matter, and all three are testable:

1. The server stores no secret. A breach of the authentication database yields public keys, which are useless to an attacker. There is nothing to crack offline.
2. Nothing reusable crosses the network. The signature is over a one-time challenge.
3. Credentials are site-scoped. A separate key pair per relying party means there is no cross-site reuse to exploit.

Why It Resists Phishing

This is the property that sets FIDO2 apart from every other second factor, and it is worth understanding mechanically rather than as a claim.

The authenticator binds each credential to an origin — the actual domain. When the user lands on a lookalike domain, the authenticator simply has no credential registered for that origin and will not respond. The user cannot be talked into approving it, because there is nothing to approve.

Compare that to one-time codes. A real-time proxy sits between the user and the legitimate site, relays the code within its validity window, and captures the resulting session. This is exactly how modern adversary-in-the-middle phishing defeats TOTP, and why "we have MFA" is no longer a complete answer. The tooling is mature and widely available, as reverse-proxy phishing frameworks demonstrate.

Push notification fatigue — repeated prompts until someone taps accept — also has no equivalent here, because approval is bound to an origin the attacker does not control.

Passkeys

A passkey is a FIDO2 credential that syncs across a user's devices through a platform or password manager, rather than living on one hardware key. That solves adoption — users lose devices and refuse to carry tokens — at the cost of some assurance, since the credential now exists in a cloud account.

Device-bound passkeys on hardware security keys remain the higher-assurance option and are the right choice for administrative access. Synced passkeys are the right choice for a general workforce, because a control nobody uses protects nothing.

The Hard Parts

• Account recovery becomes the weakest link. If losing a device drops the user into an email-based reset, the security of the whole system is the security of the mailbox. Register multiple authenticators up front.
• Legacy systems. Applications that cannot speak WebAuthn need federated single sign-on in front of them, so the passwordless login happens once at the identity provider.
• Is one factor enough? A security key with a PIN or biometric is something you have plus something you know or are — genuinely multifactor in one gesture. A key requiring only a touch is a single factor. The distinction matters when mapping to authentication factor requirements.
• Session tokens still matter. Phishing-resistant login does not protect a session cookie stolen afterwards, which is why session hijacking controls remain necessary.

Exam Focus

Know that FIDO2 comprises WebAuthn and CTAP. Know the private key never leaves the authenticator and the server holds only a public key. Know that origin binding is what makes it phishing-resistant, and that TOTP and push approval are not. Recognize passkeys as synced FIDO2 credentials, and recognize account recovery as the control that undermines the whole design when it is left weak.