What is FIDO2?

Key takeaways

• FIDO2 is a set of standards from the FIDO Alliance and W3C (primarily WebAuthn for the web side and CTAP for the device side) that together provide phishing-resistant authentication.
• The protocol cryptographically binds authentication to the specific origin (the website or service). A phishing site cannot complete the authentication even if the user tries.
• FIDO2 supports several authenticator types: hardware security keys, platform authenticators on laptops, and phone-based passkeys.
• For mid-market manufacturers, FIDO2 is the practical destination for phishing-resistant MFA. The protocol is widely supported across major identity providers in 2026.
• ARG validates FIDO2 implementation as part of the engagement: that the rollout is real, that the weak factors are disabled, and that the implementation holds against simulated attacks.

What is FIDO2, and how does it work?

FIDO2 is two complementary standards that work together:

1. WebAuthn (Web Authentication). A W3C standard for the browser-to-relying-party side of the authentication. Browsers expose a JavaScript API that lets websites request authentication from a connected authenticator.
2. CTAP (Client to Authenticator Protocol). A FIDO Alliance standard for the browser-to-authenticator side. CTAP2 is the version used with FIDO2.

The authentication flow:

Registration (first time). The user creates a credential on their authenticator (security key, smartphone with passkey, or platform authenticator). The authenticator generates a public-private key pair specific to the relying party (the website). The public key is sent to the relying party; the private key never leaves the authenticator. The relying party stores the public key associated with the user account.

Authentication (each subsequent time). The relying party sends a challenge to the browser. The browser passes the challenge plus the relying party identifier to the authenticator. The authenticator verifies the user (with biometric, PIN, or simple button-press) and signs the challenge with the private key. The browser sends the signed challenge back. The relying party verifies the signature with the stored public key.

The key property: the authenticator includes the relying party identifier in the signature. If the user is on a phishing site (different relying party identifier), the signature would be invalid; the authenticator refuses to sign because the identifier does not match what the credential was registered against.

The protocol's phishing resistance is not a feature added on top; it is intrinsic to how WebAuthn works. There is no way to phish a FIDO2 credential through a credential-harvest page because the protocol never sends anything phishable.

The difference between platform authenticators and roaming authenticators

FIDO2 authenticators come in two categories.

Platform authenticators. Built into the device the user is authenticating from. Windows Hello on a laptop, Apple Touch ID or Face ID on a Mac or iPhone, fingerprint readers on Android devices. The credential is bound to the device.

Roaming authenticators. External hardware that connects to the device the user is authenticating from. USB security keys (YubiKey, Feitian, Google Titan), NFC-capable keys for mobile use, Bluetooth-connected keys. The credential is on the external device, which moves with the user.

Each has trade-offs:

• Platform authenticators are convenient (no extra hardware, biometric on a familiar device) but are device-bound (lose the laptop, lose access until alternate authenticator is registered).
• Roaming authenticators are portable (work across devices, work even when the user has a new laptop) but require physical hardware (which can be lost, broken, or forgotten).

A mature FIDO2 deployment typically uses both: platform authenticators as the daily-use mechanism for laptops the user works on every day, plus a hardware key as a recovery factor and for accessing systems from new devices. For shop-floor and shared-device scenarios, hardware keys are usually appropriate; platform authenticators do not fit shared-use patterns.

Passkeys complicate the platform-vs-roaming distinction slightly. A synced passkey lives on the user's primary device but syncs across the user's devices (within the same ecosystem: Apple, Google, Microsoft, or password manager). The credential is functionally available across the user's devices without separate registration on each.

Why FIDO2 is structurally phishing-resistant in a way passwords plus MFA are not

The structural difference between FIDO2 and "passwords plus MFA" is in the role of the relying party identifier.

In a traditional password-plus-MFA flow:

• The user submits credentials (password + OTP or push approval) to whatever site is in their browser.
• The site can be the legitimate identity provider or a phishing site that proxies the credentials to the legitimate identity provider.
• The MFA factor verifies possession but does not bind to the origin.
• An adversary-in-the-middle phishing site can capture the complete authentication and use it.

In a FIDO2 flow:

