Phishing-Resistant MFA Explained: FIDO2, Passkeys, and Conditional Access Best Practices

CISA calls FIDO2/WebAuthn the "gold standard" for MFA. Here's how phishing-resistant MFA, passkeys, and Conditional Access actually fit together.

Not all MFA is equal

CISA doesn't just recommend multi-factor authentication — it explicitly ranks it. In guidance it released in October 2022, the agency described FIDO/WebAuthn-based authentication as the "gold standard" for MFA, urging organizations to prioritize migrating to it as part of applying Zero Trust principles.[1]

That's a meaningful distinction from "any MFA is good MFA." Some forms of MFA can be defeated with nothing more than a convincing fake login page.

What "phishing-resistant" actually means

SecurityWeek's coverage of the CISA guidance lays out why the distinction matters: some MFA methods are vulnerable to phishing sites requesting a one-time code, to "push bombing" attacks, and to SIM swapping, where an attacker convinces a carrier to move a victim's phone number to an attacker-controlled SIM.[2] Some attackers also exploit weaknesses in the Signaling System 7 (SS7) telecom protocol to intercept codes sent by SMS or voice call.[2]

FIDO2/WebAuthn avoids this because the cryptographic exchange is bound to the actual origin — the domain — the user is authenticating to. A lookalike phishing domain simply can't complete the handshake, even if the user has already been fooled into visiting it.

The MFA hierarchy, from weakest to strongest

A legal summary of CISA's fact sheet notes that the agency identifies app-based MFA and SMS/voice MFA as particularly vulnerable, and says the currently available phishing-resistant options are limited to FIDO/WebAuthn and PKI-based smart card authentication.[3] SMS and voice MFA should only be used as a last resort.[3]

Roughly, in order of resistance to phishing:

• SMS/voice OTP — weakest; vulnerable to phishing, SIM swap, and SS7 interception
• App-based push (plain accept/deny) — vulnerable to push bombing / MFA fatigue
• App-based push with number matching — an interim mitigation, still phishable through a real-time relay attack
• TOTP codes from an authenticator app — still phishable; a fake login page can relay the code in real time
• FIDO2/WebAuthn security keys and platform authenticators (passkeys) — phishing-resistant; origin-bound

Rolling it out: CISA's phased approach

The CISA fact sheets released on October 31, 2022 outline a practical path: standardize on FIDO standards and WebAuthn, inventory which systems actually support MFA, and roll out phishing-resistant MFA in phases rather than all at once.[4] For organizations that rely on push-notification MFA and can't move to phishing-resistant MFA immediately, CISA recommends number matching as an interim mitigation for MFA fatigue attacks, while acknowledging it's weaker than phishing-resistant MFA.[4]

The suggested starting points are the resources attackers go after first: email, file servers, and remote access systems that reach corporate data. That prioritization isn't arbitrary — FIDO2 rollout is genuinely constrained by hardware procurement, device compatibility, and enrollment friction. A single flag-flip across an entire organization tends to produce a wave of help-desk lockouts, and that pressure often pushes IT teams into quietly reopening the phishable fallback paths they were trying to close.

Where passkeys fit in

Passkeys are FIDO2 credentials wrapped in consumer-friendly language and, increasingly, cloud sync. That sync detail matters for enterprise deployments. A synced passkey — backed up through a cloud account like iCloud Keychain or Google Password Manager — inherits the security of the account it syncs through, which reintroduces a phishable or account-recovery attack surface one layer up. A device-bound passkey, such as a hardware security key or a platform authenticator without sync enabled, doesn't carry that dependency.

For privileged accounts — admins, break-glass accounts, anyone with standing access to sensitive systems — device-bound FIDO2 hardware keys are the stronger choice precisely because they remove the cloud-recovery path as an attack vector.

Conditional Access: MFA is necessary, not sufficient

Phishing-resistant MFA answers "is this really the account owner." It doesn't answer "should this session, from this device, in this context, be trusted right now." That's the role of Conditional Access (or an equivalent policy engine) — evaluating signals like device compliance, location, and sign-in risk, and requiring stronger authentication or blocking access when those signals look wrong.

A few practical patterns worth building into a baseline policy:

• Require phishing-resistant MFA specifically for privileged roles, scoped by authentication strength rather than just "any MFA was satisfied"
• Block legacy authentication protocols that can't support a modern MFA challenge at all — a common bypass path
• Tie access to device compliance, so a stolen or replayed token from an unmanaged device still gets flagged
• Treat session/token replay as a separate risk from initial login — phishing-resistant MFA stops credential theft at sign-in, but it doesn't by itself stop a stolen session cookie from an adversary-in-the-middle proxy; short token lifetimes and continuous access evaluation are the complementary control

Removing the fallback paths

A phishing-resistant MFA deployment is only as strong as its weakest fallback. If SMS recovery, phone-based help-desk identity verification, or a break-glass procedure can still get someone back into an account, an attacker will simply target that path instead of trying to defeat FIDO2 directly. Locking down the primary factor while leaving recovery and help-desk paths on the old, phishable methods is one of the more common gaps between "we deployed passkeys" and "we're actually phishing-resistant."

1. Inventory systems and identify which support FIDO2/WebAuthn natively versus which need a compensating control.
2. Start with high-value targets — email, VPN/remote access, file and document platforms, admin consoles.
3. Move push-notification users to number matching as an interim step where FIDO2 isn't yet feasible.
4. Issue device-bound FIDO2 keys to privileged and admin accounts specifically; synced passkeys are reasonable for lower-risk general users.
5. Layer Conditional Access policies on top: device compliance, authentication-strength requirements, legacy-auth blocking.
6. Audit and close phishable recovery and help-desk fallback paths before declaring the rollout complete.
7. Phase enrollment with a real support plan — a single hard cutover tends to generate lockouts that pressure teams into reopening weak fallbacks.

Security takeaway

Phishing-resistant MFA and Conditional Access solve two different problems, and treating them as one checkbox is how gaps get introduced. FIDO2/WebAuthn removes phishing as a viable path to credential theft; Conditional Access decides whether a given session should be trusted at all, even after authentication succeeds. Neither one covers for the other — and neither one covers for a help-desk process that still resets access over the phone with an SMS code.

Sources & References

• [1] Cybersecurity Dive — CISA calls FIDO/WebAuthn MFA the "gold standard" — View source
• [2] SecurityWeek — CISA Urges Organizations to Implement Phishing-Resistant MFA — View source
• [3] Bricker & Eckler — summary of CISA guidance discouraging app-based, SMS, and voice MFA — View source
• [4] CISA — Releases Guidance on Phishing-Resistant and Numbers Matching Multifactor Authentication, October 31, 2022 — View source