FIDO2 and passwordless: how passkeys actually work

Every password ever typed has the same design flaw: it is a shared secret. The site stores something derived from it, you memorize it, and you hand it to whatever page asks, every time, forever. Reuse: nobody keeps a unique unguessable string per account, so one dumped forum unlocks email, banking, and work. Phishing: a secret you must type into any convincing page is one you will eventually type into the wrong one. Server-side compromise: even hashed properly, a password database is a warehouse of future logins, crackable at leisure.

FIDO2 is the industry's attempt to delete the flaw rather than manage it: replace the shared secret with a per-site key pair, of which the server only ever holds the public half. This is the concept post — the stack, the ceremony, the passkey story, what passwordless doesn't fix. For what a second factor buys you, the factors primer has the background; for the hardware itself, that is the hardware keys guide, and this post will try to stay off its lawn.

The three specs that make up FIDO2

FIDO2 is an umbrella, not one protocol. The FIDO Alliance — founded in 2012 to reduce the world's over-reliance on passwords — develops it jointly with the W3C, and it lands as three specifications.

WebAuthn is the browser API, a W3C Recommendation since 2019. It defines how a site requests a credential, the shape of the challenge and the signed response, and which credentials a browser may offer to which site — everything the open web needed for passwordless login without plugins. The specification is unusually readable.

CTAP2, the Client-to-Authenticator Protocol, is the layer underneath: WebAuthn is the conversation between site and browser, CTAP2 the conversation between the browser and the key in your hand, over USB, NFC, or Bluetooth. Yubico's developer site documents it down to the bytes. It matters only for roaming authenticators, the keys carried between machines; a phone's secure enclave or a laptop's TPM is reached through the operating system.

CTAP1, better known as U2F, is the legacy — the 2014-era protocol behind FIDO's first keys, still listed because old U2F keys work under WebAuthn, the platform translating between old and new.

What a passkey login actually does

There are two ceremonies, and neither contains a password.

Registration: the site asks for a new credential, the browser relays to an authenticator, and the authenticator mints a fresh key pair for exactly this site. It returns the public key and a credential ID — an opaque handle — and keeps the private key sealed where it was generated, behind a touch, a PIN, or a biometric. The server stores the username, the credential ID, and the public key: the entire enrollment. No secret crosses the wire, because there is no shared secret to share.

Authentication: the server sends a random challenge, a number it has never used before. The browser bundles it with the origin it is genuinely connected to and hands it to the authenticator. You touch, or enter the PIN, or show your face; the authenticator signs; the server checks the signature against the stored public key. You are in, and the server learned nothing useful for impersonating you tomorrow.

A stolen credential table, unlike a stolen password table, is just public keys, worthless for signing anything: stealing the credential store stops being an attack.

Origin binding, the anti-phishing property

Every credential is scoped to an RP ID, a registrable domain, and the browser only puts the credential up for a page whose origin matches. That is the whole anti-phishing argument: a relay proxy on a look-alike domain can forward the challenge but cannot make the authenticator sign for the real site's domain — and there is no code to retype, because nothing human-readable is ever displayed. Where that lands against the attacks that actually work is ranked in how 2FA gets bypassed.

Discoverable credentials and user verification

A classic hardware-key login still asks who you are: you type a username, the site looks up your key. A discoverable credential — the older name is resident key — stores the credential ID and a user handle on the authenticator itself, so the site can ask whether any of its passkeys live on this device and offer an account picker: usernameless login. The trade is storage — hardware keys budget a fixed number of slots; phones are generous.

The other knob is what the device checks of you. User presence is the touch — proof that somebody warm is at the key, nothing more. User verification is the PIN or biometric, an attempt to prove which somebody; the biometric never leaves the device, the authenticator just sets a flag in the signed assertion — an argument biometric 2FA makes in full. Passkey flows generally require verification; classic key flows often settle for presence.

Passkeys are synced credentials

"Passkey" is a marketing word with a technical core: a WebAuthn credential that syncs. Apple syncs them end-to-end through iCloud Keychain, Google through Google Password Manager, and password managers have piled in since. Syncing is the pitch: lose the phone, buy a new one, sign into the ecosystem account, and your passkeys re-provision. A device-bound key offers no such mercy — lost means re-enrolling everywhere, which is why the hardware guide says buy two.

