Phishing-Resistant MFA: FIDO2 and WebAuthn

In September 2023, attackers phoned the IT help desk at a major casino operator, impersonated an employee found on LinkedIn, and talked their way into a credential and MFA reset. Every factor was technically "enabled" — and none of it survived a ten-minute social-engineering call against the recovery path. MGM Resorts lost over $100 million because "MFA enabled" and "MFA secure" are not the same thing.

Why This Matters Now

The MGM breach was not an outlier. It was the loudest signal in a pattern that had been building for years. Throughout 2022 and 2023, CISA tracked a wave of MFA-bypass attacks hitting organizations running Okta, Microsoft Entra ID, and Twilio Authy — all using real-time proxy toolkits that treat traditional MFA as a speed bump rather than a wall.

OMB Memorandum M-22-09, the federal zero trust strategy, mandates phishing-resistant MFA for all agency staff and contractors. This is not aspirational guidance — it is a compliance requirement with deadlines that have already passed for most agencies. CISA's post-incident advisories now explicitly state that SMS, email OTP, and push-notification MFA do not meet the bar.

Meanwhile, the FIDO Alliance's passkey initiative has crossed the adoption threshold. Apple, Google, and Microsoft ship platform authenticators in every current device. The technology that eliminates phishing at the protocol level is no longer exotic — it is built into the hardware your workforce already carries.

Why Traditional MFA Fails

The core problem is simple: traditional MFA methods transmit a secret through a channel the user controls. If an attacker can insert themselves into that channel in real time, the secret is theirs.

Real-Time Phishing Proxies

Tools like Evilginx2, Modlishka, and Muraena sit between the user and the legitimate identity provider. The user sees what looks like their normal login page. They enter their password. They approve the push notification or type their OTP. The proxy relays everything to the real IdP, captures the authenticated session cookie, and replays it from the attacker's infrastructure. The entire attack completes in under three seconds.

This is what hit Twilio in 2022 — the 0ktapus phishing campaign whose fallout cascaded into downstream compromises including Signal and DoorDash. The attacker does not need to crack anything — they just need the user to authenticate normally while the proxy watches.

Push Fatigue and MFA Bombing

Push-notification MFA was never secure — it was convenient. The industry spent five years deploying it as "strong MFA" while ignoring published research showing real-time proxy bypass since 2018. We chose UX over security and called it progress.

MFA bombing exploits the gap between "something you have" and "something you consciously authorize." Attackers trigger dozens of push notifications at 2 AM until the target approves one to make it stop. Microsoft has reported observing thousands of MFA fatigue attempts per day, with the volume climbing sharply year over year. Number matching helped but did not eliminate the vector — a user typing "47" into a push prompt at 3 AM is not making a security decision; they are making it stop.

SIM Swap and SS7 Interception

SMS-based MFA is compromised at the carrier level. SIM swap attacks require nothing more than social engineering a mobile store employee or bribing an insider — the FBI's IC3 reported over $68 million in SIM swap losses in 2021 alone. SS7 protocol vulnerabilities allow interception of SMS messages without any interaction with the carrier at all. These are not theoretical concerns; they are active exploitation paths used against high-value targets daily.

What Makes MFA Phishing-Resistant

The defining characteristic of phishing-resistant MFA is origin binding. The authenticator cryptographically verifies that the authentication request comes from the legitimate relying party — not a proxy, not a lookalike domain, not a man-in-the-middle. The user does not need to detect the phish. The protocol prevents it mechanically.

Origin binding works because the authenticator stores a credential scoped to a specific origin (e.g., login.example.com). When an authentication challenge arrives, the authenticator checks whether the requesting origin matches the stored credential. A phishing proxy running at login-example.com or 1ogin.example.com fails this check silently — no credential is released, no session is created, no error message tells the attacker what went wrong.

This is fundamentally different from OTP or push MFA, where the secret is origin-agnostic. A six-digit code works regardless of which site asked for it. A push approval confirms intent but not destination. Origin binding eliminates the entire class of relay and proxy attacks.

FIDO2 and WebAuthn Explained

FIDO2 is the umbrella specification from the FIDO Alliance that combines two components: WebAuthn (the W3C browser API) and CTAP2 (the protocol for communicating with external authenticators like hardware security keys).

How Authentication Works

Registration: The user registers a FIDO2 authenticator (hardware key or platform biometric) with the relying party. The authenticator generates a unique public-private key pair scoped to that specific origin. Only the public key leaves the device.
Challenge: At login, the relying party sends a cryptographic challenge that includes its origin identifier.
Origin verification: The authenticator checks the challenge origin against its stored credential scope. If the origins do not match, authentication fails silently.
Signing: If the origin matches, the authenticator requires user presence (touch, fingerprint, face scan) and signs the challenge with the private key.
Verification: The relying party verifies the signature against the stored public key. Session established.

A phishing site at evil-bank.com cannot trigger authentication for credentials registered to bank.com. The private key never leaves the authenticator. There is no shared secret to intercept, no code to relay, no push to approve on behalf of someone else.

