Secure MFA Despite Reverse Proxy: What Actually Holds Up in 2026

From Offense to Defense

In two earlier articles we documented the offensive side: one on Modlishka as a flexible HTTP reverse proxy for phishing simulations, and one comparing EvilnoVNC with classic reverse proxies. Both pieces show how Adversary-in-the-Middle (AiTM) phishing is set up in our audits. What has changed since: AiTM is no longer a red-team tool but mainstream in the criminal market. The defense has to catch up, and since the ENISA Technical Implementation Guide from Q1 2026 it is also under regulatory obligation.

This article describes what actually defends against reverse proxy phishing in 2026, what the NIS-2 transposition concretely demands, and which implementation mistakes we encounter regularly in audits.

Why Classic MFA No Longer Holds

Reverse proxy phishing is no longer a niche topic. The business model is called Phishing-as-a-Service, and it is highly professionalized. Tycoon 2FA holds about three quarters of the market in current threat reports, EvilProxy and open-source frameworks like Evilginx share the rest. Public reports now attribute the majority of account compromise incidents to such kits.

The attack itself is compact. The attacker registers a domain such as login-microsoft365-secure.example and runs a reverse proxy on it that mirrors the real Microsoft login page. The victim opens a phishing mail, clicks, enters password and MFA factor. The proxy forwards both to the real site and intercepts the resulting session cookie. The technical depth lives in the linked pentester articles.

The central observation is the shift in the attack target. AiTM does not aim at the second factor but at the session that results from successful MFA. As soon as the attacker holds a valid cookie, the second factor is irrelevant. The login is complete, the session is legitimate, the attacker operates as the employee. What classic MFA delivers is a time-limited confirmation. The reverse proxy does not steal the confirmation; it takes the result.

What "Phishing-Resistant" Actually Means Technically

The term has been overstretched in the past two years. It became unambiguous only with the ENISA Implementation Guide from Q1 2026: phishing-resistant is any method that, through origin binding, ensures authentication can only proceed against the real domain the user originally registered with.

Method	Phishing-Resistant	Reason
FIDO2 hardware key	Yes	Domain in the signature challenge
Device-bound passkey	Yes	Origin-bound in secure enclave
Smartcard plus PIN	Yes	Domain binding through certificate chain
Push with number matching	Conditional	Defends against MFA fatigue, not against AiTM
TOTP via authenticator app	No	Code is not origin-bound
SMS code	No	Code is not origin-bound
Email code	No	Code is not origin-bound

The pattern in the right column is the actual point. Phishing-resistant is whatever does not pass through the reverse proxy. Everything else can be relayed live.

A FIDO2 authenticator relies on two things: a private key that never leaves the device, and the domain information from the browser context. When a user is registered at login.microsoftonline.com, the authenticator stores the public key together with that exact domain. On the next sign-in, the browser sends a challenge request. The authenticator only signs if the domain in the request matches the registered one. If a reverse proxy displays the same content under a different domain, the authenticator sees a different domain in the browser context and refuses to sign. The attack does not fail at the user, the antivirus, or the mail filter. It fails at the authenticator itself. This property is not an additional hardening but the defining architectural property of WebAuthn and FIDO2.

The NIS-2 Frame and ENISA Q1 2026

With the German NIS-2 transposition of 06 December 2025, the obligation for documented risk management is formally established. §30 BSIG lists ten minimum measures, one of which is authentication. What "appropriate" meant here was open until early 2026.

The ENISA Technical Implementation Guide from Q1 2026 sharpened that. For privileged access, remote access, and external vendor accounts, phishing-resistant MFA is the expected standard. SMS OTP and push approvals are explicitly named as insufficient.

§38 BSIG defines the consequences. Management must approve risk management measures, monitor their implementation, and keep themselves trained. Waivers via articles of association or shareholder agreements are statutorily excluded; violations attach to executives' personal assets. Fines reach 10 million euros or 2 percent of global annual turnover for particularly important entities. In sum, phishing-resistant MFA for admin accounts is no longer a technical recommendation in 2026. It is a compliance obligation with personal management liability.

