It’s the most common objection a security vendor hears: “We’ve already got multi-factor authentication. We’re covered.” A few years ago that was a defensible position. Today it rests on an assumption that attackers have spent the last three years systematically dismantling. MFA is still essential — but “we have MFA” and “we’re protected against phishing” are no longer the same sentence.
First, the part that’s true: MFA works
Let’s be fair to MFA, because the case against complacency is stronger when you concede what’s real. Microsoft’s own research shows MFA blocks more than 99.2% of account-compromise attacks [1] and stops over 99% of password-based attacks. [2] Against credential stuffing, password reuse, and the bulk “spray and pray” attacks that make up most of the noise, MFA is the single highest-value control you can turn on. If you haven’t, do that before anything else.
So why isn’t that the end of the story? Because that 99.2% describes the attacks MFA was designed to stop. The attackers simply changed the attack.
Attackers stopped beating MFA — they started going around it
The dominant technique against MFA-protected accounts today is adversary-in-the-middle (AiTM) phishing. Instead of building a fake page that captures your password to replay later, the attacker puts an invisible proxy between you and the real website. [3] Here’s the unsettling part: you see the genuine Microsoft or Google login page. You type your real password. Your phone buzzes and you approve the real MFA prompt. Everything works exactly as expected — because it is the real login, relayed through the attacker’s server.
The moment the legitimate service issues a session cookie — the token that says “this person is already logged in” — the attacker captures it. [5] With that token, they walk straight into the account without needing your password or your MFA ever again. A stolen session token is a valid token: it sails past MFA, single sign-on, and Conditional Access policies, because as far as those systems are concerned, authentication already succeeded. [4]
This is now the default, not the exception
This isn’t a fringe technique. Microsoft reported more than 10,000 AiTM attacks per month against its users in 2024. [3] Token theft accounted for roughly 31% of Microsoft 365 breaches in 2025, overtaking traditional credential compromise as the leading vector. [4] Microsoft’s 2025 Digital Defense Report found identity-based attacks up 32% in the first half of the year, with attackers pivoting specifically to session-token theft, OAuth consent abuse, AiTM and device-code abuse. [6]
And the capability has been commoditized. Phishing-as-a-service kits build AiTM in by default: one platform, Tycoon 2FA, accounted for about 62% of the phishing volume Microsoft blocked by mid-2025, and renting it starts around $120. [3] In May 2026 the FBI issued a public warning about a kit called Kali365 that steals Microsoft 365 tokens and bypasses MFA without ever touching the password. [6] The attacker no longer needs skill — only a subscription.
It’s not only AiTM
The same logic — operate after or around the prompt — drives a whole family of MFA-bypass methods: push-bombing (spamming approval prompts until a tired user taps “yes”), OAuth consent phishing (tricking a user into granting a malicious app standing access), and device-code abuse. None of them require breaking MFA. They require a user reaching a page or prompt they trust. As one identity-security expert put it, most MFA methods in use today — somewhere around 90–95% — are susceptible to this kind of interception. [7]
“But we’re moving to passkeys”
This is the sharpest counter-argument, and it deserves a straight answer: yes, passkeys help — a lot. Passkeys, certificate-based authentication and Windows Hello are phishing-resistant because they cryptographically bind the login to the real website’s origin, so an AiTM proxy simply can’t complete the handshake. [2] If you can roll them out everywhere, do it.
The catch is “everywhere.” In practice three gaps remain. First, adoption is partial — most organizations still have SMS, app-code or push MFA enrolled alongside passkeys, and attackers simply downgrade to the weakest factor a user has. Second, passkeys protect the login, not everything else a phishing page does — the malicious attachment, the fake invoice, the data-entry form, the OAuth consent screen. Third, the long tail of SaaS apps, legacy systems and third parties your business touches will not all support phishing-resistant MFA for years. Passkeys raise the wall; they don’t cover the whole perimeter today.
MFA + real-time detection, not MFA alone
Keep your MFA. Add a layer that catches the AiTM page as it loads — before a password or a session token is ever handed over.
Protect your business →MFA is necessary. It is not sufficient.
Here’s the cleanest way to think about it. MFA is a very good lock on the door. AiTM phishing doesn’t pick the lock — it convinces the user to walk up to a perfect replica of the door and hand the attacker the key as it turns. The only way to stop that is to stop the user trusting the fake door in the first place: to detect the phishing page in real time, at the point of click, before any credential or token is exchanged.
That’s not a replacement for MFA — it’s the layer that protects the exact gap MFA leaves open. Defense-in-depth is the whole point: turn on MFA, move toward passkeys, and catch the page that the session-stealing kit is counting on your users to trust. “We have MFA” was a finish line in 2021. In 2026 it’s the starting line.