Platform Authenticators vs. Roaming Authenticators

Platform authenticators are built into the device — Touch ID, Face ID, Windows Hello, Android biometrics. They are convenient (no extra hardware), tied to the device's secure enclave, and sufficient for many deployments. The tradeoff: if the device is compromised at the OS level, the authenticator may be as well.

Roaming authenticators are external hardware keys — YubiKey, Titan, Feitian, SoloKeys. They connect via USB, NFC, or Bluetooth. They are isolated from the host device's software stack, making them resistant to endpoint compromise. Federal deployments typically require roaming authenticators for privileged access.

PIV/CAC as Phishing-Resistant MFA

CAC and PIV smart cards predate FIDO2 by two decades but achieve phishing resistance through the same principle: origin binding via cryptographic proof. The authentication uses a client TLS certificate bound to the server's certificate chain. A proxy site with a different certificate cannot elicit the client credential.

For DoD environments, CAC is already the phishing-resistant authenticator of record. For civilian agencies and contractors without access to the federal PKI, FIDO2 security keys are the designated alternative under M-22-09.

The practical difference: PIV/CAC requires PKI infrastructure, certificate lifecycle management, and physical card readers. FIDO2 requires a USB port or NFC reader. For organizations building new authentication infrastructure rather than extending existing DoD CAC ecosystems, FIDO2 is typically the lower-friction path.

Federal Mandates and Compliance Requirements

OMB M-22-09: The Zero Trust Strategy

M-22-09 is explicit: agencies must use phishing-resistant MFA for all staff, and the memo specifically names FIDO2 and PIV/CAC as compliant methods. Push notifications, SMS, and email OTP do not satisfy the requirement regardless of what vendors claim in their marketing materials.

The memo's identity pillar requires that "agency staff use enterprise-managed identities to access the applications they use in their work" and that "phishing-resistant MFA protects those personnel from sophisticated online attacks." This is not a recommendation — it is a requirement with OMB reporting obligations.

CISA Secure by Design

CISA's Secure by Design guidance explicitly calls out MFA bypass as a vendor responsibility. Identity providers that ship push-only MFA without phishing-resistant options are failing their customers. CISA's post-incident guidance following the Okta and Microsoft breach chains recommends organizations migrate to FIDO2 as a priority control.

Framework Requirements

Framework	MFA Requirement	Phishing-Resistant?
OMB M-22-09	All federal staff and contractors	Explicitly required
FedRAMP High	IA-2(1)/(2): MFA for privileged and non-privileged accounts	Required at High baseline
CMMC Level 2	IA.L2-3.5.3: MFA for local and network access	Recommended, not yet mandated
NIST 800-171 r3	03.05.03: MFA for privileged and non-privileged	Aligned with SP 800-63B AAL3
PCI DSS v4.0	Req 8.4: MFA for CDE access	Phishing resistance "strongly encouraged"

Organizations operating under multiple frameworks benefit from implementing phishing-resistant MFA once and mapping the control across all applicable requirements — a single implementation satisfies the strictest standard and cascades downward.

Implementation Options Compared

Authenticator	Phishing-Resistant	UX Friction	Per-User Cost	Best For
FIDO2 hardware key (YubiKey, Titan)	Yes	Low (tap)	$25-70 per key	High-assurance, privileged access
Platform authenticator (passkey)	Yes	Very low (biometric)	$0 (built-in)	Workforce-wide rollout
PIV/CAC smart card	Yes	Medium (insert + PIN)	$20-40 (gov-issued)	DoD, federal civilian
Push notification (number match)	No	Low	$3-8/user/month	Legacy — migrate away
SMS/email OTP	No	Medium	$0.01-0.10/msg	Unacceptable for sensitive access

Deployment Considerations

Backup and Recovery

Users lose keys. Plan for this before you start issuing hardware:

Two keys per user minimum — one primary, one backup stored securely (not in the laptop bag with the primary).
Recovery flows that do not downgrade. If your recovery path falls back to SMS OTP, you have not deployed phishing-resistant MFA — you have deployed phishing-resistant MFA with a phishable bypass. Supervised in-person re-enrollment or a second registered platform authenticator are acceptable recovery paths.
Help desk hardening. Social engineering the help desk into resetting MFA is how Scattered Spider compromised MGM's Okta tenant in the first place. Help desk identity verification must be at least as strong as the MFA it resets.

Device Compatibility

FIDO2 security keys come in multiple form factors. Match your key procurement to your device fleet:

USB-A for legacy desktops and docking stations
USB-C for modern laptops and tablets
NFC for mobile devices — tap the key to the phone
Lightning is being phased out; USB-C keys with NFC cover both current and legacy Apple devices

Platform authenticators (passkeys) require no additional hardware but depend on device TPM or secure enclave capabilities. Windows 10 1903+, macOS Ventura+, iOS 16+, and Android 9+ all support FIDO2 platform authentication natively.

Application Support and Identity Federation

