FIDO2 Explained: WebAuthn, Passkeys, and Security

FIDO2 comprises two public-key authentication standards: the World Wide Web Consortium’s Web Authentication API (WebAuthn) and the FIDO Alliance Client to Authenticator Protocol (CTAP). Together they let a relying party register and use a cryptographic credential without storing a reusable shared secret like a password.

FIDO2 can provide phishing-resistant and replay-resistant authentication when implemented and validated correctly. It does not prove a person’s legal identity, decide who should be allowed to enroll, secure a compromised server session, or repair a weak account-recovery process. Those are adjacent controls that must be designed around the authentication ceremony.

Key takeaways

• FIDO2 is WebAuthn plus CTAP. WebAuthn connects a website or application to the client; CTAP connects the client platform to a roaming authenticator.
• The private key stays with the authenticator. The relying party stores a public key and verifies signatures over fresh challenges and scoped context.
• Domain binding creates phishing resistance. A credential registered for one relying-party identifier cannot simply be replayed to an attacker’s unrelated domain.
• Passkeys are FIDO credentials. They may be device-bound or synchronized across a provider’s devices, creating different assurance, recovery, and portability trade-offs.
• Recovery is part of the security model. A strong FIDO2 login can be bypassed if email, support, or identity-recovery paths can replace the credential with weaker evidence.

What is FIDO2?

The FIDO Alliance specifications overview defines FIDO2 as the combination of the W3C WebAuthn specification and the FIDO Client to Authenticator Protocols. The standards divide the system into cooperating roles:

• Relying party: the website or service that registers credentials and verifies authentication assertions.
• Client: usually the browser or operating-system component that implements WebAuthn and mediates the ceremony.
• Authenticator: a platform component or external device that creates and uses the credential key.
• User: the person who consents to registration or authentication and may verify locally with a PIN, password, or biometric.

The W3C WebAuthn Level 3 specification defines a web API for creating and using public-key credentials scoped to a relying party. Scripts never receive the private credential key. They receive structured data and cryptographic proof produced through the authenticator and client.

FIDO2, WebAuthn, CTAP, U2F, and passkeys compared

Term	Practical meaning	Main boundary
FIDO2	The WebAuthn and CTAP standards used together	Complete standards family, not one API call
WebAuthn	Browser or client API and relying-party data model for public-key credentials	Connects the relying party to the client
CTAP2	Protocol between the client platform and a roaming authenticator	Carries external-authenticator communication over transports such as USB, NFC, and BLE
U2F / CTAP1	Earlier FIDO protocol commonly associated with second-factor security keys	More limited than modern FIDO2 capabilities
Passkey	A discoverable FIDO credential designed for passwordless sign-in	Can be synchronized or device-bound
Security key	A roaming hardware authenticator connected by USB, NFC, or another supported transport	One possible authenticator form
Platform authenticator	Authenticator built into a device or operating system	Often activated with local PIN or biometric

“Passwordless” describes the user journey, not every possible deployment. A service can use WebAuthn as a second factor after a password, as a primary multi-factor credential, or alongside other authenticators. The relying party must decide which credential characteristics and flags meet the protected action’s assurance.

How FIDO2 registration works

Registration, also called credential creation, binds a new public-key credential to an account at the relying party.

1. The server creates registration options

The relying party generates a fresh, unpredictable challenge and sends public-key credential creation options to the client. Options identify the relying party, the user account, accepted algorithms, authenticator preferences, attestation preference, and excluded existing credential identifiers where relevant.

Challenges should be single-use, short-lived, bound to the correct session and user, and stored or verifiable by the server. A challenge generated only in the browser cannot protect the server ceremony.

2. The client invokes WebAuthn

The application calls navigator.credentials.create() with the public-key options. The browser checks origin and security context, then asks an available authenticator to create a credential.

3. The authenticator obtains user consent

The authenticator requires user presence and, if requested and supported, user verification. User presence can be a touch or explicit action. User verification means the authenticator locally verifies the user through a PIN, device secret, biometric, or another supported method.

A local biometric normally unlocks use of the credential; the biometric template is not sent to the website as the authentication secret.

