FIDO Protocols

How FIDO protocols work

FIDO protocols replace password-based sign-in with a challenge-response flow that proves possession of a private cryptographic key. The private key stays on the user’s device or security key, while the server keeps only the public key, so the relying party can verify the login without ever learning a reusable secret.

This design is why FIDO is usually described as phishing-resistant rather than merely passwordless. The browser, authenticator, and relying party cooperate to bind the authentication ceremony to the site origin, which helps stop credential replay and reduces the value of harvested secrets.

Why FIDO is different from passwords

Passwords are shared secrets: if they are guessed, stolen, reused, or relayed, the account can be abused. FIDO changes the trust model by replacing a memorized secret with a private key that is never exposed to the server, and in normal use never leaves the authenticator.

That shift matters because it removes several common attack paths at once. There is no password database to phish for, no password to reuse across services, and no captured value that can be replayed in a later session. The result is stronger resistance to social engineering, credential stuffing, and simple replay attacks.

FIDO is also broader than a single product or browser feature. It is an ecosystem of ceremonies and authenticator capabilities that includes platform authenticators, roaming security keys, user verification, and, in practice, WebAuthn and CTAP as the main protocol building blocks. A good mental model is that FIDO standardises how the cryptographic proof is created and verified, not just what the user sees on screen.

Where FIDO fits in modern authentication

FIDO is most useful when the organisation wants strong authentication without passwords in places where phishing risk is high or account takeover would be costly. It is commonly used for workforce sign-in, customer login, and high-assurance access paths where the organisation wants a verifier-controlled, origin-bound credential rather than a reusable shared secret.

It also fits well with passwordless migration plans because it can be introduced gradually alongside existing authentication methods. Many deployments start with FIDO as a strong second factor and later move toward passwordless sign-in once recovery, device provisioning, and support processes are mature enough to handle account lifecycle edge cases.

For practitioners, the most important implementation detail is that FIDO protects the sign-in ceremony, not the whole identity stack. Session security, recovery flows, device trust, and account recovery policy still matter, because a strong authenticator does not prevent abuse of weak fallback paths.

Operational constraints and recovery considerations

FIDO works best when the organisation understands device coverage, authenticator support, and recovery processes before rollout. Users may lose devices, replace phones, or switch browsers, so the authentication design has to account for enrollment, backup, and recovery without reintroducing weak fallbacks that undermine the benefit of the protocol.

Relying parties also need to verify authenticator properties correctly, especially when policy depends on device class, user verification, or certified hardware. Mistakes at the verification layer can create false confidence, where the login looks modern but the enforcement is still too loose to provide the intended assurance.

Because FIDO depends on public key infrastructure in the broad sense of key pair usage, organisations should treat key handling and authenticator lifecycle as part of the control plane. If a device, token, or synced credential is enrolled, lost, replaced, or recovered incorrectly, the security outcome depends on how well those events are governed.

Threat and failure modes to keep in view

FIDO reduces phishing and replay, but it does not eliminate compromise routes around the authenticator. Attackers may target enrollment, help desk recovery, session theft, malware on the endpoint, or account linking weaknesses instead of attacking the cryptographic exchange itself. The control is strong when the surrounding lifecycle is equally disciplined.

The most common failure mode is not a broken protocol, but a weak implementation choice: permissive fallback methods, poor recovery rules, or incomplete origin and verifier checks. In practice, that means the security benefit depends on the whole authentication journey, not just the presence of a FIDO-capable login button.

When FIDO is deployed well, it materially raises the cost of account takeover. When it is deployed inconsistently, it can create a false sense of security while weaker channels remain exploitable.

Practitioner Guidance

Why practitioners should care: FIDO is most valuable when you need phishing-resistant authentication without the operational burden of passwords. The protocol choice is only one part of the control; rollout decisions should account for enrollment, recovery, and session handling so the strongest factor is not bypassed by weaker defaults.

What to watch for: Pay close attention to fallback authentication, recovery verification, and whether your relying party actually enforces the authenticator properties you think it does. A secure FIDO deployment can still be undermined if password reset, help desk flow, or legacy MFA remains the easiest route in.

Practitioner takeaway: Treat FIDO as a strong authentication foundation, then test the entire account lifecycle around it, especially onboarding, replacement, and recovery.

Related resources from NHI Mgmt Group

• Why do legacy protocols increase NHI risk?
• Why do legacy protocols like NTLM still increase breach risk?
• How should security teams choose between FIDO and certificate-based authentication?
• How can organisations run FIDO and CBA together without creating access sprawl?