By Ryan Windt, Head of Growth Marketing
For years, multi-factor authentication was the answer. If a carrier asked whether your organization had MFA deployed, and you said yes, that was usually enough. The box was checked. The conversation moved on.
That era is ending.
A class of attack called Adversary-in-the-Middle phishing, or AiTM phishing, has made the simple question “do you have MFA?” insufficient. Underwriters at an increasing number of carriers are now asking a follow-up question: what kind of MFA?
The distinction matters because AiTM attacks are specifically engineered to defeat the most widely deployed forms of MFA. If your organization relies on push notifications or one-time codes sent to an authenticator app, those controls are bypassable in real time by tools that have been commercially available on criminal forums for years.
This post explains how AiTM phishing works, why it renders standard MFA ineffective, and what underwriters are starting to require as a result.
What Is AiTM Phishing?
Traditional phishing tries to steal your password. You click a fake login page, enter your credentials, and the attacker captures them. MFA was designed to stop exactly this: even if the attacker has your password, they still cannot authenticate without the second factor.
AiTM phishing attacks this assumption directly.
In an AiTM attack, the attacker does not just capture credentials. They position a proxy server between the victim and the legitimate service. When the victim attempts to log in, they are actually connecting to the attacker’s proxy, which relays everything to the real site in real time. The victim enters their password. The attacker relays it. The real site asks for the second factor. The victim enters the one-time code or approves the push notification. The attacker relays that too.
The session token that the legitimate service issues upon successful authentication is captured by the attacker’s proxy before it ever reaches the victim’s browser.
The victim has successfully completed MFA. The attacker now has a valid, authenticated session. No password cracking, no brute force. The attack completes in the time it takes the user to log in.
This is not a theoretical vulnerability. AiTM phishing kits, most notably a framework called Evilginx, are widely documented, actively maintained, and have been used in breaches affecting organizations across every industry.
Why Push Notification and TOTP MFA Are Vulnerable
The reason AiTM defeats standard MFA is that most MFA methods rely on a shared secret or a real-time code that can be relayed.
Authenticator app codes (TOTP): Time-based one-time passwords generated by apps like Google Authenticator or Microsoft Authenticator are valid for a short window, typically 30 seconds. An AiTM proxy captures the code the user enters and relays it to the real site immediately, within that validity window. The code is legitimate; the relay is transparent.
Push notifications: Apps like Duo or Microsoft Authenticator that send an “approve this login” prompt are slightly more resistant to automated phishing, but still vulnerable to AiTM. Because the proxy is completing a live authentication session, the real site sends the push to the user’s device. The user approves it, believing they are logging in normally. The attacker’s session is authenticated.
SMS codes: Vulnerable to the same relay mechanism as TOTP codes, and additionally vulnerable to SIM-swapping, where an attacker convinces a mobile carrier to transfer a victim’s number to an attacker-controlled SIM.
The common thread: all of these methods authenticate the user’s identity, but they do not verify that the user is connecting to the legitimate site. The session token can be captured and reused from a different context, which is precisely what AiTM exploits.
What AiTM-Resistant MFA Looks Like
There is a category of MFA that is structurally resistant to AiTM attacks, not because it is harder to intercept, but because the interception produces nothing usable.
FIDO2 security keys and passkeys use public-key cryptography tied to the specific origin of the site being authenticated. When a user authenticates with a FIDO2 key or passkey, the cryptographic challenge includes the domain of the legitimate site. If the authentication request originates from an AiTM proxy at a different domain, even a convincing lookalike, the key will not produce a valid response. There is nothing for the attacker to relay.
This property is called phishing resistance, and it is why security keys and passkeys are the standard recommended by CISA, NIST, and increasingly, cyber insurance underwriters.
Certificate-based authentication operates on similar principles and is common in enterprise environments, particularly for privileged access.
The key distinction is binding: phishing-resistant MFA binds authentication to the legitimate origin at a cryptographic level. Push notifications and TOTP codes do not have this property. They authenticate the user but not the connection.
What Underwriters Are Now Asking
The cyber insurance market began pricing MFA as a required control years ago. Organizations without any MFA faced substantially higher premiums or outright declinations. That baseline requirement has not changed.
What has changed is the granularity of the question.
Underwriters at a growing number of carriers are adding follow-up questions about MFA quality, particularly for high-risk access points. Applications are asking whether organizations deploy phishing-resistant MFA, and specifically whether it is enforced for privileged accounts, remote access, and identity administration.
This scrutiny tends to concentrate on the access points where AiTM compromise has the highest business impact:
Email. Business email compromise facilitated by session token theft is one of the most common cyber insurance claim types. An AiTM attack against an employee’s Microsoft 365 or Google Workspace login gives an attacker authenticated access to email, calendar, file storage, and any connected applications.
Remote access and VPN. MFA on VPN access protected by push notifications is bypass-able. An attacker who successfully AiTMs a remote access login has a network foothold.
Identity infrastructure. Administrative access to Active Directory, Azure AD, Okta, or similar identity systems is the highest-value target in most environments. Underwriters are paying increasing attention to whether phishing-resistant MFA is enforced for identity administrators specifically.
Cloud environments. Cloud management consoles, particularly for IaaS environments with sensitive data or production workloads, are appearing more frequently in underwriting questionnaires.
The trajectory is consistent: underwriters are moving from asking whether MFA exists to asking whether MFA is effective against the attack techniques actually driving claims.
The Documentation Gap
Organizations that have already deployed phishing-resistant MFA often face a secondary problem at renewal: they cannot demonstrate it clearly.
Carriers are not asking about MFA deployment in isolation. They want to understand enforcement scope, the percentage of accounts protected, whether exceptions exist for legacy applications, how service accounts and non-human identities are handled, and what monitoring is in place for authentication anomalies.
An organization that has deployed FIDO2 keys for a subset of users but still allows push notification fallback across the rest of the environment has a partial control, not a complete one. Underwriters will distinguish between the two.
Useful documentation for demonstrating MFA quality includes:
- Identity provider reports showing authentication method breakdown by user and application
- Conditional access or authentication policy exports
- Privileged access review records showing which accounts have phishing-resistant factors enforced
- Incident response or detection configuration showing alerts on authentication anomalies
The goal is to make the picture legible to an underwriter who is assessing risk across hundreds of applications. Clear documentation of what is protected, at what assurance level, and what the exceptions are, reduces friction at renewal and strengthens the underwriting narrative.
How AiTM Exposure Connects to Policy Coverage
Understanding what AiTM attacks enable is important for mapping the coverage question accurately.
An AiTM attack that captures a session token is an access event. What happens after that access event determines which coverage lines respond.
If the attacker uses the compromised session to access email and redirect invoice payments, that is funds transfer fraud, often covered under the social engineering or crime provisions of a cyber policy. The social engineering and funds transfer fraud coverage explainer covers how carriers handle this coverage class and where the exclusions tend to appear.
If the attacker uses the access to exfiltrate customer or employee data, that triggers breach response coverage: forensic investigation, legal notification requirements, credit monitoring, and regulatory defense. The data breach insurance postcovers how this coverage works in practice.
If the attacker uses the session to deploy ransomware after moving laterally, that is a ransomware event. Coverage for ransomware, including extortion payments, system restoration, and business interruption, is addressed in detail at does cyber insurance cover ransomware payments.
The access vector, an AiTM-bypassed MFA, does not by itself determine coverage. The post-access activity does. This is an important distinction when reviewing policy language, particularly any exclusions tied to failure of security controls.
What This Means at Renewal
If your organization’s MFA program has not been reviewed in the context of AiTM risk, renewal is a reasonable forcing function to do that review.
The practical questions are:
What authentication methods are in use, and where? Mapping authentication methods by application and access point reveals where phishing-resistant coverage exists and where it does not.
Where are the highest-risk access points? Email, remote access, identity infrastructure, and cloud management consoles are the areas underwriters are focusing on. These are reasonable places to prioritize FIDO2 or passkey enforcement.
What fallback options exist? Many deployments have phishing-resistant MFA as an option but still permit push notification fallback. Those fallback paths are the attack surface.
What does the documentation look like? If a carrier asks for evidence of MFA implementation, what would you show them?
The MFA implementation guide for cyber insurance covers what a credible MFA program looks like from an underwriting perspective, including how to document it and what carriers consider baseline versus preferred.
Improving MFA quality before renewal typically has a measurable effect on terms. Carriers that are asking harder questions about MFA are also, in most cases, offering better pricing to organizations that can demonstrate they have addressed the AiTM risk specifically.
FAQ
What does AiTM stand for? AiTM stands for Adversary-in-the-Middle. It refers to a phishing technique where an attacker uses a proxy server positioned between the victim and a legitimate login page to capture not just credentials but authenticated session tokens in real time.
Does AiTM phishing work against all types of MFA? AiTM is effective against MFA methods that rely on relayable codes or approvals: TOTP authenticator apps, push notifications, and SMS codes. It does not work against FIDO2 security keys or passkeys, which use origin-binding to ensure the authentication is cryptographically tied to the legitimate site.
What is phishing-resistant MFA? Phishing-resistant MFA refers to authentication methods, primarily FIDO2 security keys and passkeys, that bind the authentication response to the legitimate domain at a cryptographic level. Even if an attacker intercepts the exchange, the response is not valid at any other origin.
Are cyber insurance carriers requiring phishing-resistant MFA? Carriers are at various points in adjusting their requirements. Some are actively requiring phishing-resistant MFA for high-privilege accounts. Others are asking about it in applications and using it as a rating factor. The direction across the market is toward greater scrutiny of MFA quality, not just MFA presence.
Does having FIDO2 on some accounts but not others satisfy underwriters? Partial deployment is better than none, but underwriters are evaluating enforcement scope. A program that requires phishing-resistant MFA for all privileged accounts and email access, with clear documentation, is stronger than one where phishing-resistant factors exist as an option among multiple permitted methods.
Will having better MFA actually affect my cyber insurance premium? In many cases, yes. Carriers that ask harder questions about MFA quality are generally using the answers to inform pricing. Organizations that can document phishing-resistant MFA enforcement across high-risk access points often see improvement in terms at renewal.
Related Resources
- MFA Implementation Guide for Cyber Insurance
- What Underwriters Look for on a Cyber Insurance Application
- Privileged Access Management and Cyber Insurance
- Social Engineering and Funds Transfer Fraud Coverage
- Cyber Insurance Requirements Checklist
- Does Cyber Insurance Cover Ransomware Payments?
Ready to find out how your current security controls are likely to be evaluated at renewal? Talk to a SeedPod broker.