What Is Phishing-Resistant MFA?

Standard MFA relies on codes and push approvals that a user enters or accepts by hand, and a proxy site can capture and relay both. Phishing-resistant MFA uses a cryptographic key pair bound to the legitimate domain, so nothing a proxy captures can be reused. That binding is what stops adversary-in-the-middle (AiTM) attacks.

Standard MFA methods add a second factor to a password, but none of them check where the login request comes from. An AiTM proxy sits between the user and the real site, relays the password and code, and steals the resulting session cookie.

Phishing-resistant MFA closes that opening. It generates a cryptographic signature that only validates against the domain that requested it, so a proxy site never receives a usable credential.

This distinction between the two approaches explains why credential theft persists even at organizations that already require MFA. The next section traces how attackers adapted to standard MFA and why that evolution makes phishing-resistant methods a baseline rather than an upgrade.

Standard MFA is failing because attackers no longer guess passwords; they intercept entire login sessions. SIM-swapping, email compromise, and push-notification spam all defeat one-time codes and approvals without breaking any encryption. AiTM proxies then take the attack further, capturing live session cookies that let attackers skip the login screen entirely.
 

The Vulnerabilities of Standard MFA (Including SMS, OTP, and Push)

Standard MFA factors depend on human interaction, and human interaction can be manipulated. Every method below asks a person to read a code, tap a notification, or trust an inbox, giving social engineers an opening that cryptography closes:

• SMS codes: SIM-swapping lets an attacker port a victim’s phone number to a new device, so the code arrives on the attacker’s phone instead.
• Email-based OTPs: If the linked email account is already compromised, the one-time code arrives directly in the attacker’s inbox.
• Push notifications: Attackers who already hold a stolen password can trigger MFA fatigue attacks, also called push bombing, by sending repeated approval requests until the victim taps accept out of frustration.

The Rise of AiTM Phishing Proxies

AiTM tools like Evilginx act like reverse proxies that sit between the victim and the real corporate login page, relaying every request in both directions. The victim sees the authentic site’s content as it’s rendered by Evilginx and then enters a password and completes MFA normally. Evilginx forwards that traffic to the legitimate server and captures the session cookie the server returns after authentication.

This is why standard MFA cannot stop AiTM. The code the victim enters is genuinely valid. The proxy simply relays it to the real site in real time, then walks away with the session cookie needed to bypass MFA entirely on future requests.

MFA Fatigue and How Attackers Weaponize Push Notifications

Push bombing turns a security feature into a nuisance attack. An attacker who already holds stolen credentials floods the victim’s phone with dozens of approval prompts, often late at night or during a busy stretch of the workday. Most people approve one prompt just to stop the noise, handing over account access without ever seeing a fake login page.

The Post-Auth Blind Spot: How Attackers Steal Active Session Cookies

Once a session cookie exists, MFA has nothing left to check. The cookie tells the server a user already proved identity, so every request after login skips authentication entirely. An AiTM proxy captures the session cookie the instant the real server issues it, then feeds it into a browser extension or replay tool on the attacker’s machine. The server sees a valid, already-authenticated session and grants access without asking for a password or an MFA prompt again.

Stolen cookies can also come from malware or a compromised browser profile, which widens the blind spot further. This gap explains why login security alone cannot stop session takeovers. A cookie stolen after a clean, phishing-resistant login is just as usable to an attacker as one stolen after a weak login, since the theft happens after MFA has already done its job.

Phishing-resistant MFA replaces anything a user types or approves with a private key that never leaves the device. A key signs a login challenge locally, and the signature validates only when the requesting domain matches the domain registered with the key. A proxy site gets nothing it can reuse.

Public Key Cryptography Manages Shared Secrets

Traditional MFA depends on shared secrets, such as a password, a one-time code, or a value both the user and the server must know or generate the same way. Shared secrets can always leak, whether through a proxy site, a database breach, or a copied text message. Phishing-resistant MFA removes that dependency through a different process entirely:

• Key generation: During registration, the device creates a mathematically linked public-private key pair rather than a password.
• Public key storage: The public key is transmitted to the service and stays on its server, where it verifies signatures but cannot create them.
• Private key isolation: The private key stays inside the device’s secure hardware enclave, a dedicated chip separate from the main operating system.
• Local signing: Every login signs a challenge locally, so no shared value ever needs to travel across the network.

Because the private key never crosses the network, there’s no password to steal and no value an attacker can copy from a proxy site. Every authentication event happens through a local signature, not a shared value passed back and forth between the user and the server.

