Token Theft Walks Right Past Most MFA. Here Is the 2026 Fix.

A successful MFA prompt is not proof that a user signed in to Microsoft. That single sentence explains the fastest-growing attack pattern in Microsoft 365 tenants today: adversary-in-the-middle (AiTM) phishing paired with token theft.

The uncomfortable part is that the tenants getting hit usually had MFA enabled on every account. The question that matters in 2026 is not "do you have MFA?" It is "what kind of MFA are you enforcing, and where are the exceptions?"

This post breaks down how an AiTM attack actually works, why conventional MFA does nothing to stop it, and the deployment model we would build today, with Conditional Access strategies you can apply this week.

How a token gets stolen after a "successful" MFA sign-in#

Picture a mid-size accounting firm that lives entirely in Microsoft 365. MFA is on for every account: SMS codes, Authenticator prompts, all the boxes checked.

One morning the finance manager gets an email that looks completely legitimate, a OneDrive document share notification. He clicks the link, lands on what appears to be a Microsoft sign-in page, and logs in. Email entered. Password entered. MFA approved. He is redirected to the Microsoft 365 portal and nothing seems wrong.

But he never signed in to Microsoft. He signed in to an attacker's proxy site.

That fake login page was AiTM phishing infrastructure. While the user believed he was authenticating to Microsoft, the proxy captured his username and password and, more importantly, intercepted the session tokens Microsoft issued after the MFA challenge passed.

From there the attacker opens an incognito browser, injects the stolen session cookie, and is instantly authenticated as the user. No password. No MFA prompt. No friction. From Microsoft's perspective, the sign-in log shows a successful MFA authentication.

Not all MFA methods deserve equal trust against that playbook. Here is how we would deploy MFA going into 2026.

Close the coverage gaps before upgrading the methods#

The most common failure is not weak MFA, it is missing MFA. Two coverage problems show up constantly:

Per-user MFA instead of Conditional Access. A surprising number of tenants still run per-user MFA settings rather than a modern Conditional Access deployment. Per-user settings leave holes every time a new account is created in the organization. Conditional Access applies the policy to everyone, including accounts that do not exist yet.

MFA must apply to:

• All user accounts
• Privileged accounts
• Service accounts with interactive logins

If an account can authenticate, it can be hijacked. Wherever possible, replace service accounts with managed identities or service principals, and eliminate shared or "temporary" accounts that never expire. If a login exists, MFA belongs there. No exceptions.

Guest users. Many breaches do not start with internal users. They start with partners and suppliers. Guest accounts often hold access to Teams, SharePoint, and sensitive documents, and if a guest is compromised, your tenant becomes the blast radius. Enforce MFA for guest users, review external access regularly, and treat long-term partners differently than one-off guests. A single compromised guest account is enough to trigger an AiTM chain reaction.

Which MFA methods should be retired in 2026?#

SMS, voice calls, and email one-time codes should be treated as legacy authentication methods. They are vulnerable to:

• SIM swapping
• Social engineering
• Compromise of the second factor itself (think of a user whose second factor is their personal Gmail inbox)

At an absolute minimum, organizations should be running Microsoft Authenticator with number matching, which forces users to confirm a number shown on screen and dramatically reduces MFA fatigue attacks.

One caution: before disabling old methods, review the user registration data carefully. Ripping methods out without a migration plan causes outages and support tickets, not security.

Phishing-resistant MFA is what actually breaks AiTM#

This is where MFA finally catches up to the attack. Phishing-resistant methods include:

• Windows Hello for Business
• FIDO2 security keys
• Passkeys (including iPhone and Android support)

These methods use device-bound cryptographic keys instead of shared secrets. Even if a user lands on a pixel-perfect fake login page:

• The authentication cannot complete
• The key will not sign a request for the wrong origin
• Token replay fails

That single change breaks AiTM attacks entirely. The proxy has nothing to capture because the credential never leaves the device and never signs for the attacker's domain.

Roll it out in phases, starting where compromise hurts most:

1. Global admins
2. Executives
3. Finance and other high-impact roles

Then expand outward to the rest of the organization.

What about token protection in Conditional Access?#

Microsoft has introduced token protection controls in Conditional Access, included in Entra ID P1, designed to stop replay attacks. They are promising, but as of December 2025 they are:

• Limited in scope
• Windows-only
• Restricted to mobile and desktop clients
• Not effective against browser-based AiTM attacks

Token protection is worth piloting, but it is not a silver bullet yet. For a deeper breakdown, see Breaking Down Token Protection in Conditional Access.

The bar has moved#

If your MFA strategy has not changed in the last few years, it is already behind. Attackers stopped trying to beat MFA prompts and started stealing what comes after them. Coverage everywhere, legacy methods retired, phishing-resistant credentials for the accounts that matter: that is the 2026 deployment.