WebAuthn vs FIDO2 vs Passkeys: Term Map and Rollout

WebAuthn, FIDO2 and passkeys are three names for different layers of the same technology, and teams that use them interchangeably end up writing policies, RFPs and audit evidence that do not say what they mean. WebAuthn is a W3C browser API, FIDO2 is the FIDO Alliance umbrella name for WebAuthn plus the Client to Authenticator Protocol (CTAP), and a passkey is a type of credential that those protocols create and use. The confusion has real consequences: an admin console labelled "FIDO2" may accept synced passkeys you did not intend to allow, and a requirement for "passkeys" may be met by a credential that cannot reach the assurance level an auditor expects. This guide gives a precise term map, explains where passkeys sit in the stack, sets out the threat model and failure modes at each layer, and ends with a rollout decision table and the misconceptions to correct in policy documents. It is for identity architects, IAM engineers, security policy owners and anyone writing procurement or audit language. Protocol internals are in the FIDO2 and WebAuthn Internals Guide; this page does not repeat them.

Key takeaways

Three layers, not three options: WebAuthn is the API a website calls, CTAP is the protocol a client uses to reach an authenticator, and FIDO2 is the name for both together; you never choose between them.
A passkey is a credential, not a protocol: passkeys.dev defines a passkey as the user-facing name for a discoverable credential, the thing older documents call a resident key.
"Passkey" alone does not set assurance: a synced passkey and a device-bound passkey on a security key are both passkeys, but NIST SP 800-63B-4 prohibits exportable keys at AAL3, so only the second can serve there.
Policy must name the property, not the brand word: write requirements in terms of discoverability, user verification, backup eligibility and attestation, which a relying party can check, rather than "FIDO2" or "passkey".
Admin consoles mix the names: identity providers label the same method differently, so map each console setting to the property it controls before you sign off a rollout.

The short answer

FIDO2 is not a competitor to WebAuthn or to passkeys. The FIDO Alliance describes the standards "commonly known as FIDO2" as WebAuthn and CTAP: WebAuthn is the browser API that manages passkeys, and CTAP is implemented by authenticators and client platforms, not by relying parties. A passkey is the credential that sits on the authenticator. The comparison that matters for a rollout is not WebAuthn against FIDO2 against passkeys, but which kind of passkey (synced or device-bound) and which authenticator (platform or roaming) each user population should hold. That second question is covered in depth in Passkeys vs Hardware Security Keys; this page gives the vocabulary and the decision table that sits on top of it.

Term map

Status checked on 14 November 2026 against the W3C, FIDO Alliance and passkeys.dev sources listed at the end.

Term	Defined by	What it is	Who implements or touches it
FIDO U2F (CTAP1)	FIDO Alliance	The original second-factor protocol with a binary, APDU-like message format; CTAP 2.2 calls it CTAP1/U2F and says CTAP2 authenticators should still implement it for backwards compatibility	Older security keys and services that only do second factor
FIDO UAF	FIDO Alliance	A separate FIDO protocol for app-based authentication; the FIDO Alliance counts credentials in UAF apps as device-bound passkeys. See FIDO UAF	Native mobile apps, mostly in banking and telecoms
FIDO2	FIDO Alliance	The umbrella name for WebAuthn plus CTAP2; not a separate specification you can implement on its own	Marketing, procurement and admin consoles
WebAuthn	W3C	The Web Authentication API (navigator.credentials.create() and get()); Level 3 became a W3C Recommendation on 25 August 2026	Relying party developers, browsers and operating systems
CTAP2 (CTAP 2.x)	FIDO Alliance	The client to authenticator protocol using CBOR messages over USB HID, NFC, Bluetooth Low Energy and hybrid transports; CTAP 2.2 is a Proposed Standard dated 14 July 2025	Authenticator makers and client platforms, never the relying party
Discoverable credential	W3C WebAuthn	A credential usable when the relying party supplies no credential IDs; historically called a resident credential or resident key, a name kept in API fields such as residentKey	Relying party developers setting residentKey
Server-side credential	W3C WebAuthn	A non-discoverable credential that works only when the relying party supplies its credential ID, so the user must be identified first; typical of second-factor security key use	Relying parties using WebAuthn as a second factor
Passkey	FIDO Alliance, passkeys.dev	The user-facing name for a discoverable credential; the WebAuthn Level 3 terminology lists "Passkey" as a deprecated synonym and uses "discoverable credential" as the normative term	End users, product and help desk teams
Synced passkey	FIDO Alliance, passkeys.dev	A passkey copied across a user's devices through a passkey provider's cloud service; in WebAuthn terms a multi-device credential (backup eligible)	Passkey providers, end users
Device-bound passkey	FIDO Alliance, passkeys.dev	A passkey that never leaves one authenticator, such as a security key; formerly "single-device passkey"; in WebAuthn terms a single-device credential	Security key holders, high-assurance populations
Platform authenticator	W3C WebAuthn	An authenticator built into the device, such as a laptop TPM or phone secure element	Operating systems
Roaming authenticator	W3C WebAuthn	An authenticator off the device, reached over USB, NFC or Bluetooth, usually called a security key; a phone can act as one through cross-device authentication	Security key makers, phones
Hybrid transport and cross-device authentication	FIDO Alliance (CTAP 2.2)	Lets a passkey on one device, usually a phone, sign the user in on another device; CTAP 2.2 describes QR-initiated and state-assisted hybrid modes	Clients and phones
Passkey provider	passkeys.dev	An app or service that stores and manages passkeys; first-party providers ship with the operating system, third-party providers plug in through platform APIs. See Passkey Providers	Operating systems, browsers, password managers
Conditional UI and conditional create	W3C WebAuthn, passkeys.dev	Autofill-style passkey sign-in on fields marked webauthn, and passkey creation offered after a successful sign-in with another method ("passkey upgrades"). See Passkey Autofill and Conditional UI	Relying party front-end developers
Attestation and AAGUID	W3C WebAuthn, FIDO Metadata Service	An optional statement of authenticator origin, and the 128-bit identifier of the authenticator model it refers to	Relying parties enforcing which authenticators are allowed

