Skip to main content
Comply Defense
Category: Identity & Access Management

FIDO2/WebAuthn

Also known as: FIDO2, WebAuthn, Web Authentication API, CTAP, FIDO2 (WebAuthn)
Simply put

FIDO2 is an open set of authentication standards that lets people sign in using external authenticators such as key fobs or biometric methods like fingerprint readers, generally without a traditional password. WebAuthn is the part of FIDO2 that web developers use to add this kind of sign-in to browsers and certain applications. Together, these standards also support the use of passkeys as a passwordless way to authenticate.

Formal definition

FIDO2 is an open authentication standard commonly described as comprising two components: WebAuthn and the Client to Authenticator Protocol (CTAP). WebAuthn refers specifically to the web API that developers use to enable browser-based (and, per the evidence, Android-native) passwordless authentication, while CTAP governs communication between clients and external authenticators such as key fobs. In most implementations, FIDO2 supports authentication via biometric methods (for example, fingerprint reading) and hardware authenticators, and the same standards are leveraged to deploy passkeys. According to the evidence, WebAuthn enjoys wide support across evergreen browsers including Chrome, Safari, and Firefox. Note: this entry defines the standard at a conceptual level and does not address suitability for CUI, DoD RMF, or FISMA authentication assurance requirements; readers should verify applicability against current authoritative guidance (for example, NIST digital identity guidance) and any agency-specific tailoring.

Why it matters

FIDO2 and WebAuthn represent a shift away from traditional shared secrets like passwords toward authentication that relies on external authenticators, biometric methods, and passkeys. For organizations wrestling with credential-based attacks, the appeal of these standards is that they generally do not require a user to enter a reusable password, which reduces the exposure created by password reuse, weak passwords, and credentials that can be intercepted or replayed. Because WebAuthn is an open, browser-facing standard with wide support across evergreen browsers such as Chrome, Safari, and Firefox, it can be adopted without proprietary client software in many web-based scenarios.

For compliance-focused readers, it is important to distinguish the availability of a standard from its acceptability for a given authentication assurance requirement. FIDO2/WebAuthn is a technical authentication mechanism; it is not, by itself, a compliance determination. Whether a FIDO2 implementation satisfies a particular authenticator assurance level, a Controlled Unclassified Information (CUI) protection obligation, a DoD Risk Management Framework (RMF) control, or a FISMA requirement depends on how it is deployed and on the current authoritative guidance and any agency-specific tailoring. This entry describes the standard at a conceptual level and does not resolve those applicability questions.

Readers should therefore treat adoption of FIDO2/WebAuthn as a design decision that still must be mapped to the relevant control set and verified against current official sources, such as NIST digital identity guidance. The evidence supports the description of the standard and its components, but it does not establish suitability for any specific federal, defense, or national security system, and it does not provide metrics on effectiveness.

Who it's relevant to

Information System Security Managers and Security Architects
Those responsible for designing authentication for web-based and Android-native applications may evaluate FIDO2/WebAuthn as a passwordless option using external authenticators, biometrics, or passkeys. They should map any implementation to the applicable control set and confirm suitability against current authoritative guidance rather than assuming the standard alone satisfies an assurance requirement.
Compliance Officers and Auditors
Reviewers assessing authentication mechanisms should distinguish the presence of a FIDO2/WebAuthn capability from a determination that it meets a specific CUI, DoD RMF, or FISMA authentication requirement. The evidence here defines the standard conceptually and does not establish acceptability for any given system; applicability should be verified against current official sources and agency-specific tailoring.
Web and Application Developers
Developers building browser-based or Android-native sign-in flows use the WebAuthn API, part of FIDO2, to enable passwordless authentication and to support passkeys. WebAuthn enjoys wide support across evergreen browsers such as Chrome, Safari, and Firefox, which can ease integration in many web scenarios.
Authorizing Officials and Government Contractors
Officials making authorization decisions and contractors supporting government systems should treat FIDO2/WebAuthn as a technical mechanism, not a compliance conclusion. Any reliance on it for a particular impact level or assurance level should be confirmed against current authoritative guidance (for example, NIST digital identity guidance) and the relevant contractual or regulatory requirements.

