Phishing-Resistant MFA: FIDO2, Passkeys and CISA Guidance

Phishing-resistant MFA is the only kind of multi-factor authentication an attacker cannot sit in front of and relay in real time. The problem is that most companies believe they have MFA when what they actually have is phishable MFA: one-time codes (OTP) over SMS or an app, and push approval notifications. Every one of those factors can be stolen or relayed with a modern phishing kit, which is why adversary-in-the-middle (AitM) attacks have turned the second factor into just one more thing the attacker collects along the way. This guide explains exactly where the gap is, what it means for a method to be phishing-resistant, which methods actually qualify (FIDO2/WebAuthn, passkeys and PIV/smart cards), and how they map to CISA guidance and the NIST 800-63 AAL levels.

Phishing-resistant MFA at a glance

• OTP and push are not phishing-resistant: a reverse proxy relays them and steals the already-authenticated session cookie.
• A method resists phishing when authentication is cryptographically bound to the legitimate origin and uses challenge-response with no shared secret.
• The methods that do qualify are FIDO2/WebAuthn (security keys and passkeys) and PIV/smart-card certificate-based authentication.
• CISA recommends FIDO/WebAuthn and PKI; NIST SP 800-63B requires them (verifier impersonation resistance) for its highest level, AAL3.

Why your MFA is still phishable: the AitM attack

The attack that made traditional MFA obsolete does not break cryptography or exploit a server-side CVE: it gets in the middle. In an adversary-in-the-middle (AitM) attack, also called an evil twin, the attacker stands up a reverse proxy that serves a perfect copy of the real login page (Microsoft 365, Okta, Google) because it actually forwards every request to the legitimate server. The victim types their username and password, the proxy relays them, the server asks for the second factor, the victim enters the OTP or approves the push, and the proxy relays that too. When the login completes, the server returns an already-authenticated session cookie and the attacker keeps it. From that point on they own the session and never have to face the MFA prompt again.

The tooling that automates this is public and increasingly common in real campaigns: Evilginx2 (a reverse-proxy framework with per-platform phishlets), Modlishka, Muraena, and phishing-as-a-service suites such as EvilProxy, Tycoon 2FA and Mamba 2FA rented by subscription. The common denominator: the second factor travels over the attacker's channel, so it does not matter how strong the OTP is, it gets relayed intact.

Two classic vectors complete the picture. MFA fatigue (push bombing) fires off dozens of push notifications until the victim, annoyed or confused, approves one: this was the technique behind the 2022 Uber breach and the 0ktapus/Scattered Spider group. SIM swapping ports the victim's SIM at the carrier to receive SMS OTPs, which is why NIST has discouraged SMS for years.

Number matching (entering a number shown on screen into the app) mitigates push bombing, but it does not protect against AitM, because in a reverse proxy the number gets relayed too. It is a bandage, not a cure. For the full map of deception variants, including the evil twin, see types of phishing and how to avoid phishing.

What is phishing-resistant MFA

Phishing-resistant MFA is authentication designed so that no intermediary can reuse the proof of identity, even by capturing it in transit. It relies on three properties that OTP and push lack:

1. Origin binding. The authenticator checks the domain requesting authentication. If the request comes from micr0soft-login.com instead of login.microsoftonline.com, the signature simply is not produced: the user cannot land on the wrong site even if they try.
2. Asymmetric cryptography with no shared secret. No password or code is in flight. The device holds a private key that never leaves it and signs a server challenge; the server only knows the public key, useless to an attacker even if stolen.
3. Session-bound challenge-response. Each authentication signs a unique challenge, so it cannot be recorded and replayed later.

In NIST terminology this is called verifier impersonation resistance: the authenticator refuses to operate against a fake verifier. It is the same principle that makes a passkey more secure than a password and that underpins any serious Zero Trust architecture, where identity is the new perimeter.

Phishing-resistant MFA methods

Only two families of technology meet the phishing-resistance bar today. The rest are better than nothing, but phishable.

FIDO2/WebAuthn: security keys and passkeys

FIDO2 is the open standard from the FIDO Alliance, made up of the browser WebAuthn API (standardised by the W3C) and the CTAP2 protocol to the authenticator. Two usage forms are built on top of it:

• Physical security keys (device-bound): devices such as YubiKey, Feitian or Google Titan that hold the private key in a chip that never exports it. Maximum assurance, ideal for privileged accounts.
• Passkeys: discoverable FIDO2 credentials. They come device-bound (in the laptop TPM or phone Secure Enclave) and synced to the provider's cloud (iCloud Keychain, Google Password Manager, password managers). Synced passkeys are slightly less strict because they depend on the security of that sync account, but they remain phishing-resistant because origin binding still holds.

For the technical detail of how WebAuthn and CTAP build all this, see the dedicated guide to what is FIDO2.

PIV and smart cards (certificate-based authentication)

PKI-based authentication uses a digital certificate stored on a smart card or token: PIV (the US Government standard, FIPS 201), the military CAC, or any corporate smart card. The user proves possession of the private key through challenge-response. It is phishing-resistant for the same reason FIDO2 is, and it fits organisations that already run a public key infrastructure, in exchange for a higher operational cost (readers and certificate management).

In Microsoft environments, Windows Hello for Business achieves the same result with an asymmetric key pair anchored to the device TPM and unlocked by biometrics or a local PIN, a natural deployment path in Entra ID estates.

