What is the difference between FIDO2 and WebAuthn?

FIDO2 is the overall specification set from the FIDO Alliance and W3C. It has two components: WebAuthn, the W3C standard defining the JavaScript API a website uses to create and verify credentials, and CTAP, the Client to Authenticator Protocol defining how a browser or operating system talks to an external authenticator such as a USB security key. When someone says a site supports FIDO2, they mean it implements WebAuthn and works with authenticators speaking CTAP.

Is a passkey the same as a WebAuthn credential?

A passkey is a WebAuthn credential that is discoverable, meaning the authenticator stores the credential and its associated user handle so it can offer it without the server providing a credential ID first. That is what enables usernameless sign-in. Earlier WebAuthn deployments often used non-discoverable credentials, where the server sends a list of credential IDs and the authenticator finds the matching key, which requires the user to identify themselves first.

What is the difference between a synced passkey and a device-bound one?

A synced passkey is stored in a credential manager, typically the platform's keychain or a password manager, and replicates across that account's devices. Lose a phone and the passkey is on the replacement. A device-bound passkey exists only on the hardware that created it, usually a security key, and cannot be exported. Device-bound gives a stronger guarantee about where the key is; synced gives a workable recovery story.

Do passkeys replace security keys?

They overlap. A hardware security key holds device-bound passkeys and is the right choice for administrators, high-value accounts and regulated environments where you must be able to attest that the credential cannot leave the hardware. Synced passkeys on a phone or laptop are the right default for ordinary users, because the recovery story is what determines whether people adopt them at all.

Why are all of these phishing-resistant?

Because the signature covers the origin. The authenticator will only produce an assertion for the domain the credential was registered to, and the browser supplies that domain rather than the page. A convincing lookalike site cannot obtain a usable signature, because the credential for the real site simply does not respond to the fake one. That property holds for every credential in this family regardless of what you call it.

What should I actually implement?

WebAuthn, through a well-maintained library for your stack. Support discoverable credentials so passkeys work, allow multiple credentials per account, and do not remove your recovery path before adoption is high. If you serve regulated or administrative users, additionally support attestation so you can require device-bound authenticators for those accounts.

FIDO2 vs WebAuthn vs Passkeys: What Each Name Means

People ask which of these to use as though they were alternatives. They are layers of one stack plus a name for the credential that comes out of it.

Scope: WebAuthn Explained owns the API and the ceremony in detail, Passkeys Explained owns adoption and user experience, and Best Hardware Security Keys owns the devices. This page owns the terminology, because the terminology is what the question is actually about.

The stack

Name	What it is	Who defines it	You interact with it by
FIDO2	The umbrella specification set	FIDO Alliance and W3C	Saying "we support FIDO2"
WebAuthn	The browser API for creating and using credentials	W3C	Calling it from your web application
CTAP2	The protocol between client and external authenticator	FIDO Alliance	Nothing, the platform handles it
Passkey	A discoverable credential created through the above	FIDO Alliance branding	Registering and signing in

Read down that table and the confusion resolves. A developer implements WebAuthn. The browser uses CTAP2 to reach a security key, or an internal platform interface to reach the phone's secure element. Both sit inside FIDO2. What the user ends up with is a passkey.

What WebAuthn does

Two ceremonies.

Registration. The site asks for a new credential. The authenticator generates a key pair, keeps the private key, and returns the public key with a credential ID. The site stores those against the account.

Authentication. The site sends a challenge. The authenticator signs it with the private key, after whatever user verification is configured, and returns the signature. The site verifies it against the stored public key.

The security property that matters is in the details of what gets signed: the assertion is bound to the origin the credential was registered to. The browser supplies that origin, not the page. A phishing site on a lookalike domain cannot get the authenticator to produce anything it can use, because as far as the authenticator is concerned no credential exists for that origin.

That is why every credential in this family is phishing-resistant, and it is a structural property rather than a matter of user vigilance.

What CTAP is for

WebAuthn stops at the browser. Something has to carry the request to a security key over USB, NFC or Bluetooth, and that is CTAP.

For most people building things, CTAP is invisible: browsers and operating systems implement it. It matters when you are choosing hardware, because CTAP2 support is what makes a key a FIDO2 key rather than a legacy U2F device, and it is what enables discoverable credentials and PIN-based user verification.

What makes a passkey a passkey

The technical distinction is discoverability.

In the original model, credentials were non-discoverable. The server sent a list of credential IDs, the authenticator matched one and signed. That works and it requires the user to identify themselves first, because the server has to know which IDs to send.

A discoverable credential stores enough on the authenticator, including a user handle, that it can be offered without the server naming it. That is what allows the sign-in flow with no username: the authenticator presents the accounts it holds for that site and the user picks one.

Passkey is the name the industry settled on for that credential, and it was chosen for users rather than for engineers. It is not a new protocol.

Synced versus device-bound

This is the distinction with real operational consequences, and it is where most decisions actually land.

	Synced passkey	Device-bound passkey
Stored in	Platform keychain or password manager	The authenticator's secure element
Survives losing the device	Yes, restores to a new one	No
Can be exported	Within the provider's ecosystem	No
Recovery depends on	The provider account, and its own security	Your backup authenticator
Attestable	Limited	Yes, you can require specific hardware
Right for	Ordinary users, consumer accounts	Administrators, regulated and high-assurance accounts

The trade is legible. Synced credentials make the credential as strong as the account that syncs it, and they solve the problem that stops people adopting anything: what happens when the phone goes in the river. Device-bound credentials give you a real guarantee about where the private key is and cannot be recovered when the hardware is gone.

For a high-value account, that lack of recovery is the feature. For a consumer, it is the reason they never enrol.

What to do

If you are implementing:

Implement WebAuthn with a maintained library. Do not write the verification yourself.
Support discoverable credentials so passkeys work as users expect.
Allow several credentials per account, and prompt for a second at registration.
Keep a recovery path until adoption is high, and make that path at least as strong as the credential it recovers, since it becomes the weakest link.
If you have administrative or regulated users, support attestation so you can require device-bound authenticators for them.

If you are choosing for yourself:

Synced passkeys for everyday accounts, in whichever ecosystem you already trust with your credentials.
A hardware key with device-bound credentials for email, your password manager, financial accounts and anything administrative.
Two hardware keys, one kept elsewhere. The failure people actually experience is losing their only authenticator.

The verdict

There is no choice to make between FIDO2, WebAuthn and passkeys, because they are not the same kind of thing. FIDO2 is the family, WebAuthn is what you implement, CTAP is how the hardware is reached, and a passkey is what the user ends up holding.

The decision that does exist is synced against device-bound, and it turns on one question: what happens when the device is lost. Answer that per account and the rest of the terminology stops mattering.