WebAuthn is supported by every major browser (Chrome, Firefox, Safari, Edge) and most enterprise identity providers (Entra ID, Okta, Ping, Duo). Legacy applications that do not support FIDO2 natively can inherit phishing resistance through SSO federation — authenticate once with FIDO2 at the IdP, access downstream apps via SAML or OIDC tokens.

The gap is internal and legacy tooling. RADIUS-based VPN concentrators, mainframe terminal emulators, and thick-client applications may require protocol bridging or agent-based solutions. Inventory your application portfolio's authentication surface before committing to a rollout timeline.

Conditional Access and Device Trust

Phishing-resistant MFA is strongest when combined with device trust scoring and conditional access policies. A FIDO2 assertion from an unmanaged, unpatched device still represents risk — just not phishing risk. Layer continuous monitoring and just-in-time access on top of phishing-resistant MFA for a complete identity governance posture.

Key Takeaways

"MFA enabled" does not mean "MFA secure." SMS, email OTP, and push notifications are all vulnerable to real-time phishing proxies — the exact attack class used in the Twilio/0ktapus campaign — and phishable recovery paths are how MGM was breached despite MFA.

Phishing-resistant MFA works through origin binding: the authenticator cryptographically verifies the requesting site before releasing any credential. Users do not need to detect the phish — the protocol prevents it.

FIDO2/WebAuthn and PIV/CAC are the only two classes of MFA that meet OMB M-22-09's phishing-resistant requirement. Push with number matching does not qualify.

Deploy two keys per user, harden your help desk recovery flow, and do not build a phishable bypass into your "phishing-resistant" deployment.

Start with privileged access (admins, cloud infra, identity systems) and expand to general workforce. A phased rollout that holds the line on no-downgrade recovery is better than a fast rollout with SMS fallback.

Frequently Asked Questions

Are passkeys the same as FIDO2 security keys?

Passkeys are FIDO2 credentials stored in a platform authenticator (device biometrics) rather than a roaming authenticator (hardware key). Both are phishing-resistant because both use origin-bound public-key cryptography. The difference is where the private key lives: passkeys reside in the device's secure enclave and can sync across devices via the platform vendor's cloud (Apple Keychain, Google Password Manager); hardware security keys store the key on the physical device with no sync capability. For most enterprise deployments, hardware keys offer stronger assurance for privileged access while passkeys provide a practical path for workforce-wide rollout.

Does push notification with number matching count as phishing-resistant?

No. Number matching reduces MFA fatigue attacks by requiring the user to type a displayed number rather than just tapping "Approve," but it does not address real-time proxy attacks. An attacker running Evilginx2 relays the number-matching challenge to the user in real time — the user sees the correct number, types it, and the attacker captures the session. CISA and OMB M-22-09 do not recognize number-matching push as phishing-resistant. It is an improvement over basic push but not a substitute for origin-bound authentication.

What happens if a user loses their FIDO2 security key?

This is a deployment design problem, not a technology limitation. The standard approach: issue two keys at enrollment (primary and backup), register both with the identity provider, and store the backup in a physically separate location. If both are lost, recovery must not downgrade to phishable MFA. Acceptable recovery paths include supervised in-person re-enrollment with government-issued ID verification, recovery through a second registered platform authenticator, or a time-delayed recovery flow with out-of-band identity confirmation by the user's manager. The help desk reset path must be hardened against social engineering — this is exactly how the MGM breach started.

Can FIDO2 work in air-gapped or classified environments?

Yes. FIDO2 authentication is a local cryptographic operation between the authenticator and the relying party — it does not require internet connectivity beyond reaching the application itself. In SIPR or air-gapped networks, FIDO2 security keys function identically to how they work on the public internet. The challenge-response happens over USB or NFC between the key and the local browser; no external callout is required. For classified environments that already use CAC/PIV, the existing smart card infrastructure already satisfies phishing-resistant requirements without deploying additional FIDO2 keys.

How does phishing-resistant MFA relate to zero trust architecture?

Phishing-resistant MFA is one of the five pillars (Identity) in the zero trust architecture model defined by OMB M-22-09 and CISA's Zero Trust Maturity Model. It ensures that identity verification cannot be subverted by credential theft or session hijacking at the authentication layer. However, zero trust does not stop at authentication — it extends to device trust, network segmentation, application-layer authorization, and continuous monitoring. Phishing-resistant MFA is the foundation that makes the other pillars trustworthy; without it, an attacker who bypasses MFA inherits all access that the compromised identity holds, regardless of how well the other pillars are implemented.

How Advisedly Helps

Advisedly maps phishing-resistant MFA implementation to every applicable control across 500+ compliance frameworks simultaneously — from OMB M-22-09's identity pillar through CMMC IA.L2-3.5.3 to FedRAMP IA-2(1). The platform tracks authenticator deployment status per user population, flags recovery flows that downgrade to phishable methods, and generates the control-implementation narrative auditors expect for each framework's MFA requirement. For organizations juggling federal mandates alongside commercial standards like PCI DSS v4.0, a single phishing-resistant MFA deployment maps once and satisfies everywhere, with continuous monitoring that alerts when configuration drift reintroduces phishable fallback paths: begin@advisedly.ai