Inside FIDO2

FIDO2
An open authentication standard set developed by the FIDO (Fast IDentity Online) Alliance, generally comprising the WebAuthn specification and the Client to Authenticator Protocol (CTAP). It is designed to enable phishing-resistant, public-key-based authentication. Practitioners should verify the current specification version against official FIDO Alliance and W3C sources.
WebAuthn (Web Authentication API)
A web standard maintained by the World Wide Web Consortium (W3C) that defines a browser and platform API allowing web applications to register and authenticate users using public-key credentials rather than shared secrets such as passwords.
CTAP (Client to Authenticator Protocol)
A companion protocol under the FIDO2 umbrella that governs communication between a client device (such as a browser or operating system) and an external authenticator (such as a hardware security key) over transports like USB, NFC, or Bluetooth.
Public-key credential pair
The core cryptographic mechanism in which a private key is retained on the authenticator and a corresponding public key is registered with the relying party. Authentication is performed by signing a challenge with the private key, which is generally not exportable from the authenticator in most implementations.
Authenticator
The hardware or software component that generates and stores credentials. Authenticators are commonly categorized as roaming (external, portable devices) or platform (built into a device), and the choice affects usability and assurance considerations.
Relying party
The application or service that requests and verifies authentication. The relying party stores the user's public key and validates signed assertions during authentication events.
Phishing resistance
A property arising from origin binding, where credentials are scoped to a specific relying party origin. This design generally prevents credentials from being used against fraudulent sites, a characteristic relevant to authenticator assurance discussions.

Common questions

Answers to the questions practitioners most commonly ask about FIDO2.

Does adopting FIDO2/WebAuthn by itself make an authentication solution compliant with federal or DoD requirements?
No. FIDO2/WebAuthn is a technical authentication standard, not a compliance framework, and implementing it does not by itself establish compliance. Federal and DoD authentication requirements are generally governed by policies and guidance such as NIST SP 800-63 (Digital Identity Guidelines) for identity assurance and authenticator assurance levels, along with agency-specific and RMF-based tailoring. A FIDO2/WebAuthn authenticator may help satisfy certain phishing-resistant multifactor authentication objectives, but compliance depends on the applicable control baseline, impact level, and authorizing official's determination. Confirm requirements against the current authoritative sources for your system's category rather than assuming the technology alone suffices.
Is FIDO2 the same thing as WebAuthn, or are they interchangeable terms?
They are related but distinct and should not be treated as interchangeable. FIDO2 is generally described as an overarching set of specifications that includes the WebAuthn component and a separate client-to-authenticator protocol component. WebAuthn is the web-facing API portion, while the client-to-authenticator protocol addresses communication between the client platform and external authenticators. Referring to the full capability as simply 'WebAuthn' omits the client-to-authenticator layer, and referring to it only as 'FIDO2' can obscure which specific component a given product or requirement addresses. When documenting an implementation, identify which components are in scope.
What should an ISSM confirm when evaluating a FIDO2/WebAuthn authenticator for use on an RMF-authorized system?
An ISSM should generally confirm how the authenticator maps to the applicable authenticator assurance level and phishing-resistance objectives under the relevant NIST guidance, how it aligns with the identification and authentication controls in the system's tailored baseline, and whether the authenticator's binding, storage, and verification characteristics meet the impact level. The ISSM should also confirm interoperability with existing identity infrastructure and how the authenticator is reflected in the system security plan. This entry does not cover product-specific validation, procurement, or the authorizing official's risk acceptance, which must be verified against current official sources and organizational policy.
How does FIDO2/WebAuthn relate to existing PIV or CAC credential requirements?
FIDO2/WebAuthn and PIV/CAC-based authentication are distinct approaches, and the relationship depends heavily on agency policy. Many federal civilian and DoD environments have longstanding requirements tied to PIV or CAC credentials for certain access, and introducing a FIDO2/WebAuthn authenticator does not automatically replace or satisfy those requirements. In some implementations FIDO2/WebAuthn may serve as an alternative or supplemental phishing-resistant authenticator where policy permits, but this varies by agency and system category. Verify against the applicable identity and credentialing policy whether the two can coexist or substitute for one another in your environment.
What documentation is typically needed to reflect a FIDO2/WebAuthn deployment in an authorization package?
Documentation generally includes how the authenticator is addressed in the system security plan, the mapping to relevant identification and authentication controls in the tailored baseline, and any supporting assessment evidence showing how the implementation meets the intended assurance objectives. Because assessment is distinct from authorization, this evidence supports but does not constitute the authorizing official's decision. The specific artifacts, formats, and depth of evidence vary by agency and impact level, so confirm requirements against the current authoritative guidance and your organization's authorization process rather than assuming a standard set applies.
How does continuous monitoring apply to a FIDO2/WebAuthn implementation after an ATO is granted?
An ATO is time-bound and subject to continuous monitoring, so a FIDO2/WebAuthn deployment must be maintained and reassessed rather than treated as permanently accepted once authorized. Continuous monitoring activities generally include tracking changes to the authenticator configuration, verifying that the implementation continues to meet the applicable control requirements, and reflecting any material changes through the organization's change management and reauthorization processes. The specific monitoring frequency, metrics, and reporting depend on agency policy and the system's impact level, which should be confirmed against current authoritative guidance.

