Block legacy authentication

What is legacy authentication?

Legacy authentication is the family of older sign-in protocols Microsoft 365 still supports for backwards compatibility: POP and IMAP for mail clients, SMTP AUTH for devices that send email, and basic authentication for Exchange ActiveSync. They were designed before multi-factor authentication existed, and that is the whole problem — a legacy auth sign-in cannot be challenged for a second factor. The protocol hands over a username and password and either gets in or doesn't.

Why attackers target it

If a legacy endpoint is open, your MFA is decoration for that route. Attackers know it, so password spray and credential-stuffing campaigns are aimed at legacy endpoints first: replay a stolen or guessed password against POP/IMAP/SMTP AUTH, and no phone ever buzzes. In the June 2026 campaign Huntress documented — 81 million login attempts in two weeks — most of the breached businesses had MFA turned on. The attacker never defeated a second factor; they used routes where one is never asked for.

This maps to MITRE ATT&CK T1110.003 (password spraying), and it's one of the first doors a commodity attacker rattles.

How to block legacy authentication in Microsoft 365

The fix is one Conditional Access policy (requires Entra ID P1):

1. Go to entra.microsoft.com → Protection → Conditional Access → New policy
2. Name it "Block legacy authentication"
3. Assignments → Users: All users, excluding your break-glass account
4. Assignments → Cloud apps: All cloud apps
5. Conditions → Client apps: select Exchange ActiveSync clients and Other clients
6. Access controls → Grant: Block access
7. Run it in Report-only mode for a week, review the sign-in logs for legitimate legacy auth, then switch it to On

Budget about an hour, most of it the report-only review. Microsoft's own walkthrough is in the Entra documentation.

What might break

Anything still authenticating the old way: aging IMAP/POP mail clients, printers and scanners that email scans, monitoring tools using basic auth. That's why the report-only week matters — filter your sign-in logs on Client app = "Other clients" and see what shows up. The usual remediations are moving the device or app to OAuth, replacing it, or (least good) a tightly scoped exception group while you migrate.

How Tenant Strike checks this

A scan reads your Conditional Access policies through Microsoft Graph — read-only, like everything Tenant Strike does — and looks for an enabled policy that blocks the legacy client app types tenant-wide. A policy sitting in report-only mode doesn't count as protection, and the report says so. If the check fails, the finding includes the exact policy configuration to create and links you straight to the Conditional Access blade. If it passes, the report names the policy that's doing the protecting, so you can verify the claim yourself.