Where passkeys sit in the stack

Read the stack from the user outwards. The user unlocks an authenticator with a fingerprint, face or device PIN. The authenticator holds a private key that it generated for one relying party ID. If the authenticator is built into the device, the operating system reaches it directly; if it is a security key or a phone, the client reaches it over CTAP on USB, NFC, Bluetooth or hybrid. The browser or operating system exposes WebAuthn to the website, writes the calling origin into the signed client data and refuses to use a credential for a domain it was not created for. The relying party server issues a challenge, receives the signed response and verifies it.

A passkey is the key pair and its metadata on that authenticator, specifically a discoverable one, so the user can sign in without typing a username first. Two consequences follow. First, a WebAuthn credential is not automatically a passkey: a server-side credential registered as a second factor after a password is WebAuthn and FIDO2, but not a passkey in the passkeys.dev sense. Second, a passkey is not tied to one storage model: it may live in a provider's sync fabric or be locked to one security key. WebAuthn Level 3 lets the server tell these apart at runtime through the backup eligibility (BE) and backup state (BS) flags; the FIDO2 and WebAuthn Internals Guide explains how to read them.

Layer by layer: threat model, failure modes and controls

WebAuthn: the relying party layer

Threat model: the attacker controls a look-alike site or relays traffic in real time. WebAuthn defeats this only if the server checks origin, RP ID hash, challenge and flags; the browser does its part, the server must do the rest.
Failure modes: loose origin matching, reused challenges, ignoring the user verification (UV) flag, and leaving phishable fallbacks enabled so attackers simply pick them.
Controls: a maintained server library, single-use server-side challenges, exact origin checks, a UV policy per population, and removal of fallbacks once coverage allows. This maps to ATT&CK T1557 Adversary-in-the-Middle and T1111 Multi-Factor Authentication Interception.

CTAP: the authenticator transport layer

Threat model: a stolen or cloned authenticator, a guessed PIN, or a nearby attacker during cross-device sign-in.
Failure modes: buying keys that only speak CTAP1/U2F and then discovering they cannot hold discoverable credentials, or assuming every key supports the CTAP 2.1 or 2.2 features your policy needs. CTAP 2.2 also notes that clientPIN can provide user verification but does not establish user presence on non-NFC transports, a detail that matters when you write gesture requirements.
Controls: procure against a stated CTAP version and feature list, require PIN or built-in biometric user verification, and keep the PIN retry limits the authenticator enforces. See the Hardware Security Keys Guide.

Passkey: the credential layer

Threat model: takeover of the passkey provider account that syncs the credential, malicious enrolment through recovery, or unauthorised export. The FIDO Alliance itself cautions that passkeys backed by passwords or synced across devices are vulnerable to theft.
Failure modes: allowing synced passkeys for populations that need AAL3, treating the provider's account recovery as outside your threat model, and a help desk that resets users back to a weaker method.
Controls: decide synced or device-bound per population, enforce it with attestation and AAGUID restrictions where the IdP supports them, harden recovery, and alert on new credential registration for privileged users. See Passkey account recovery.

Comparison at a glance

