Legacy authentication is the old way clients sign in to Microsoft 365 — protocols that only pass a username and password and can’t do multi-factor authentication. That’s the whole problem. You can enforce MFA across the entire tenant, and a legacy protocol will still let an attacker in with nothing but a guessed or stolen password. It’s why password-spray attacks lean on legacy auth so heavily.
Blocking it is one of the highest-value security changes you can make, but it’s also one that breaks things if you rush. An old mail client, a printer that scans to email, or a forgotten line-of-business app might still be using it. This guide does it in the right order: find what’s still using legacy auth, fix or exclude those, then block it with a Conditional Access policy you’ve validated in report-only mode first.
What counts as legacy authentication
Legacy authentication covers any client that authenticates with basic auth or an older protocol that predates modern authentication. The common ones:
Legacy vs modern authentication
| Legacy protocols | IMAP, POP, SMTP AUTH, older Exchange ActiveSync, MAPI over basic auth |
|---|---|
| Legacy clients | Office 2010 and older, some Office 2013 without modern auth enabled |
| Can it do MFA? | No — only a username and password are passed |
| Modern authentication | OAuth 2.0 based, supports MFA and Conditional Access |
| Modern clients | Current Outlook, Microsoft 365 Apps, mobile Outlook |
The defining trait is that legacy auth can’t honor MFA. Modern authentication uses OAuth and tokens, so it can. Microsoft has already retired basic authentication for most legacy protocols in Exchange Online, which removed a lot of the exposure — but a Conditional Access policy gives you tenant-wide enforcement that doesn’t rely on those Exchange changes alone.
Step 1: Find what still uses it
Never block legacy auth blind. Check the Microsoft Entra sign-in logs first to see who and what is still connecting the old way.
- Sign in to the Microsoft Entra admin center (
entra.microsoft.com). - Go to Identity → Monitoring & health → Sign-in logs.
- Add a filter on Client app and select the Legacy authentication clients group (IMAP, POP, SMTP, MAPI, Exchange ActiveSync, and the rest).
- Set the date range wide enough to catch monthly or occasional jobs.
- Review which users, apps, and protocols appear.
Step 2: Fix or plan around what you found
For each legacy user or app, you have three options, in order of preference:
- Update the client. Move it to a modern Outlook or a current app version that supports modern authentication. This is the real fix.
- Re-platform the app or device. A printer or app can often use OAuth, Graph, or a modern SMTP submission method instead of basic SMTP AUTH.
- Scope a temporary exclusion. If something genuinely can’t move yet, exclude that specific account from the block while you plan its replacement — not the whole tenant.
Step 3: Build the Conditional Access policy
The block itself is a single Conditional Access policy. The key is to start it in report-only mode so it evaluates and logs without enforcing.
- In the Entra admin center, go to Protection → Conditional Access → Policies.
- Click New policy and name it clearly, e.g. “Block legacy authentication.”
- Users: select All users, then under Exclude, add your break-glass admin accounts and any temporary legacy exclusions from Step 2.
- Target resources: select All cloud apps.
- Conditions → Client apps: set the toggle to Yes, then tick Exchange ActiveSync clients and Other clients (these two cover legacy auth) and leave the modern options unticked.
- Grant: choose Block access.
- Set Enable policy to Report-only, then Create.
Step 4: Validate in report-only, then enforce
Leave the policy in report-only for long enough to catch periodic jobs — a few days at least, ideally a full cycle that includes any monthly tasks.
- Go back to the sign-in logs and open the Report-only tab on individual sign-ins.
- Look for sign-ins where the policy result is “Would have blocked.”
- Cross-check those against Step 1: are they all things you’ve already fixed or excluded?
- When the report-only results show only the legacy traffic you intend to block, edit the policy and set Enable policy to On.
Before you flip the policy to On
- Sign-in logs reviewed; every legacy user/app is accounted for
- Clients updated to modern auth where possible
- Service accounts (printers, apps, monitoring) fixed or excluded
- Break-glass admin accounts excluded from the policy
- Report-only results show only the legacy traffic you mean to block
- A rollback plan in case something unexpected breaks
After the block: keep it clean
Blocking legacy auth pairs naturally with the rest of your identity hardening. With legacy protocols closed, your MFA enforcement actually covers every sign-in instead of leaking around the edges. It’s worth reviewing your other Conditional Access policies at the same time so they work together rather than overlapping in confusing ways.
Keep an eye on the sign-in logs for a while after enforcing. A new legacy attempt usually means a device or app you missed, or a new one that someone set up the old way. Blocking legacy auth also cuts a major path attackers use to slip past your defenses, so it fits alongside the rest of your protection against phishing in Microsoft 365.
Bottom line
Legacy authentication is the gap that lets a stolen password bypass MFA, so closing it matters. Do it in order: find what still uses it in the sign-in logs, update or exclude those clients and service accounts, then block it with a Conditional Access policy you’ve validated in report-only mode. Exclude your break-glass accounts before you enforce, roll out in waves on a large tenant, and keep watching the logs afterward. It’s a one-time project that quietly removes one of the most-used attack paths into a tenant.
