Category: FIDO & Passkeys

FIDO2

Also known as: FIDO2, Fast Identity Online 2

Simply put

FIDO2 is an open authentication standard developed by the FIDO Alliance that lets people sign in without passwords. It is designed to support passwordless and multi-factor authentication across mobile and desktop environments, and passkeys are built on top of it. Because it relies on cryptographic credentials rather than shared secrets, it aims to reduce dependence on passwords for verifying who a user is.

Formal definition

FIDO2 is a set of open authentication standards from the FIDO Alliance that enables passwordless and multi-factor authentication for verifying user identities in mobile and desktop environments. It provides service providers a means to implement passwordless authentication, and passkeys are built on FIDO2 specifications. Note that FIDO2 addresses authentication (proving who a principal is) and does not itself define authorization; its exact component specifications and their version numbers are out of scope for this entry based on the available evidence, and specific factor combinations depend on the authenticator and deployment configuration.

Why it matters

Passwords remain one of the weakest links in identity systems because they are shared secrets that can be phished, reused, guessed, or stolen in bulk. FIDO2, as an open authentication standard developed by the FIDO Alliance, matters because it gives service providers a way to move away from password-based verification toward cryptographic credentials, reducing dependence on shared secrets for proving who a user is. This addresses authentication specifically, confirming a principal's identity, and does not by itself govern what that principal is subsequently authorized to do.

For organizations, the significance of FIDO2 lies in its role as the foundation for passkeys, which are built on FIDO2 specifications. As passkeys gain adoption across major platforms and consumer services, FIDO2 becomes the underlying standard that IAM teams need to understand when evaluating passwordless and multi-factor authentication strategies. Its status as an open standard is relevant to interoperability planning, since it is not tied to a single vendor's proprietary scheme.

Because FIDO2 supports both passwordless and multi-factor authentication across mobile and desktop environments, it is applicable to a broad range of deployment scenarios. That said, the specific factor combinations available depend on the authenticator and deployment configuration, so teams evaluating FIDO2 should treat it as a standard to be profiled against their own requirements rather than a single uniform capability.

Who it's relevant to

Security architects

Architects evaluating passwordless and multi-factor authentication strategies need to understand FIDO2 as the open standard underpinning passkeys. Because it is vendor-neutral, it informs interoperability decisions when designing authentication flows across mobile and desktop environments. Architects should scope how FIDO2 handles authentication only, and plan authorization separately.

IAM engineers

Engineers implementing passwordless authentication will encounter FIDO2 as the standard that service providers use to verify user identities without shared secrets. The specific factor combinations they can offer depend on the authenticator and deployment configuration, so implementation details should be validated against the chosen authenticators and target platforms.

System administrators

Administrators rolling out passkeys, which are built on FIDO2 specifications, benefit from understanding how the standard supports passwordless and multi-factor sign-in across mobile and desktop. This helps set expectations for how users authenticate and how the deployment configuration influences the available authentication experience.

Inside FIDO2

WebAuthn

The W3C standard component of FIDO2 that defines the browser and platform JavaScript API through which web applications (relying parties) register and authenticate users with public key credentials. WebAuthn handles the relying party side of the ceremony.

CTAP (Client to Authenticator Protocol)

The FIDO Alliance component that defines communication between the client (such as a browser or operating system) and an external authenticator, for example a roaming security key connected over USB, NFC, or BLE. WebAuthn and CTAP together compose FIDO2.

Public key credential

A key pair generated per relying party during registration. The private key remains on the authenticator and never leaves it in typical deployments, while the public key is stored by the relying party for subsequent verification. This is an inherence/possession-based mechanism that avoids shared secrets.

Authenticators

The hardware or software elements that create and hold credentials. These may be platform authenticators (built into a device, such as a laptop or phone) or roaming/cross-platform authenticators (such as external security keys), depending on the deployment.

Relying party

The web application or service that registers credentials and later verifies authentication assertions signed by the authenticator's private key.

Common questions

Answers to the questions practitioners most commonly ask about FIDO2.

Is FIDO2 the same thing as WebAuthn?

No, though the terms are often used interchangeably. FIDO2 is an umbrella term for a set of specifications from the FIDO Alliance and W3C. WebAuthn is one component of FIDO2: the W3C web API that lets browsers and web applications interact with authenticators. The other core component is CTAP (Client to Authenticator Protocol), which governs communication between the client platform and external authenticators such as security keys. So WebAuthn is a part of FIDO2, not a synonym for it.