4. The authenticator creates a key pair

The authenticator creates a credential key pair scoped to the relying party. The private key remains protected by the authenticator or its synchronization fabric. The resulting credential contains the public key, credential identifier, authenticator data, client data, and attestation information according to the selected format.

5. The server validates and stores the credential

The relying party validates the ceremony before storing anything. Checks include:

• expected challenge;
• expected origin;
• correct relying-party identifier hash;
• expected cross-origin state and topOrigin when the ceremony is embedded;
• user-presence and user-verification flags according to policy;
• accepted algorithm and key parameters;
• attestation structure and trust policy if attestation is requested;
• uniqueness and association with the correct user account.

The server stores the credential identifier, public key, account binding, signature counter or applicable state, transports or metadata where useful, and credential lifecycle information. It never needs the private key.

How FIDO2 authentication works

Authentication proves control of a previously registered credential.

1. The server creates request options

The relying party generates a new challenge and sends assertion options. It may include an allow-list of credential identifiers or use discoverable credentials so the authenticator can identify the account.

2. The client requests an assertion

The application calls navigator.credentials.get(). The browser and authenticator select a suitable credential and obtain the required user presence or local user verification.

3. The authenticator signs the ceremony data

The authenticator signs over the fresh challenge context and authenticator data using the credential private key. Because the credential is scoped to the relying party, an unrelated phishing origin cannot ask the authenticator to produce a valid assertion for the real service.

4. The server verifies the assertion

The relying party verifies the expected challenge, origin, relying-party hash, signature with the stored public key, required flags, allowed credential, user binding, and relevant counter or backup state. Only then should it create or elevate an application session.

Each assertion proves control at a moment. Session creation, token protection, reauthentication, transaction authorization, logout, and revocation remain separate application responsibilities.

Why FIDO2 is phishing-resistant

Passwords and one-time codes can be entered into an impostor site, which can relay them to the real service. FIDO2 uses a credential scoped to the relying party and cryptographically binds the assertion to the expected verifier context.

The NIST SP 800-63B-4 authenticator requirements describe WebAuthn as phishing-resistant through verifier-name binding. The authenticator output is bound to the authenticated domain name instead of depending on the user noticing a deceptive page.

Phishing resistance has boundaries:

• It does not stop malware or an attacker who already controls an authenticated session.
• It does not prevent a user from approving a malicious transaction inside the genuine service.
• It does not secure an account-recovery path that can replace the credential.
• It does not prove that the person controlling the authenticator is the real-world person an organization intended to enroll.

Replay resistance and challenge handling

A recorded assertion should not work in a later ceremony because every request uses a fresh challenge. NIST describes cryptographic authenticators that incorporate nonces or challenges as replay-resistant.

Implementation errors can remove that property. Common failures include predictable challenges, reusing challenges, accepting a challenge for the wrong account, not enforcing expiry, or validating only the signature while ignoring origin and relying-party context.

The server should mark a challenge consumed atomically. If parallel requests race, only one successful ceremony should be able to use that challenge.

User presence and user verification

WebAuthn distinguishes:

• User presence (UP): the user performed an interaction indicating participation.
• User verification (UV): the authenticator locally verified the user through an activation factor such as a PIN or biometric.

Presence alone is not multi-factor authentication. A service protecting a higher-risk action may require the UV flag and reject assertions that only show presence. Requirements should state the expected flag values rather than rely on an interface label such as “Use Face ID.”

Local verification quality also varies by authenticator. The relying party may have limited visibility into the exact biometric or PIN implementation for user-supplied authenticators, so policy should be proportionate to the transaction and deployment population.

Platform, roaming, and cross-device authenticators

Platform authenticators

These are integrated with a phone, laptop, or operating system. They can provide a short journey using the device’s local unlock method. The trade-off is dependence on platform account recovery, device security, and synchronization behavior.

Roaming authenticators

External security keys can be carried between devices and connected through supported transports. They are useful for workforce, administrative, or high-assurance use cases, especially when credential non-exportability and managed issuance matter.

Cross-device authentication