What Is Origin Binding?

Origin binding is the cryptographic mechanism that ties a signed credential to one specific, verified domain name, such as login.zscaler.com. The browser or operating system checks the exact domain making the authentication request and passes that domain to the authenticator as part of the challenge.

If a user lands on a look-alike phishing domain, the authenticator compares the domain in the request against the domain recorded during registration. The two will not match, since the phishing domain uses a different address even when the page looks identical. The authenticator refuses to sign the cryptographic challenge, and authentication stops before any credential or session data changes hands.

This single check is what separates phishing-resistant MFA from every prior generation of MFA. Standard MFA has no concept of domain verification, so a proxy site can request and receive a valid code. Origin binding makes that request fail automatically, without requiring the user to recognize the fake phishing site or inspect a URL.

Attackers rarely break phishing-resistant MFA directly. Instead, they steal session cookies after login, push users toward weaker fallback methods, or hide the FIDO2 option on a proxied login page. Recent phishing kits and security research show each technique, and each one exploits a gap next to the cryptography rather than the cryptography itself.

BlackForce and Real-Time Session Hijacking

The ThreatLabz 2026 Phishing and Initial Access Report identifies session hijacking kits, such as BlackForce, that capture credentials and MFA codes during the live login flow and take over the resulting session in real time. The report also found that 95.2% of phishing activity was delivered over encrypted channels, hiding it from tools that don’t inspect TLS/SSL traffic.

Tycoon 2FA and the Downgrade Redirect

Tycoon 2FA, a phishing-as-a-service platform disrupted by Europol and industry partners in March 2026, included code that detected passkey prompts. Rather than attacking the passkey itself, the kit redirects the login flow toward a weaker fallback method, such as an SMS code or an authenticator app, then phishes that instead.

The Serverless Proxy Downgrade Attack

In 2022, researchers demonstrated a proof-of-concept authentication downgrade attack that abuses Cloudflare Workers as a transparent proxy. The technique manipulates login page configuration or injects CSS to hide the FIDO2 option from a user’s view entirely, forcing a fallback to phishable push notifications or one-time codes even when a hardware key is already registered on the account.

Each case points to the same lesson. Attackers rarely attack the cryptography directly. They attack whatever’s next to it, whether a fallback option, a hidden configuration setting, or an unprotected session cookie.

FIDO2 made phishing resistance move from a niche security control to something built directly into everyday hardware. Federal policy has since caught up, and current standards now spell out exactly which authenticators qualify and which fall short.

FIDO2, WebAuthn, and Passkeys

FIDO2 is a universal authentication standard from the FIDO Alliance that pairs a hardware-backed private key with the public key cryptography described earlier. FIDO2 has two parts: WebAuthn, the browser API built into Chrome, Safari, Edge, and Firefox, and the Client to Authenticator Protocol (CTAP2), which connects browsers and operating systems to authenticators such as security keys and Windows Hello.

Passkeys built on this standard come in two forms:

• Device-bound passkeys: The private key lives on a physical security key or a dedicated hardware chip and can’t be synced or exported.
• Synced passkeys: The key material is stored in a cloud keychain, such as iCloud Keychain or Google Password Manager, so the credential follows the user across every device tied to that account

The convenience of passkeys comes at a cost, since a compromised cloud account can expose a synced key in ways a device-bound key never allows. Security teams often reserve synced passkeys for lower-risk users and applications.

PIV Smart Cards and Public Key Infrastructure

Personal Identity Verification (PIV) smart cards predate FIDO2 but deliver comparable phishing resistance through established public key infrastructure. A PIV card holds a private key issued by a trusted certificate authority, and the card must be physically inserted into a reader to sign an authentication challenge, which ties the credential to specific hardware.

The Federal Zero Trust Mandate: OMB M-22-09 and NIST SP 800-63-4

The White House Office of Management and Budget (OMB) memo M-22-09, issued in January 2022, directed federal agencies to move away from standard MFA and adopt phishing-resistant authentication as part of the government’s broader zero trust strategy. The memo named PIV cards and FIDO2 authenticators as the accepted methods and explicitly excluded SMS, OTP, and push-based approvals from meeting that requirement.

NIST Special Publication 800-63-4, finalized in 2025, extended that policy direction into a precise technical requirement. Authenticator Assurance Level 3 (AAL3), the highest tier NIST defines, now mandates a phishing-resistant authenticator with a non-exportable private key.