What does NOT count as phishing-resistant

CISA phishing-resistant MFA guidance

CISA (the US cybersecurity agency) published the fact sheet Implementing Phishing-Resistant MFA, which sets out the reference criterion regulators and auditors now cite. Its key points:

• It recognises two types: FIDO/WebAuthn based (including passkeys) and PKI based (PIV). These are the only two it recommends as the target.
• It explicitly warns that OTP apps, push and SMS are not phishing-resistant, though they remain better than password-only.
• It offers number matching as an interim measure for those who cannot migrate yet, making clear it is a stepping stone, not the goal.

This criterion does not live in isolation. Executive Order 14028 and the OMB Zero Trust strategy (memo M-22-09) require US federal agencies to use phishing-resistant MFA, and CISA's Zero Trust Maturity Model places it at the advanced tier of the identity pillar. A requirement already mandatory for the US Government signals where European frameworks (NIS2, ENS, DORA) will move next.

Alignment with NIST SP 800-63

The NIST SP 800-63B standard defines authenticator assurance levels (AAL):

• AAL2: requires MFA, but allows phishable factors such as TOTP. It is the minimum for most services.
• AAL3: requires a hardware-based cryptographic authenticator and verifier impersonation resistance, that is, phishing-resistant in practice. FIDO2 with a physical key and PIV are the typical paths to AAL3.

The most recent revision of the 800-63 family makes phishing resistance an explicit property and adds specific guidance for syncable authenticators (cloud passkeys). In practice: if your target is AAL3 or protecting critical identities, you need FIDO2 or PKI, there is no shortcut.

Phishing-resistant authentication in practice

Reaching phishing-resistant authentication in a real company is a phased project, not a switch:

1. Start with the privileged. Domain admins, cloud accounts with high permissions and access to critical systems: the attacker's priority target and the best immediate return. This is where identity and access management (IAM) discipline fits best.
2. Hand out physical keys or register passkeys and require the phishing-resistant method in conditional access.
3. Remove the fallbacks. The most common mistake is enabling FIDO2 but leaving TOTP as a backup: the attacker forces a downgrade to the weak method and wastes the effort. For critical accounts, retire the phishable factors.
4. Retire legacy protocols (basic auth, legacy IMAP/POP) that bypass modern MFA entirely.
5. Plan account recovery, the real Achilles heel: a secure re-enrolment procedure that does not quietly reintroduce a phishable channel.
6. Extend to the rest of the workforce with passkeys, measuring coverage and blocked attacks.

One important nuance: phishing-resistant MFA stops credential theft, but not the theft of the already-issued session cookie via infostealer malware on the endpoint. So pair it with device-bound sessions, short-lived tokens and monitoring, the same logic that curbs credential stuffing on the password-reuse side. And if you do not know whether your MFA would survive a real AitM, the most honest way to find out is to test it: in an offensive cybersecurity assessment we simulate a controlled reverse-proxy phishing campaign and measure which factors hold and which fall before an attacker does it for you.

Frequently asked questions

Is the OTP from my authenticator app phishing-resistant?

No. A TOTP code from Google or Microsoft Authenticator is far better than SMS, but it can be relayed in an adversary-in-the-middle attack: the reverse proxy captures the code you type and the resulting session cookie. Only FIDO2/WebAuthn and PKI (PIV) are considered phishing-resistant.

Are passkeys truly phishing-resistant?

Yes. Passkeys are FIDO2 credentials and inherit origin binding: the authenticator refuses to sign for any domain other than the legitimate one. Synced passkeys additionally depend on the security of the sync account, but they keep the resistance; device-bound physical keys offer the highest assurance for privileged accounts.

What does CISA say about phishing-resistant MFA?

CISA recognises two forms: FIDO/WebAuthn (including passkeys) and PKI (PIV). It recommends migrating to them, notes that OTP, push and SMS are not phishing-resistant, and offers number matching only as an interim mitigation during the transition.

Do I need to reach NIST AAL3?

It depends on risk. AAL2 (MFA, even if phishable) is enough for many services, but for privileged identities or critical data, NIST SP 800-63B AAL3 requires a hardware authenticator with verifier impersonation resistance: in practice, FIDO2 with a physical key or PKI.

Does number matching solve the problem?

Not entirely. It stops MFA fatigue because it forces the user to enter a number they can see, but it does not protect against AitM, since in a reverse proxy that number is relayed too. It is a useful improvement, not a substitute for phishing-resistant MFA.

Related resources

• What is FIDO2: phishing-resistant MFA and passkeys
• Passkey vs password: which is more secure in 2026
• Types of phishing: spear, BEC, vishing, smishing and AitM
• How to avoid phishing: a practical guide for businesses
• What is IAM: identity and access management
• What is Zero Trust: architecture, principles and implementation

Phishing-resistant MFA with Secra

At Secra we help B2B organisations close the gap between "we have MFA" and "our MFA survives a real attack." We combine offensive assessment (controlled reverse-proxy phishing campaigns that measure which factors fall) with deployment design: prioritising privileged accounts, choosing between FIDO2 keys and passkeys, and removing phishable fallbacks.

If you want to know whether your authentication would hold against an AitM before an attacker tests it, contact Secra and we will set up an initial no-commitment session.