The honest trade: syncing moves the crown jewels from your pocket to your ecosystem account — whoever recovers or compromises it inherits every passkey synced to it. Both vendors encrypt the synced material, but that guards the cloud copy, not the account. A synced passkey bottoms out in the ecosystem account and its recovery path, which often still ends at a text message: the passwordless future, guarded in the last mile by the phone number.

The other trick is signing in on a machine that holds none of your credentials: the cross-device flow, hybrid transport in the spec, has the borrowed PC display a QR code, your phone scan it, and the two run a Bluetooth handshake proving physical proximity before the phone relays the signature. The proximity check is what stops a remote attacker relaying the exchange — and why the flow dies when either radio is off.

Microsoft's passwordless arc

Microsoft has spent a decade as the loudest of the big three about killing the password. Windows Hello signs you into the machine with a PIN or a face, backed by the TPM; the PIN looks like a weak password but behaves like the opposite — device-local, never transmitted, throttled in hardware — and Microsoft's Hello documentation is blunt that it is not one. Microsoft accounts can go fully passwordless too: remove the password under Advanced security options, and sign-ins proceed through the Authenticator app, Windows Hello, or a hardware key — the passwordless overview walks the ladder.

The direction of travel is not subtle: in May 2022, Apple, Google, and Microsoft jointly committed to expanded FIDO support; Apple shipped passkeys with iOS 16, Google turned them on for Google Accounts in 2023. The big three want passwords gone. Each still operates the recovery side doors passwordless cannot touch — the final stop.

What passwordless doesn't fix

Recovery, first: the strongest login ceremony ever standardized still ends at the "forgot everything" flow, staffed by helpdesk humans, security questions, and legacy systems — a passwordless front door does not repair a side door that resets factors over a phone call. Second, synced passkeys inherit the ecosystem account's weaknesses — the master-key risk reappears one level up, in that account's recovery path.

Third, support is uneven: passkeys exist on the major platforms, but the long tail — banks, utilities, insurers, internal tools, half the SaaS market — still offers TOTP or nothing. For the years that rollout takes, TOTP remains the universal layer: every service with a two-factor option speaks it, it works offline, and no vendor owns it. That is the honest division of labor. If you want to see that layer with zero commitment, the guest generator computes codes in the page: paste a secret, an otpauth link, or a QR image, and the current code appears — no account, no requests, nothing stored.

FIDO2 is the first mainstream authentication design in thirty years that removes the shared secret instead of moving it. The ceremony is standardized, the browsers and phones ship it; what remains is the rollout and the side doors. Until both finish, the strong position is boring: passkeys on the services that have them, a spare key in the drawer, and TOTP for the rest of the internet.

Frequently asked questions

What is FIDO2 in simple terms?

A pair of open standards, plus a legacy one, that replace passwords with per-site cryptographic key pairs. WebAuthn is the browser API; CTAP2 is how the browser talks to a hardware key over USB, NFC, or Bluetooth. The server stores only public keys, the private keys never leave your devices, and each login is a signature over a one-time challenge — nothing shared, nothing to steal, phish, or reuse.

Is WebAuthn the same as FIDO2?

Not quite. FIDO2 is the umbrella name: WebAuthn is the W3C-standardized component covering the site-to-browser conversation; CTAP2 covers the browser-to-key conversation. A platform authenticator such as a phone or laptop TPM uses WebAuthn without CTAP2 at all; a roaming hardware key needs both. The terms get used interchangeably, and nothing breaks.

Are passkeys and security keys the same thing?

Both are FIDO2 credentials with an identical ceremony underneath. A security key holds device-bound credentials on a token — nothing syncs, and a lost key means re-enrolling everywhere, which is why you register two. A passkey syncs through your ecosystem, surviving device loss at the price of the ecosystem account becoming the thing to protect.

Can a passkey be phished?

The credential itself, no. Origin binding means a look-alike domain cannot obtain a valid signature for the real site, and there is no code to type into the fake page. Attackers go around it: recovery flows, helpdesk social engineering, or the ecosystem account that syncs your passkeys. The front door is fixed; the side doors are a separate project.

Do passkeys replace authenticator apps?

Where a service supports them, yes, and they beat typing a code. But most of the internet still offers TOTP-only two-factor — banks, forums, internal tools — and TOTP works offline with no vendor involved. Most people in 2026 run both: passkeys on the majors, TOTP for the long tail.