FIDO2 and WebAuthn

How FIDO2 and WebAuthn Work

fido2 is the broader passwordless standard family, while webauthn is the browser and application-facing API that lets a site request a public-key based assertion from an authenticator. Together, they replace shared secrets with a challenge-response flow tied to a private key held on the user’s device or security key.

The important security shift is that the password is no longer the primary bearer of trust. The verifier receives proof that the authenticator can sign the challenge, and the private key never leaves the device. That design makes credential replay and credential stuffing far less effective than with passwords or one-time codes.

WebAuthn is the web layer most teams implement first, because it is what browsers and apps use to initiate registration and sign-in. FIDO2 includes that layer plus the underlying authenticator protocol, so the term usually implies both the user experience and the device-side cryptographic mechanism.

Why FIDO2 Is Phishing-Resistant

FIDO2 and WebAuthn are valuable because they bind authentication to the origin that initiated the request. A fake login page cannot simply ask the user for a reusable secret, then replay it elsewhere, because the authenticator response is tied to the real site’s domain and challenge context.

That origin binding is why these standards are often described as phishing-resistant. They also reduce risk from adversary-in-the-middle attacks that harvest passwords, SMS codes or push approvals, because the attacker does not get a reusable secret that works against the legitimate service.

NIST SP 800-63 Digital Identity Guidelines treats phishing-resistant authenticators as a higher assurance option, which is why FIDO2 and WebAuthn are commonly used for stronger sign-in policies and step-up authentication.

Where FIDO2 and WebAuthn Fit in Identity Architecture

These standards sit in the authentication layer, but they influence the whole identity stack. They change how users enroll, how recovery works, how help desks handle account resets and how organisations think about passwordless rollout across browsers, mobile apps and managed devices.

In practice, the deployment question is not only whether the authenticator works, but whether the broader identity system can support registration, recovery, device changes and account lifecycle events without falling back to weaker paths. A strong FIDO2 deployment still fails if recovery silently reintroduces password or SMS dependence.

Passwordless and Passkeys Guide is the most direct companion for understanding rollout, recovery and the operational choices that determine whether passwordless actually stays phishing-resistant.

Workforce Identity Security Guide helps place FIDO2 in the wider employee identity journey, including SSO, federation and account recovery.

What FIDO2 Does Not Solve by Itself

FIDO2 and WebAuthn strengthen primary authentication, but they do not automatically solve session theft, over-privileged access, compromised endpoints or weak recovery controls. If an attacker steals an active session token after login, the login method itself may be strong while the downstream session remains exposed.

The standards also do not remove the need for good identity governance. Organisations still need enrollment rules, recovery assurance, device trust decisions and policy choices about which users may use platform authenticators, roaming keys or both. Browser support, mobile support and fallback paths also need to be tested, not assumed.

Teams often underestimate how much of the risk shifts from password compromise to account recovery compromise. If an attacker can social-engineer help desk resets or abuse a recovery workflow, the attacker may bypass the benefits of strong authenticators entirely.

Risk and Threat Considerations

FIDO2 and WebAuthn materially reduce password phishing, but they do not eliminate identity attack paths. The remaining exposure concentrates in recovery, session handling, device compromise and poor fallback design, where an attacker can bypass the stronger authenticator without defeating the standard itself.

Failure mechanism: The most common failure is not cryptographic weakness, but a surrounding process failure, such as weak account recovery, token theft after login or a fallback to less-resistant methods that reintroduce phishing and replay risk.

Impact: A compromised recovery path or stolen session can still lead to account takeover, privileged action, data exposure or lateral movement, even when the original authentication event used FIDO2 or WebAuthn.

Practitioner Guidance

Why practitioners should care: Treat FIDO2 and WebAuthn as an authentication control, not a full identity programme. The implementation only stays strong if registration, recovery, fallback and session controls are designed to match the assurance level of the authenticator.

What to watch for: Pay close attention to SMS fallback, help desk resets, shared recovery links, unmanaged devices and any policy that allows weaker sign-in after a strong first factor. Those are the places where phishing-resistant authentication is most often undermined in practice.

Practitioner takeaway: The best deployment is the one that makes the secure path the easiest path, while ensuring that recovery and exception handling do not become the weakest link.

Related resources from NHI Mgmt Group

• What is the difference between FIDO2 and WebAuthn for security teams?
• What is the difference between PIV smart cards and FIDO2 WebAuthn for phishing-resistant login?
• What is the difference between WebAuthn PRF and regular FIDO2 signatures for vault security?
• What is the difference between SMS-based 2FA and FIDO2 WebAuthn for MFA?