Dimension	WebAuthn	FIDO2	Passkey
Kind of thing	Browser and platform API specification	Umbrella name for WebAuthn plus CTAP2	Credential type (discoverable credential)
Standards body	W3C Web Authentication Working Group	FIDO Alliance	Term from the FIDO Alliance and platform vendors; normative term in WebAuthn is "discoverable credential"
What a policy can check	Origin, RP ID, challenge, UP and UV flags	Nothing on its own; it is a label	Discoverability (credProps), BE and BS flags, attestation and AAGUID
Phishing resistance	Provided when the server verifies the response correctly	As for WebAuthn	Inherited from WebAuthn origin binding, synced or not
Assurance ceiling (SP 800-63B-4)	Depends on the authenticator	Depends on the authenticator	Synced: AAL2 at most. Device-bound on a qualifying authenticator: can support AAL3

How identity providers label it

Identity providers are listed alphabetically; the order is not a ranking. Each uses its own label for the same WebAuthn method, which is one reason policy documents drift.

Identity provider	Console label	Settings that decide which passkeys are accepted
Microsoft Entra ID	Passkey (FIDO2), under Authentication methods policies	Enforce attestation; key restriction policy by AAGUID; passkey profiles that set attestation, passkey type and AAGUID rules per target group. Microsoft's documentation notes that synced passkeys do not support attestation and that AAGUID lists are a policy guide rather than a strict control when attestation is off
Okta Identity Engine	FIDO2 (WebAuthn) authenticator	User verification (Discouraged, Preferred, Required); authenticator groups built from FIDO Metadata Service entries by name or AAGUID and used in enrolment policies; a Block Passkeys for FIDO2 (WebAuthn) Authenticators setting for passkeys on unmanaged devices

The practical point: a console called "FIDO2" or "Passkey (FIDO2)" accepts whatever its attestation, AAGUID and type settings allow, which may include synced passkeys. Deployment steps for both are in Workforce Passkeys in Entra ID and Okta.

Writing requirements that mean what you intend

Replace brand words in policies, RFPs and audit criteria with the property you actually need. The left column is a common phrase; the right is wording a relying party or IdP can enforce and an auditor can test.

Phrase that causes trouble	Enforceable wording
"Users must use FIDO2"	"Users authenticate with a WebAuthn credential with user verification required; SMS, voice, email OTP and push approval are disabled for this group."
"Administrators must use passkeys"	"Administrators use a single-device (not backup eligible) discoverable credential on an authenticator whose AAGUID is on the approved list, verified by attestation at registration."
"Support passkeys" (customer RFP)	"Support discoverable credentials, conditional mediation for sign-in, and registration of at least two credentials per account, with self-service removal."
"FIDO2 security keys"	"Roaming authenticators implementing CTAP 2.1 or later, FIDO certified, with PIN or built-in biometric user verification, holding at least [N] discoverable credentials."
"Phishing-resistant MFA" with no detail	"Cryptographic authentication bound to the verifier's origin, meeting the phishing resistance requirements of NIST SP 800-63B-4, at AAL2 for workforce and AAL3 for privileged roles."

Rollout decision table

Use this after the vocabulary is settled. It gives the default credential and the properties to enforce; the Passkey Rollout Guide covers phasing, enrolment and recovery.

Population or situation	Credential	User verification	Attestation and AAGUID	Assurance target
General workforce on managed laptops and phones	Synced or platform passkey	Required	Optional; synced passkeys usually return none	AAL2
Privileged administrators, break-glass and finance approvers	Device-bound passkey on a security key	Required	Required; approved AAGUID list	AAL3
Shared or frontline devices	Device-bound passkey on a personal security key	Required (PIN)	Required	AAL2 or AAL3. See Passwordless for Frontline and Shared Devices Guide
Contractors on unmanaged devices	Security key issued by you, or synced passkey if risk allows	Required	Required if keys are issued	AAL2
Consumers	Synced passkey, offered through conditional create	Preferred or required by risk	Do not require	AAL2 for sensitive actions. See Magic Links vs OTP vs Passkeys
Existing U2F second-factor estate	Keep server-side credentials during migration, then register discoverable credentials	Move to required	Keep existing list	Raise to AAL2 or AAL3 as fallbacks are removed

Small and large organisations: a small organisation can often rely on one IdP setting with synced passkeys for everyone and a handful of security keys for administrators. A large or regulated organisation needs per-group profiles, attestation for privileged groups, a documented AAGUID list and evidence that phishable fallbacks are disabled, because auditors will ask which credential type each population holds.

Implementation order

Fix the vocabulary: adopt the term map above in your authentication standard and replace "FIDO2" and "passkey" in requirements with the enforceable wording.
Inventory what is registered today: export registered WebAuthn credentials from the IdP with AAGUID, registration date and, where available, backup eligibility, so you know how many are synced, device-bound or legacy U2F.
Set per-population policy: configure UV, attestation and AAGUID restrictions per group in the IdP, starting in a pilot group with the existing method still available.
Test negative cases: try to register a synced passkey into the privileged profile and a non-approved key model; both must fail. Try a fallback method for a group where it should be disabled.
Remove fallbacks group by group: keep the old method configured but disabled for rollback during each phase, then delete it once help desk volumes settle.
Harden recovery last but before go-live for privileged users: a new credential registration for an administrator should need verified identity and raise an alert. See the Account Recovery and Help Desk Security Guide.