Does FIDO2 mean the same thing as passkeys?

Not exactly. FIDO2 is the underlying set of specifications (WebAuthn plus CTAP), while a passkey is a FIDO2 credential, typically one that is discoverable (resident) and, in most current usage, synchronized across a user's devices through a platform or password manager ecosystem. In other words, passkeys are built on FIDO2, but the term generally refers to a particular class of FIDO2 credential and its user experience rather than the specifications themselves. Device-bound FIDO2 credentials on hardware security keys are also FIDO2 credentials but are not always described as passkeys, depending on the vendor's terminology.

How does FIDO2 handle authentication so that credentials cannot be phished or replayed?

FIDO2 authentication is based on public key cryptography. During registration the authenticator generates a key pair, retaining the private key and registering the public key with the relying party. At authentication time the relying party sends a challenge, which the authenticator signs with the private key after a user gesture such as a biometric or PIN. Because the private key never leaves the authenticator and the signature is scoped to the relying party's origin, credentials are resistant to phishing and replay in typical deployments. Note that FIDO2 addresses authentication; authorization decisions about what the authenticated principal may do remain a separate concern.

What does a relying party need to implement to support FIDO2?

A relying party generally needs to implement the WebAuthn registration and authentication ceremonies, which involve generating and verifying challenges, storing registered public keys and associated credential metadata per user, and validating the authenticator's signed responses against the expected origin and relying party identifier. Depending on configuration, the relying party may also verify attestation statements to establish authenticator provenance, though many deployments choose not to require attestation. The specifics vary by platform library and vendor SDK.

How does FIDO2 relate to MFA and step-up authentication requirements?

A single FIDO2 authentication can satisfy multiple factors depending on the authenticator and configuration. A security key verifies possession, and when combined with a PIN (knowledge) or a biometric (inherence) it can constitute multi-factor authentication in one gesture. FIDO2 can serve as a primary authenticator, as a second factor alongside another method, or as the mechanism for step-up authentication when a resource requires higher assurance. Whether a given ceremony counts as MFA depends on user verification settings and the authenticator's capabilities.

How do FIDO2 credentials fit into provisioning and identity lifecycle processes?

FIDO2 credentials are registered per user and per relying party, so credential enrollment, re-enrollment after device loss, and revocation typically need to be integrated with existing identity lifecycle and account recovery workflows. Because each credential is bound to a specific authenticator (or, for synchronized passkeys, to a provider ecosystem), governance considerations include tracking which credentials are registered to which accounts and ensuring recovery paths do not reintroduce weaker, phishable fallback methods. These lifecycle and governance concerns are distinct from the runtime authentication ceremony itself.

Common misconceptions

FIDO2, WebAuthn, and passkeys are interchangeable synonyms.

They are related but distinct. FIDO2 is the umbrella comprising WebAuthn (the W3C API) and CTAP (the client-to-authenticator protocol). WebAuthn is one component of FIDO2. Passkeys are a term commonly used for FIDO2/WebAuthn credentials, often those that can be discoverable and synced across devices; they build on the same underlying standards rather than being a separate technology.

FIDO2 performs both authentication and authorization for the user.

FIDO2 addresses authentication: proving that a principal controls a registered private key. It does not determine what that principal is permitted to do; authorization is a separate step handled by the relying party or downstream policy enforcement, and is out of scope for FIDO2 itself.

FIDO2 always requires a separate physical security key.

FIDO2 supports both roaming authenticators (such as external keys) and platform authenticators built into a device. Depending on configuration and platform support, authentication can occur without a separate dongle.

Best practices

Register more than one authenticator per user (for example a platform authenticator plus a roaming security key) so that account recovery does not depend on a single device.

Define and validate the relying party identifier carefully during WebAuthn registration and authentication to ensure credentials are scoped to the intended origin.

Decide deliberately whether to use discoverable (resident) credentials versus non-discoverable ones, as this affects usernameless flows and authenticator storage, and confirm your authenticators and clients support the chosen mode.

Treat FIDO2 as an authentication mechanism only, and keep authorization decisions in a separate policy layer at the relying party rather than assuming a successful assertion grants access.

Verify platform and browser support for WebAuthn and CTAP in your target environments before rollout, since capabilities vary by client and authenticator.

Plan account recovery and step-up flows in advance so users who lose an authenticator can regain access without weakening the phishing-resistant properties FIDO2 provides.