Hybrid flows can use a nearby phone to authenticate a session on another device. The handoff and proximity mechanisms improve usability but add user-interface and threat-model details that should be tested rather than treated as identical to same-device authentication.

Support multiple credentials per account. Users replace phones, lose security keys, use work and personal devices, and need a safe way to name, inspect, and remove credentials.

Device-bound and synced passkeys

A passkey is a FIDO credential designed for sign-in without a password. Passkeys can be:

• Device-bound: the credential private key remains tied to one authenticator or managed device.
• Synced: credential material is encrypted and synchronized through a provider’s fabric for use across eligible devices.

Synced passkeys improve availability and recovery, while device-bound credentials can provide stronger non-exportability. The NIST SP 800-63B-4 syncable-authenticator guidance allows syncable authenticators in contexts up to Authentication Assurance Level 2 when its requirements are met, but syncing conflicts with the non-exportability required at Level 3.

Do not infer assurance from the word “passkey.” Evaluate whether credentials are backed up, eligible for backup, shared, managed, device-bound, attested, and activated with user verification according to the relying party’s policy.

Attestation and authenticator trust

Attestation can provide evidence about an authenticator’s provenance or properties at registration. It is not the same as the authentication signature, and it does not identify the human user.

Consumer services often minimize attestation collection for privacy and ecosystem compatibility. Managed workforce deployments may require specific authenticator models or certification. The decision should answer a threat-model question rather than collect device-identifying evidence by default.

If attestation is used:

• define accepted formats and trust anchors;
• validate certificate paths and statements correctly;
• specify metadata update and revocation handling;
• plan for authenticators with no trusted attestation;
• document privacy and retention consequences;
• test replacement when an accepted model changes status.

FIDO2 does not replace identity proofing

FIDO2 proves control of a credential registered to a relying party. It does not establish the legal name, age, address, regulatory status, or real-world uniqueness of the person enrolling it.

That distinction creates three common patterns:

1. Pseudonymous enrollment: the service needs a secure account but not a verified real-world identity.
2. Identity-bound enrollment: identity proofing occurs first, then a FIDO credential is bound to the verified account.
3. Step-up or recovery: the service re-verifies identity or uses other strong evidence before allowing a lost authenticator to be replaced.

Binding should be explicit. Record which account and proofing state existed when the credential was added, which session authorized it, and whether later risk should trigger reauthentication or identity refresh.

Account recovery and credential lifecycle

Recovery is where many phishing-resistant deployments downgrade. If a user can replace every FIDO credential using an emailed link or weak support questions, an attacker will target that path instead.

A complete lifecycle covers:

• adding a second authenticator;
• naming and viewing registered credentials;
• device loss and suspected compromise;
• revoking one credential without destroying the account;
• recovering with codes, another authenticator, managed support, or identity proofing;
• notifying the user through an independent channel;
• delaying or limiting high-risk actions after recovery;
• logging who changed the credential set and why;
• closing sessions created before compromise was reported.

Recovery assurance should match the consequence of replacing the authenticator. A low-risk community account and an administrator who can move funds do not need the same path.

How to evaluate a FIDO2 deployment

Protocol validation

Test challenge generation and expiry, exact origin validation, relying-party identifier rules, signature verification, supported algorithms, UP and UV policy, credential association, counters, backup flags, and error handling. Prefer a maintained server library over hand-written binary parsing, while still understanding what it validates.

Authenticator coverage

Test platform and roaming authenticators across supported browsers, operating systems, devices, transports, enterprise policies, and accessibility settings. Include credential creation, sign-in, conditional user interface, cross-device use, and device replacement.

Account and session security

Review who can add a credential, whether recent authentication is required, how sessions are elevated, when reauthentication occurs, and how credential changes affect existing sessions.

Recovery and support

Red-team loss, stolen devices, compromised email, SIM change, support impersonation, and malicious household or workplace access. Measure both attacker resistance and genuine-user completion.

Privacy and observability

Minimize attestation and device data to what the policy needs. Avoid using stable credential identifiers across relying parties; WebAuthn’s scoping is designed to prevent that. Log reasons and ceremony outcomes without leaking sensitive client data.