Worked scenarios

Scenario 1, the audit finding: a policy says "all administrators use FIDO2 passkeys". The IdP's passkey method has attestation off and no AAGUID list, and several administrators registered synced passkeys from their personal phones. Every sign-in was phishing-resistant, but the organisation cannot claim AAL3 for those accounts, and the administrators' recovery now depends on a consumer provider account outside its control. The fix is wording ("single-device credential, approved AAGUID, attestation required"), a privileged passkey profile that enforces it, and re-registration of affected administrators with issued keys.

Scenario 2, the customer RFP: a product team asks vendors to "support FIDO2". One vendor's answer is accurate but describes only second-factor security key support with server-side credentials, so customers would still type a password first. The requirement should have asked for discoverable credentials, conditional mediation and conditional create, which is what the team meant by passkeys.

Misconceptions to correct

"Passkeys replaced FIDO2": passkeys are built on FIDO2; the FIDO Alliance says so directly. Nothing was replaced except the user-facing name.
"Synced passkeys are not phishing-resistant": they are; the FIDO Alliance states phishing resistance holds whether or not keys are bound to hardware. What changes is exportability and therefore the assurance ceiling and the recovery threat model.
"A security key is not a passkey": since 2019, according to the FIDO Alliance, security keys can hold device-bound passkeys as discoverable credentials with user verification.
"WebAuthn means passwordless": WebAuthn also supports second-factor use with server-side credentials; passwordless needs discoverable credentials and user verification.
"Passwordless equals phishing-resistant": magic links, push and SMS sign-in are passwordless but not phishing-resistant. See Passwordless vs Phishing-Resistant MFA.

Detection and measurement

Credential mix by population: share of privileged accounts whose only credentials are single-device and on the approved AAGUID list; the target is 100 per cent.
Phishable method exposure: number of accounts in passkey-only groups that still have SMS, OTP or push registered.
User verification rate: share of WebAuthn sign-ins with UV set, by group.
Policy drift: alerts on changes to the IdP passkey policy, attestation setting or AAGUID list.
Registration anomalies: new credential registrations for privileged users outside a recovery ticket, and registrations with an unrecognised AAGUID.

Common failure patterns

Policy written in brand words: "FIDO2" or "passkeys" in a standard with no stated properties, leaving the IdP default to decide what is accepted.
Assuming the console label means device-bound: a method named for FIDO2 accepting synced passkeys because attestation is off.
Buying U2F-only keys for passwordless: keys that cannot hold discoverable credentials, discovered after distribution.
Counting second-factor WebAuthn as a passkey rollout: users still type passwords, which remain phishable and reusable elsewhere.
Leaving relayable fallbacks on: real-time phishing of passwords and one-time codes, as in the Twilio breach, works against any account that still has those methods, regardless of how many passkeys it also holds.

Framework mapping

Framework	Reference	How the terms map
NIST SP 800-63B-4	AAL2 and AAL3, syncable authenticators	Syncable (exportable) keys permitted at AAL2, prohibited at AAL3. See the NIST SP 800-63B-4 Authenticator Assurance Levels Guide
NIST SP 800-53 Rev. 5	IA-2(1), IA-2(2), IA-2(8), IA-5(2)	MFA for privileged and non-privileged accounts, replay resistance, public key-based authentication
NIST CSF 2.0	PR.AA-03	Users, services and hardware are authenticated
CISA guidance	Implementing Phishing-Resistant MFA fact sheet	Names FIDO/WebAuthn as the only widely available phishing-resistant authentication, with PKI-based MFA as the less widely available alternative. See Certificate-Based Authentication vs FIDO2
MITRE ATT&CK	T1557, T1111, T1539	Relay and MFA interception are countered by WebAuthn origin binding; session cookie theft after sign-in is not

Practitioner checklist

Adopt one term map in your authentication standard and use "discoverable credential", "single-device" and "multi-device" in normative text.
Rewrite every requirement that says only "FIDO2" or "passkey" into checkable properties: UV, discoverability, backup eligibility, attestation, AAGUID.
Map each IdP console setting to the property it enforces and record the mapping with the policy.
Decide synced or device-bound per population and enforce it with attestation and AAGUID lists where the assurance target is AAL3.
Procure security keys against a CTAP version, certification and discoverable credential capacity, not "FIDO2" alone.
Inventory registered credentials, including legacy U2F server-side credentials, before changing policy.
Disable phishable fallbacks per group once coverage allows, keeping a disabled configuration for rollback.
Alert on new credential registration and on passkey policy changes for privileged groups.

WebAuthn vs FIDO2 vs Passkeys: A Term Map and Rollout Decision Table