That single requirement rules out synced passkeys at AAL3, since cloud-backed keys can be copied across devices, and it favors device-bound passkeys and PIV cards instead. AAL2 takes a lighter approach, requiring agencies only to offer a phishing-resistant option rather than mandate one outright, allowing organizations to transition gradually.

Organizations implement phishing-resistant MFA in phases: connect applications to a FIDO2-capable identity provider (IdP), secure the recovery process, protect active sessions, and remove weaker fallback methods. Skipping any phase leaves legacy apps, recovery flows, or session cookies open to proxy and downgrade attacks.

1. Assess compatibility: Confirm which applications authenticate through the IdP, and route legacy apps through a single sign-on (SSO) gateway.
2. Secure recovery: Use Temporary Access Passes (TAPs) for registration and replacement keys instead of SMS or password fallbacks.
3. Protect the session: Add inline TLS/SSL inspection and browser isolation to stop cookie theft after login.
4. Enforce: Disable SMS, push, and OTP fallbacks in the IdP once users register phishing-resistant authenticators.

Here’s a more detailed review of all the steps that modern enterprises should follow as they implement phishing-resistant MFA:

1) Assess System Compatibility and IdP Integration

Most enterprise IdPs, such as Okta and Microsoft Entra ID, support FIDO2 and WebAuthn natively. The first step is to confirm which applications can authenticate through that identity provider rather than handling logins independently.

Modern SaaS platforms typically connect without much rework, as they already support Security Assertion Markup Language (SAML) or OpenID Connect. Legacy applications present the harder case, considering many older, on-premises tools weren’t built to recognize FIDO2 credentials directly.

Connecting these systems to an SSO gateway lets the IdP handle the phishing-resistant authentication step, then pass a trusted session token to the legacy app. This process effectively extends protection without rewriting the application itself.

2) Design Secure Recovery and Bootstrapping Flows

A lost or damaged security key cannot become a shortcut back to passwords or SMS codes, since that shortcut reopens the exact vulnerability that phishing-resistant MFA closes. Recovery needs its own phishing-resistant path, not a fallback to weaker methods.

TAPs paired with identity verification through a help desk or manager give a practical answer. TAPs grant short-lived access strictly for registering a new key, then later expire automatically. This keeps onboarding and recovery inside the same security model the organization just adopted, rather than carving out an exception that attackers can target.

3) Layer Identity with Runtime Threat Isolation

Securing the login portal solves only half the problem. Once a session cookie exists on a compromised or unmanaged device, an attacker no longer needs to touch MFA, since the cookie already proves an authenticated state.

Inline network security controls close that remaining exposure. Real-time SSL inspection can flag traffic heading to a known AiTM proxy domain before a session ever completes, and browser isolation sandboxes render risky sessions in an isolated environment so a compromised endpoint never touches the actual corporate application. Layering these controls on top of phishing-resistant MFA protects the full session.

4) Enforce Removal of Phishing-Prone Fallback Methods

A phishing-resistant rollout is only as strong as its weakest accepted method. An identity provider that still allows SMS, push, or OTP as a fallback gives attackers an easy target, since a downgrade attack or a help desk call can trigger it and bypass FIDO2 entirely.

Enrollment coverage, not a fixed date, should drive the removal schedule. Retire fallbacks one method at a time, starting with the weakest, such as SMS, and track registration by department so no group loses access before its users are ready. This staged approach closes the opening attackers look for while giving IT time to resolve incomplete enrollment.

It's a best practice to monitor authentication logs for downgrade attempts, since a spike in fallback usage often signals an active attack rather than a forgotten device. Keep break-glass accounts few and separately monitored, and announce each cutover well in advance so enforcement feels routine to users instead of becoming a sudden lockout that attackers can exploit through social engineering.

The Zscaler Zero Trust Exchange™ protects the sessions that phishing-resistant MFA leaves exposed. With Zscaler, enterprises mitigate lateral movement risks by enforcing risk-based posture checks, application-level segmentation, and dynamic step-up authentication.

Zscaler Private Access enforces application-specific segmentation, so a compromised identity can reach only the one application it was authorized for, never the broader network. Step-Up Authentication, which runs through Zscaler Authentication Service (formerly ZIdentity), can require a FIDO2 challenge when user and entity behavior analytics (UEBA), device posture, or application sensitivity signal higher risk, not just at initial login.

To learn more about Zscaler, request a demo or a free identity assessment.