Multi-factor authentication became the standard security recommendation because it worked. Adding a second factor stopped the vast majority of credential-based account takeovers. Then attackers adapted. Tools like Evilginx, Tycoon 2FA, and EvilProxy turned MFA bypass from a specialty capability into a commodity service available for as little as $120 a month. The result is a threat landscape where 84 percent of compromised accounts that Obsidian Security observed had MFA enabled at the time of compromise. The second factor did not save them, because the attack never needed to defeat the second factor — it just needed to steal the session token after authentication completed.
FIDO2 closes this gap at the protocol level. Understanding why requires understanding how traditional MFA fails, how FIDO2 is structured differently, and what realistic deployment actually involves.
Why Traditional MFA Fails Against AiTM
Adversary-in-the-middle (AiTM) phishing is not a brute-force attack on your second factor. It is a real-time proxy attack on your authentication session. The attacker stands between you and the legitimate service, relaying traffic in both directions. When you enter your password, the proxy captures it and forwards it. When the service requests your MFA code, the proxy forwards that prompt to you. When you enter your code, the proxy captures and relays it. Authentication completes successfully — from the service's perspective — and the attacker receives the resulting session token, which they can then use independently, with no further need for credentials or codes.
This works against every MFA method that relies on a shared secret or a one-time code: SMS, TOTP authenticator apps, email OTP, and push notifications without number matching. All of them produce something the user sends over a network channel that an attacker can intercept and relay in real time. The Canadian Centre for Cyber Security tracked AiTM campaigns against Microsoft Entra ID accounts from 2023 through mid-2025 and documented that proxy-based AiTM kits had almost entirely replaced traditional credential phishing — accounting for 88 to 100 percent of observed AiTM activity in most months of early 2025. Microsoft reported a 146 percent rise in AiTM attacks over 2024 alone.
MFA fatigue attacks — flooding a user with push notifications until they approve one out of frustration — affected 14 percent of security incidents in the 2025 Verizon Data Breach Investigations Report, making it the dominant MFA bypass method alongside AiTM. These are entirely separate attack vectors that both render push-based MFA unreliable for high-risk access.
The underlying problem is that these methods all rely on shared secrets — something transmitted from one party to another. Any secret that crosses a network can be intercepted. FIDO2 eliminates shared secrets from the authentication flow entirely.
How FIDO2 Works
FIDO2 is the umbrella specification developed by the FIDO Alliance and released in 2018. It consists of two components that work together: WebAuthn and CTAP2.
WebAuthn (Web Authentication) is a W3C standard implemented in browsers and platforms. It defines the API through which web applications communicate with authenticators — the devices or software that hold your cryptographic keys. WebAuthn became a formal W3C web standard in 2019 and is now natively supported in all major browsers.
CTAP2 (Client-to-Authenticator Protocol 2) handles the communication between the browser or operating system and external authenticators — hardware security keys, smartphones, or other roaming devices — over USB, NFC, or Bluetooth.
The authentication flow works as follows. When a user registers with a FIDO2-enabled service, the authenticator generates a unique asymmetric key pair for that specific relying party (the website or service). The public key is sent to the service and stored there. The private key never leaves the authenticator. Each key pair is generated per-site, so there is no credential reuse across services.
When the user authenticates, the service sends a cryptographic challenge — a nonce unique to that session. The authenticator uses the private key to sign the challenge, and sends the signature back. The service verifies the signature using the stored public key. If the signatures match, authentication succeeds.
Before signing any challenge, the authenticator verifies the origin — the domain making the authentication request. The key pair was registered to a specific domain. If the request comes from any other domain, including a convincing lookalike, the authenticator has no registered key for it and cannot produce a valid response. This is origin binding, and it is why AiTM attacks cannot work against FIDO2.
There is nothing for an AiTM proxy to steal. The private key never crosses the network. The signed challenge is valid only for the session it was issued in and cryptographically bound to the legitimate domain. Even if an attacker intercepts the signed response in transit, they cannot reuse it — the challenge is consumed once and the signature is domain-scoped. Session hijacking after FIDO2 authentication still requires stealing a session token through other means, but the authentication step itself is structurally immune to proxy-based interception.
Authenticator Types: Hardware Keys, Passkeys, and Platform Authenticators
Not all FIDO2 implementations offer identical security guarantees. The type of authenticator determines how the private key is stored and whether it can be synchronized across devices.
Hardware security keys (roaming authenticators) are physical devices — USB, NFC, or Bluetooth — such as YubiKeys or Google Titan keys. The private key is stored on the hardware itself, never exportable, and cannot be extracted even if the device is compromised at the software level. These keys meet NIST SP 800-63B's AAL3 requirements when properly configured. They are the highest-assurance option and are what CISA recommends for privileged users, administrators, and anyone in highly regulated environments.
Platform authenticators are built into devices — Windows Hello, Touch ID, Face ID. The private key is stored in the device's secure enclave or Trusted Platform Module. These are device-bound and non-exportable, meeting AAL2 requirements. They provide excellent security with minimal friction for most enterprise users.
Synced passkeys store FIDO2 credentials in a cloud keychain (Apple iCloud Keychain, Google Password Manager, or a password manager like 1Password). The credential is synchronized across a user's devices. This dramatically improves usability and reduces the account lockout risk when a device is lost. The trade-off is that the private key exists in more places. NIST SP 800-63B-4, finalized in July 2025, permits synced passkeys at AAL2 but explicitly excludes them from AAL3, which requires a hardware-backed non-exportable key.
CISA designates FIDO2/WebAuthn and PKI-based authentication (PIV/CAC) as the only two approaches that meet its definition of phishing-resistant MFA. SMS, TOTP, and push notifications are not on that list.
For federal agencies, OMB M-22-09 mandates phishing-resistant MFA and explicitly references WebAuthn/FIDO2 and PIV as the only acceptable implementations. For the private sector, this mandate sets a clear benchmark: if the US government has concluded that TOTP and push are insufficient for federal systems, organizations holding sensitive data should seriously examine whether those methods are sufficient for theirs.
Real-World Validation
The case for FIDO2 is not theoretical. Two well-documented incidents provide concrete evidence of what phishing-resistant authentication does and does not prevent.
In 2018, Google deployed hardware security keys to all of its more than 85,000 employees. Since the deployment, Google has reported zero successful phishing attacks against employee accounts. The same credential-theft campaigns that target other large organizations have simply failed to produce any compromises at Google, because there is nothing to phish — the private key stays on the hardware key and the signed response cannot be reused.
In August 2022, Cloudflare was targeted by the same sophisticated phishing campaign that compromised Twilio and other technology companies. Cloudflare employees received the same lure messages, and some clicked through and entered their credentials into the fake login page. The campaign succeeded against other targets. At Cloudflare, it failed — because Cloudflare required hardware security keys for authentication. Employees who completed the phishing flow handed over credentials and TOTP codes, but those were not enough. The attack could not complete authentication against the real service because the hardware key, which never left the employee's possession, did not sign a challenge for the attacker's proxy domain.
These are not edge cases. They are examples of FIDO2 working exactly as designed under adversarial conditions that actively defeated organizations using traditional MFA.
Deployment Considerations
FIDO2 deployment is real-world work, and the practical obstacles are predictable enough that organizations can plan for them in advance.
Legacy application compatibility is the primary technical constraint. Applications using older authentication protocols cannot natively support FIDO2. The standard approach is to federate authentication through a modern identity provider (IdP) — Entra ID, Okta, Ping, or similar — that handles FIDO2 authentication and issues tokens downstream to legacy applications via SAML or OIDC. The IdP becomes the relying party for WebAuthn, and the legacy applications never need to change. Full migration can span years in complex environments; prioritizing privileged access, email, VPN, and SSO entry points first provides the highest risk reduction per unit of effort.
Account recovery and key loss require defined procedures before deployment, not after. If a user loses their only hardware key and has no backup, they are locked out. Organizations deploying hardware keys should issue two keys per user and require both to be registered, or combine hardware keys with synced passkeys as a fallback for non-AAL3 use cases. Recovery workflows that fall back to SMS or email OTP undermine the phishing-resistant properties of the primary authenticator for anyone who knows the recovery path exists.
Mobile and shared-device environments add complexity. Hardware keys with NFC work on most modern phones. For shared workstations, roaming authenticators and careful session management are necessary since platform authenticators are bound to the individual device.
Allowing TOTP or SMS as a fallback option entirely for users who find FIDO2 inconvenient negates the security benefit for those users. Phishing-resistant authentication is only as strong as the weakest path to the account. If attackers can trigger a fallback to a phishable factor, they will.
Cost and procurement vary by authenticator type. Hardware security keys cost roughly $25–$70 per key at volume, and a two-key-per-user policy doubles that. For organizations deploying at scale, synced passkeys through platform authenticators (Windows Hello, Touch ID) cost nothing beyond IdP configuration and eliminate the procurement and loss problem entirely, at the cost of not meeting AAL3 for users who need that assurance level.
Key Takeaways
- MFA-enabled does not mean phishing-resistant: SMS, TOTP, and push notifications are all bypassable in real time by AiTM proxy kits that are widely available and actively used. The question is not whether MFA is on, but which MFA.
- FIDO2 stops AiTM by design: Private keys never leave the authenticator. Signed challenges are domain-scoped and session-specific. There is nothing for a proxy to intercept and reuse. No other widely deployed authentication standard provides this guarantee.
- Authenticator choice determines assurance level: Hardware keys meet AAL3. Platform authenticators and synced passkeys meet AAL2. NIST SP 800-63B-4 (July 2025) explicitly prohibits synced passkeys at AAL3. Match the authenticator to the risk level of the access being protected.
- Federation is the practical deployment path: Enable FIDO2 at the IdP and federate to legacy applications. Full application-by-application migration is not required to get most of the security benefit quickly.
- Recovery paths are attack paths: Any fallback to a phishable factor is a vulnerability. Design recovery procedures before deployment and harden them with the same rigor as the primary authentication method.
The shift from phishable to phishing-resistant authentication is structural, not incremental. It does not make your existing MFA policies slightly better — it eliminates an entire class of attack that is currently the dominant method of identity compromise in enterprise environments. Google's and Cloudflare's results under real adversarial conditions are among the clearest evidence available that authentication architecture produces outcomes that no amount of security awareness training can replicate.