Common FIDO2 implementation mistakes

Checking the signature but not the context

A valid signature is insufficient if the server fails to verify the challenge, origin, relying-party identifier, flags, and account binding exactly.

Calling every passkey multi-factor

The server must verify whether user verification occurred and whether the credential characteristics meet policy. User presence alone is not the same as local user verification.

Allowing silent credential addition

Adding a new authenticator changes account security. Require an appropriate recent authentication or recovery ceremony, notify the user, and record the event.

Supporting only one credential

One-credential accounts create brittle recovery and encourage weaker fallbacks. Allow multiple authenticators with clear management and revocation.

Leaving the password as an equal fallback

If a password can always bypass the FIDO path, phishing resistance may exist only on the preferred button. Restrict or remove weaker paths according to risk and migration stage.

Ignoring server sessions

FIDO2 authenticates the login ceremony. Protect cookies and tokens, rotate sessions after authentication, require step-up for sensitive actions, and revoke compromised sessions.

A deployment checklist

Before launch, confirm that:

• challenges are unpredictable, single-use, short-lived, and bound to the correct session;
• origin, relying-party identifier, signature, algorithm, flags, and credential ownership are validated;
• UP and UV requirements are explicit for each protected action;
• platform, roaming, synced, device-bound, and cross-device cases are tested as supported;
• users can register multiple credentials and safely name, inspect, and revoke them;
• credential addition and recovery require proportionate assurance and generate notifications;
• attestation collection has a defined trust, privacy, and metadata policy;
• password, one-time-code, support, and identity-recovery fallbacks are threat-modeled;
• authenticated sessions and transaction authorization are protected separately;
• protocol libraries, browser support, deprecations, and security events have owners.

Where Didit fits alongside FIDO2

FIDO2 handles authentication after a credential has been registered. Didit can support the adjacent identity decision through ID Verification, Liveness Detection, and Biometric Authentication. Published Biometric Authentication pricing is $0.10 per check.

Teams can review current module rates on the pricing page. These products should not be assumed to implement FIDO2 from that description: the architectural point is that identity proofing, biometric checks, FIDO credential authentication, account recovery, and application authorization are different trust decisions.

Frequently asked questions

What does FIDO2 stand for?

FIDO refers to Fast Identity Online. FIDO2 is the standards family combining W3C WebAuthn with FIDO Alliance CTAP for public-key authentication.

Is FIDO2 the same as WebAuthn?

No. WebAuthn defines the relying-party and client API and data model. FIDO2 includes WebAuthn plus CTAP, which connects the client platform with roaming authenticators.

Are passkeys FIDO2 credentials?

Yes. Passkeys are discoverable FIDO credentials designed for passwordless sign-in. They can be synchronized across eligible devices or remain device-bound.

Is FIDO2 phishing-resistant?

Properly validated FIDO2 authentication is phishing-resistant because the credential is scoped to the relying party and the assertion is bound to that verifier context. Weak recovery or an already-compromised session can still bypass the intended protection.

Does FIDO2 use biometrics?

It can use a local biometric to activate an authenticator and set user verification. The relying party normally receives the result and cryptographic assertion, not the biometric template.

Does FIDO2 verify a person’s identity?

No. It verifies control of a registered credential. Real-world identity proofing is a separate enrollment or recovery decision when the service requires it.

What happens when a user loses every authenticator?

The service needs a recovery policy proportionate to account risk. Options can include another registered authenticator, recovery codes, managed administrative recovery, or renewed identity proofing, with notification and post-recovery restrictions.

Primary references

• FIDO Alliance User Authentication Specifications
• W3C Web Authentication Level 3 Candidate Recommendation Snapshot
• FIDO Alliance CTAP 2.3 Proposed Standard
• NIST SP 800-63B-4: Authentication and Authenticator Management
• NIST SP 800-63B-4 authenticator requirements

FIDO2 replaces reusable verifier secrets with scoped public-key credentials and fresh cryptographic ceremonies. Its value survives only when the relying party validates the full context, manages the credential lifecycle, protects sessions and sensitive actions, and gives recovery the same security attention as login.