How Microsoft 365 Tenants Actually Get Breached in 2026 — and the Five Controls That Stop It

Ask ten IT managers how a Microsoft 365 tenant breach happens and most will describe a user clicking a bad link and typing their password into a fake page. That version is a decade out of date — and defending against it gives you a false sense of security, because the attacks that actually land in 2026 are built to work even when the user has MFA.

Here's what the current attack chains look like across the tenants we assess, and the specific controls that break each link.

The attack that beats MFA: AiTM token theft

Adversary-in-the-middle (AiTM) phishing doesn't fake your login page — it proxies the real one. The victim signs in to what is functionally the genuine Microsoft page, completes their genuine MFA prompt, and the attacker's proxy quietly captures the resulting session token. From that point the attacker doesn't need the password or the MFA method; they replay the token and they're in.

This is why "we rolled out MFA" is no longer the finish line. Push-based and SMS MFA authenticate the user — they do nothing to stop the token from being stolen after authentication succeeds.

What breaks it:

• Phishing-resistant MFA — FIDO2 security keys or passkeys bind the authentication to the origin, so a proxy site can't complete the handshake. Start with Global Admins and finance.
• Token protection and sign-in-risk Conditional Access — bind tokens to the device and challenge risky sessions.
• Number matching (now the Microsoft default) — kills the related MFA-fatigue "push bombing" pattern where attackers spam prompts until someone approves.

The attack that needs no phishing at all: password spray

Microsoft's own Midnight Blizzard disclosure is the canonical example: a nation-state actor got in not through a zero-day, but through a password spray against a legacy, non-production test account that lacked MFA — then pivoted to privileged access from there.

Every tenant we assess has at least one of these: a forgotten service account, an old shared mailbox with a real license, a test account from a migration three years ago. Attackers don't need your CEO's account. They need any account, and forgotten ones are unwatched.

What breaks it:

• Inventory accounts with no MFA registered — in Entra, that report takes five minutes and is routinely alarming.
• Entra Password Protection with banned-password lists, and stop forcing periodic rotation (current guidance: rotation breeds weak patterns; length + banned lists + MFA beats it).
• Fewer standing admins. Every Global Administrator without phishing-resistant MFA is a standing invitation.

The door that can't enforce MFA: legacy authentication

Legacy protocols — IMAP, POP, SMTP AUTH, older ActiveSync — predate modern auth and cannot enforce MFA. If they're enabled, your password-spray exposure isn't "users without MFA," it's everyone, because the attacker just speaks a protocol that never asks for the second factor.

Blocking legacy auth tenant-wide is a single Conditional Access policy. The reason most orgs haven't: fear of breaking an old scanner or a line-of-business app that's quietly using SMTP AUTH. Run the sign-in logs report first, fix the two or three real dependencies, then block it.

What "good" looks like: the five-control baseline

If you do nothing else this quarter, these five controls dismantle the attack chains above in order of impact:

1. Phishing-resistant MFA for privileged roles — FIDO2/passkeys for every Global Admin, then expand outward.
2. Block legacy authentication tenant-wide via Conditional Access.
3. Number matching + limited admin count — default-on now, but verify; and audit who actually holds privileged roles.
4. Entra Password Protection — banned-password lists on, forced periodic rotation off.
5. A real Conditional Access baseline — not security defaults alone: MFA enforcement, device compliance where you manage devices, sign-in-risk policies, and token protection for admins.

None of these require new licensing at most tiers, and all five are visible in your Secure Score — which makes them easy to track and easy to show leadership. We implement the same baseline in Microsoft 365 Security Hardening.

The uncomfortable question

The pattern across every breach writeup this year is the same: the victim organization believed its MFA rollout had closed the identity gap, and the attacker went around MFA rather than through it. The question worth asking isn't "do we have MFA?" — it's "would our Conditional Access baseline have stopped a replayed token from a compliant-looking device at 2am?"

If you don't know the answer, your sign-in logs do.