There is also a structural requirement: organizations must keep an Identity Risk Inventory in which each account class is classified, documented with its MFA method, and reviewed regularly. Auditors expect this document. Without it there is no clean compliance evidence, no matter how secure the technical implementation actually is.

Implementation in Microsoft Entra

Microsoft Entra ID has all the necessary building blocks since mid-2025. Three configurations have to interlock. The Authentication Methods Policy defines, at tenant level, which methods are allowed at all. SMS and push are explicitly disabled for privileged roles. Microsoft defines a built-in Authentication Strength called Phishing-resistant MFA, which covers FIDO2, Windows Hello for Business, and certificate-based authentication. A Conditional Access policy requires this strength for all members of privileged roles, a second policy enforces it for sign-in to the Microsoft admin portals regardless of role assignment.

For organizations considering Entra passkeys on Windows: the feature reached general availability in April 2026, embedded in Windows Hello for Business. That eases the hardware token question for office-only users without lowering the security bar. In hybrid environments or for external vendor access, the hardware token remains the cleaner choice, especially where the endpoint is outside your own management.

Common Bypass Paths from Pentest Experience

A correctly configured Authentication Strength policy is necessary but not sufficient. In audits we keep seeing the same bypass paths. A classic case is self-service password reset without phishing-resistant authentication. The attacker phishes the weaker reset path, mints fresh credentials, and circumvents the actual sign-in policy entirely. Conditional Access has to cover SSPR flows, not just normal logins.

Almost as common is legacy authentication that has not been turned off. SMTP, IMAP, POP3, and Exchange ActiveSync with Basic Auth bypass Conditional Access completely. Microsoft has disabled Basic Auth at tenant level, but licensing exceptions and hybrid configurations leave it open repeatedly. Cross-tenant trusts with old MFA are a related issue: federated trusts often allow weaker sign-in in the home tenant that is then accepted as sufficient in the target tenant. Your own tenant policy is irrelevant if the trust boundary does not enforce it.

Weak fallback methods are the next trap. Configuring Authentication Strength as "preferred" rather than enforced opens the back door. In real-world testing, the "preferred" configuration does not hold. And finally the help desk: the attacker calls and asks for a FIDO registration reset. If the help desk process has no out-of-band verification, the attack is trivial. Several large incidents in 2024 and 2025 ran exactly that way, the most prominent in the U.S. casino industry. These are exactly the paths we exploit in our social engineering assessments.

A Six-Week Migration Path

Switching from classic MFA to phishing-resistant factors is feasible. A realistic plan for a mid-sized organization runs over six weeks.

1. Inventory. Identify all privileged roles, list external accounts, categorize service accounts, document break-glass accounts. Set up the Identity Risk Inventory.
2. Pilot. Three to five IT admins receive FIDO2 tokens, register them, and work with them for two weeks. Document issues, write help desk scripts for reset and loss.
3. Conditional Access for admin roles. Activate the strength policy exclusively for members of privileged roles. Break-glass accounts are prepared with FIDO2 but excluded from the policy to avoid lockout.
4. Roll-out to standard users. Activate passkeys via authenticator app or Windows Hello. Help desk training. User documentation, FAQ, short video walkthrough.
5. Block legacy auth. Disable old auth endpoints, harden SSPR flows, audit cross-tenant trusts, remove weak fallback methods.
6. Audit and compliance documentation. Annotate the Identity Risk Inventory with review dates, document Conditional Access policies, schedule a penetration test against the new login flows.

For larger organizations or regulated verticals, multiply the weeks; the schema stays the same.

Conclusion

Reverse proxy phishing is no longer a fringe threat in 2026 but standard. Classic MFA does not fail by accident but systematically. The defense that still holds today is origin-binding-based authentication via FIDO2 or device-bound passkeys. The regulatory dimension finally aligns with the technical one. NIS-2 §30 BSIG demands appropriate risk management, ENISA Q1 2026 concretizes that into phishing-resistant MFA for privileged access, §38 BSIG attaches personal liability to management. Whoever builds the defense starts with the Identity Risk Inventory and works through the six weeks. Whoever wants to verify where the attack still gets through in their own environment plans a penetration test against the login flows.