• The browser passes the relying party identifier from the current site to the authenticator.
• The authenticator verifies the user but signs only with the key registered for that specific relying party identifier.
• If the user is on a phishing site, the relying party identifier is different from where the credential was registered.
• The authenticator either refuses to sign (no credential for this site) or signs with the wrong-site credential (which the legitimate identity provider rejects).

The phishing resistance is in the protocol, not in user awareness. The user can be fooled; the cryptography cannot. This is why FIDO2 represents a fundamental shift from "users plus controls" defense to "protocol-level prevention".

Note: FIDO2 does not prevent every authentication-related attack. Stolen sessions (after legitimate authentication) are still possible. Malware on the authenticated device can act in the user's session. Social engineering of the user into performing in-session actions still works. FIDO2 closes the phishing-at-authentication door specifically; other doors remain.

Examples of FIDO2 deployments in manufacturing IT

What FIDO2 looks like in production at mid-market manufacturers:

• Executive and finance hardware keys. YubiKey 5 series issued to the executive team, finance leadership, and AP staff. Primary and backup key per user. Recovery procedure documented; help desk trained.
• Platform authenticators for general workforce. Windows Hello on corporate laptops, Touch ID or Face ID on macOS, biometric on managed Android or iOS devices. Lower cost than hardware keys for the broader workforce; sufficient phishing resistance.
• Hardware keys for shop floor. YubiKey or equivalent at HMI workstations and engineering stations. Physical security on the keys themselves (kept in supervisor offices, signed out per shift). Where the workforce is not appropriate for personal device authenticators, hardware keys fit.
• Conditional access requiring phishing-resistant MFA for sensitive applications. ERP, M365 admin, network admin, OT-adjacent systems. The conditional access policy in Entra or equivalent requires FIDO2 specifically; weaker factors do not work for these targets.
• Vendor remote access through FIDO2-required jump server. Vendor accounts route through a bastion that requires FIDO2 for authentication. The bastion is the only path; vendor accounts without FIDO2 cannot reach the protected systems.
• OAuth grant governance paired with FIDO2. Microsoft 365 admin consent policies tightened so high-scope OAuth grants require admin approval; admin accounts protected with FIDO2. The combination addresses both consent phishing and the broader credential attack surface.

The pattern: FIDO2 deployment is layered. Hardware keys for high-risk roles and shared environments, platform authenticators for general workforce, conditional access policies that route weak factors out of the picture.

How to choose between hardware keys and platform authenticators

For each cohort of users, the choice depends on operational context.

Hardware keys (preferred for):

• Executives, finance, and other high-risk roles where the marginal cost is justified by the risk reduction.
• Users who frequently work on multiple devices (new laptop, shared workstation, vendor laptop).
• Shop-floor, lab, and engineering environments where personal smartphones are restricted.
• Shared-account scenarios where the key represents the account, not the user.
• Users without a corporate-managed device (contractors, board members, advisors).
• Recovery factors paired with platform authenticators.

Platform authenticators (preferred for):

• General workforce on corporate-managed laptops or smartphones.
• Users who work primarily from a single device.
• Scenarios where the cost of hardware keys is not justified by the marginal risk reduction.
• Users with strong biometric capability on their devices.

Mixed deployment (typical):

• Hardware key as primary for high-risk roles, platform authenticator as secondary.
• Platform authenticator as primary for general workforce, hardware key as recovery factor and for new-device scenarios.
• Hardware keys exclusively for shop-floor and shared-device environments.

The cost difference matters at scale. For a 200-person organization, hardware keys (with backups) run $10k-$25k in hardware costs; platform authenticators are essentially free (built into devices). The total cost of the program is dominated by rollout and help desk, not by hardware; the hardware decision should follow operational fit, not just cost.

Best practices for FIDO2 rollout in mixed-device environments

For a mid-market manufacturer with a mix of corporate laptops, BYOD smartphones, shop-floor workstations, and vendor access:

1. Map the device landscape first. What devices exist, what authenticators they support, what cohorts they serve.
2. Define cohort assignments. Which cohorts get hardware keys, which get platform authenticators, which get both. Documented before rollout starts.
3. Pilot with IT and executives. Surface compatibility issues, recovery edge cases, and help-desk procedures before broader rollout.
4. Pre-stage hardware before cohort migration. Hardware keys arrive at the user before the migration date. Documentation prepared. Help desk briefed.
5. Test recovery procedures before production rollout. Lost-device scenario, replaced-device scenario, broken-key scenario. The procedures work before the first user needs them.
6. Integrate with PAM requirements. Privileged access typically requires hardware keys regardless of the user's other factors.
7. Conditional access policy tightening as cohorts complete. Per-cohort and per-application conditional access policies tighten as the migration progresses. The weak factors lose access to specific applications as the cohort moves to FIDO2.
8. Vendor coordination plan. Each vendor with remote access into the environment has a FIDO2 migration plan, with named timeline and verification.
9. Decommission of weak factors at completion. Push MFA, SMS MFA, TOTP MFA disabled tenant-wide once all cohorts are migrated. The decommission is the milestone that completes the program.
10. Continuous validation through adversarial simulation. Simulated credential-harvest and MFA-bypass tests confirm the migration is producing real security improvement.

FIDO2 FAQs

Is FIDO2 the same as a passkey?

Closely related but not identical. FIDO2 is the protocol standard (WebAuthn + CTAP). A passkey is a specific kind of FIDO2 credential designed for end-user convenience, typically stored on a phone or laptop and (often) synced across the user's devices. All passkeys use FIDO2 protocols; not every FIDO2 credential is what consumers call a passkey. See What is a passkey?.

Can FIDO2 work without a smartphone?

Yes. FIDO2 supports several authenticator types: hardware security keys (YubiKey, Feitian, Google Titan), platform authenticators built into laptops (Windows Hello, Apple Touch ID), and (separately) phone-based passkeys. A FIDO2 program can use any combination of these. Hardware keys are common for shop-floor and shared-device scenarios where personal smartphones are not appropriate.

What happens if a hardware key is lost?

The recovery procedure runs through documented help-desk steps. Most organizations issue two keys per user (primary and backup) so the loss of one does not lock the user out. Recovery includes deregistering the lost key, issuing a replacement, and (for high-risk roles) escalating verification before re-issuing. A documented lost-key procedure is required at scale; without it, the help desk becomes the weak link in the authentication chain.

Does FIDO2 work with shop-floor shared accounts?

Yes, with appropriate design. Shared accounts can authenticate with shared hardware keys (kept in the shift supervisor's office and signed out per shift), with shared platform authenticators on dedicated workstations, or by restructuring shared accounts into named accounts (which is usually a better outcome). The right answer depends on the operational context and the security objectives.

How ARG validates FIDO2 implementation during audits

FIDO2 implementation validation is part of ARG's continuous engagement at manufacturing clients. The work is led by James Wall on infrastructure ARG controls.

The validation covers:

• Coverage map. Which users, which applications, which authentication paths are protected with FIDO2 versus weaker factors. Gaps documented.
• Conditional access policy review. Whether the policy actually requires phishing-resistant MFA for sensitive applications, or whether weaker factors slip through exceptions.
• Weak-factor decommission state. Whether push, SMS, and TOTP factors are still available tenant-wide, on specific applications, or only as recovery factors.
• Vendor authentication review. Whether vendor remote access requires phishing-resistant MFA or allows weaker factors.
• Recovery procedure validation. Walking through the lost-key, replaced-device, and break-glass procedures with the help desk to confirm they work.
• Simulated attack testing. Adversary-in-the-middle phishing, MFA fatigue, and consent phishing simulations against named accounts (with prior authorization). The simulations confirm that FIDO2 holds where deployed and surface where weaker factors are still available.

Findings consolidate into the monthly operational packet alongside the rest of the engagement. The remediation backlog includes specific FIDO2-related items: completion of remaining cohort migration, conditional-access policy tightening, vendor authentication coordination, recovery procedure documentation. The output supports insurance underwriting and CMMC / NIST SP 800-171 compliance evidence.

For founding clients, FIDO2 migration validation is part of the monthly retainer alongside the broader identity work.

Apply as a founding client or see how the engagement works for the full delivery cycle.