Common misconceptions

Adopting FIDO2/WebAuthn by itself satisfies federal or defense authentication compliance requirements.
A technology standard is not equivalent to compliance. Whether FIDO2/WebAuthn meets a given obligation depends on how it maps to the applicable control baseline and tailoring, for example identification and authentication controls in a framework such as NIST SP 800-53, or CUI protection expectations under NIST SP 800-171, as interpreted for the specific system and impact level. Readers should confirm the mapping against current authoritative guidance rather than assuming automatic satisfaction, and note that compliance is not the same as security.
FIDO2 and WebAuthn are the same thing and are maintained by the same organization.
They are related but distinct. WebAuthn is a specification maintained by the W3C, while FIDO2 is a broader standard set from the FIDO Alliance that includes WebAuthn together with CTAP. Conflating them, or misattributing their maintaining bodies, obscures which component governs a given behavior.
Because FIDO2/WebAuthn is phishing resistant, it eliminates the need for other authentication safeguards or ongoing oversight.
Phishing resistance addresses a specific class of attack through origin binding, but it does not by itself constitute a complete authentication or security program. Deployment still requires attention to enrollment, credential recovery, lifecycle management, and continuous monitoring consistent with the governing authorization and control requirements.

Best practices

Verify the current versions of the WebAuthn (W3C) and FIDO2/CTAP (FIDO Alliance) specifications before relying on any specific capability, since these standards evolve across revisions.
Map the chosen FIDO2/WebAuthn implementation explicitly to the applicable identification and authentication controls and tailoring for your system, rather than assuming the standard alone demonstrates compliance.
Select authenticator types (roaming versus platform) deliberately based on the assurance and usability needs of the environment, and document the rationale for the applicable impact level.
Design and document credential enrollment, recovery, and lifecycle processes, recognizing that private keys are generally non-exportable and lost authenticators require a governed recovery path.
Preserve origin binding by scoping credentials correctly to the relying party origin, and validate that the deployment maintains this phishing-resistance property in practice.
Confirm scope-specific interpretations against current official sources, since obligations may differ across federal civilian, defense, and other system categories, and do not treat any single deployment as universally sufficient.