WebAuthn is the application-facing API for browser-based passwordless authentication, while FIDO2 includes WebAuthn plus CTAP for the broader exchange with authenticators. That difference matters when you are deciding what your applications, browsers, and devices must actually support.
How WebAuthn and FIDO2 sit differently in an IAM programme
For IAM planning, the distinction is practical rather than academic. WebAuthn tells you what the browser-facing authentication interface must support for passwordless or phishing-resistant sign-in. FIDO2 is the broader ecosystem that adds authenticator transport and device interaction through CTAP. That means architectural decisions, rollout sequencing, and support requirements land in different places.
In other words, WebAuthn is the application and browser contract, while FIDO2 is the end-to-end standard set that includes how the authenticator is reached. An iam programme that treats them as interchangeable can misstate what needs to be enabled in the app, what the browser must expose, and what hardware or platform authenticators must be able to do.
That distinction is why passwordless programmes should avoid vague “FIDO support” language. The real question is whether the relying party can consume WebAuthn, whether the user’s browser and device can present the right authenticator options, and whether the chosen authenticators align with the assurance level and user experience the IAM team is targeting. NIST SP 800-63 Digital Identity Guidelines is a useful reference when those decisions need to map to authenticator assurance and phishing resistance.
What changes for applications, browsers, and devices
WebAuthn matters to application teams because it defines the interface for registration and authentication ceremonies in the browser. If an application supports WebAuthn, it can work with platform authenticators, security keys, and passkeys depending on the deployment model. That makes it the control point for sign-in flows, challenge handling, and what the user sees during authentication.
FIDO2 matters to platform and endpoint teams because it includes the transport and authenticator interaction layer. CTAP is what allows a browser or operating system to talk to an external authenticator, such as a security key, or to a built-in platform authenticator. From an IAM perspective, that means supportability is split across the app, browser, OS, and device estate, not owned by a single team.
This is also where implementation guidance gets sharper. If you are rolling out passkeys, the programme should verify browser support, device support, and recovery paths together rather than assuming “WebAuthn enabled” is enough. NHIMG’s Passwordless and Passkeys Guide is useful for the rollout and recovery side, while the broader Workforce Identity Security Guide places phishing-resistant sign-in in the wider workforce control stack.
When programme scope includes device and authenticator diversity, IAM and IGA Basics helps position authentication as one part of the wider identity lifecycle rather than a standalone feature.
Why IAM programmes treat the distinction as a design and governance decision
The distinction matters because each layer creates a different implementation dependency. If WebAuthn is the app-level requirement, your main control question is whether the application can issue and verify the ceremony correctly. If FIDO2 is the procurement or endpoint requirement, your main control question is whether the browsers, operating systems, and authenticators in scope can complete the flow reliably at scale.
That also affects policy language. “Support WebAuthn” is a product requirement. “Support FIDO2 authenticators” is a programme requirement that may involve browser compatibility, hardware key policy, attestation choices, and fallback handling. Conflating those can lead to deployments where the application is ready but the user population is not, or where the organisation buys authenticators that the target browsers and endpoints cannot use consistently.
For identity roadmaps, the practical question is whether you are trying to remove passwords at the application layer, raise phishing resistance at the assurance layer, or standardise authenticators across the fleet. The answer often requires all three, but they are not the same control. NHIMG’s Identity Security Programme Guide is relevant when those choices need to be sequenced across funding, owners, and rollout stages.
Risk and Threat Considerations
The main risk is assuming a passwordless label means the whole sign-in path is phishing-resistant. In practice, weak recovery, unsupported browsers, downgraded fallback methods, or inconsistent device coverage can reintroduce the very exposure the programme is trying to remove. The boundary between WebAuthn and FIDO2 matters because the attack surface shifts from the password to the ceremony, authenticator, and recovery process.
Failure mechanism: An organisation enables WebAuthn in one application but leaves weak fallback authentication, inconsistent device support, or poorly governed authenticator recovery in place. Attackers then target the weakest alternate path, or users silently fall back to lower-assurance methods when their preferred authenticator is unavailable.
Impact: The programme may report “passwordless” progress while still allowing account takeover through downgrade paths, recovery abuse, or unsupported client configurations. That can undermine phishing resistance, create uneven user experience, and produce false confidence in the strength of the IAM control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | WebAuthn and FIDO2 map directly to phishing-resistant authentication and authenticator assurance. |
| Recommendation — Align your sign-in design to the assurance and phishing-resistance guidance before rollout. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | WebAuthn/FIDO2 choices affect how access is authenticated and governed across endpoints and apps. |
| Recommendation — Enforce the chosen authentication path consistently across users, devices, and fallback methods. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The question concerns how users authenticate through browser and authenticator support. |
| Recommendation — Specify acceptable authentication mechanisms and verify they are enforced in production. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | IAM programmes must define and control which authentication methods are allowed. |
| Recommendation — Document and enforce approved authentication methods and recovery rules. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Browser-based login architecture often sits alongside modern authentication and federation decisions. |
| Recommendation — Verify the authentication architecture supports the intended browser and token flows. | ||
Practitioner Guidance
What to verify: Confirm the exact control boundary before rollout. WebAuthn support must exist in the application and browser path, while FIDO2 support must be validated across authenticators, devices, and operating systems. If those are not tested separately, deployment issues are usually discovered by users first.
Decision rule: If your goal is app enablement, treat WebAuthn as the minimum application requirement. If your goal is fleetwide passwordless sign-in with hardware and platform authenticator choice, treat FIDO2 compatibility, recovery, and fallback policy as programme-level requirements.
Practitioner takeaway: The most common mistake is treating “FIDO2” as a generic synonym for modern authentication; in IAM, the useful distinction is whether you are specifying the application interface, the broader authenticator ecosystem, or the governance needed to keep both aligned.