FIDO2

Technical Definition

FIDO2 is the umbrella term for two complementary specifications: the W3C Web Authentication API (WebAuthn), which defines how a browser or platform requests and receives public-key credentials from a web application acting as the relying party; and the FIDO Alliance Client to Authenticator Protocol (CTAP2), which defines how the platform communicates with an external or embedded authenticator. Together they allow a relying party to register a public key during enrolment and verify a signed challenge during authentication, with the corresponding private key never leaving the authenticator.

Operational Relevance

Systems and platform teams use FIDO2 to implement phishing-resistant multi-factor or passwordless authentication for workforce and customer-facing services. Because the authenticator, not the server, holds the private key and performs the signing operation, a breach of the relying party’s credential store does not expose secrets that can be replayed elsewhere. Adopting FIDO2 operationally requires relying-party support for WebAuthn, authenticators compatible with the target user population, and a defined enrolment and recovery process for lost or replaced authenticators.

Architecture Relationship

A FIDO2 deployment involves three cooperating roles: the relying party, which is the service verifying identity; the client platform, the browser or operating system implementing WebAuthn; and the authenticator, whether a hardware key, platform biometric sensor or synced passkey provider, implementing CTAP2. Registration produces a public key bound to the relying party’s origin; authentication produces a signed assertion that the relying party verifies against the stored public key. Attestation, when requested during registration, lets the relying party assess authenticator provenance.

Example

A bounded illustrative workflow: registering a hardware security key against a web application’s account settings page. The browser invokes the WebAuthn registration ceremony, the user activates the security key, the key generates a new key pair scoped to that origin, and the relying party stores the resulting public key and credential identifier. On a later sign-in, the relying party issues a challenge, the browser forwards it to the key over CTAP2, the user re-activates the key, and the signed assertion is returned to the relying party for verification.

Misunderstanding

• Treating FIDO2 as a single certified product rather than a specification family. Conformance depends on the combination of relying-party implementation, client platform version and authenticator capability, so two deployments each described as “FIDO2-compliant” are not automatically interoperable; confirm the specific WebAuthn and CTAP2 feature set supported by each participant before assuming cross-vendor compatibility.
• Assuming FIDO2 removes the need for account-recovery planning. Losing the only registered authenticator without a backup method or recovery credential can lock a user out entirely.

Related Terms

• WebAuthn
• CTAP2
• U2F
• Passkey
• Relying party
• Authenticator attestation

Further Reading

The RFC Editor’s RFC Series (rfc-editor.org) is an authoritative index for related Internet technical specifications and a reasonable starting point for background on standards publication practice. For FIDO2 itself, consult the current WebAuthn and CTAP2 specification texts directly, since specific version numbers and conformance status were not verified within the evidence available for this entry and should be confirmed before implementation decisions are finalised.