Block legacy authentication in Entra ID (and why MFA depends on it)

You rolled out MFA and felt safer. But if legacy authentication is still allowed, there's a wide-open door right next to the one you just bolted — and attackers know exactly where it is.

New to cloud? CAMPUX is a free, build-first course. Start here →

Legacy authentication is any sign-in over a protocol that can't do modern auth — Basic authentication on IMAP, POP, SMTP AUTH, MAPI and older Office clients. Because those protocols can't prompt for a second factor, they bypass MFA entirely. Block them with a Conditional Access policy targeting all users and the legacy client apps, set to Block access — but audit your sign-in logs and migrate what's still using it first, or you'll break mail for a printer. Blocking legacy auth isn't a separate project from MFA; it's the half of MFA that finishes the job.

Password-spray attacks don't bother with your shiny modern login — they aim straight at the legacy endpoints, because a valid password there sails through with no second factor asked. That's the whole game: MFA everywhere, minus one protocol, equals no MFA for an attacker who knows to use that protocol. Closing it is the highest-value hour in an identity hardening project.

What counts as legacy authentication

It's not one thing — it's a family of older protocols that authenticate with a raw username and password and have no concept of a second factor:

• Older Office clients (pre-modern-auth Office) and Basic authentication generally.
• Mail protocols: IMAP, POP3, SMTP AUTH — used by old clients, scanners, and scripts.
• MAPI, EWS, and Exchange ActiveSync when configured for basic auth.
• Legacy PowerShell and other tools still using basic auth.

Microsoft has been retiring basic authentication in Exchange Online, which helps on the mail side — but a Conditional Access block is broader and belongs to you, so it covers workloads and clients that deprecation timelines don't.

Find it before you block it

The one way to break things is to block first and look later. Look first. In Microsoft Entra ID → Sign-in logs, add the Client app column and filter to the legacy clients (Other clients, IMAP, POP, SMTP, MAPI, Exchange ActiveSync). That surfaces exactly which users and apps still authenticate the old way. Common culprits:

• Multifunction printers and scanners sending scan-to-email over SMTP AUTH.
• Service or application accounts hard-coded to basic auth.
• A handful of users on an ancient mail client.

Make that list your migration backlog. Everything on it needs a modern-auth path before enforcement day.

The Conditional Access policy

Blocking is a single Conditional Access policy. Build it, but start in report-only:

1. Users: all users — and exclude your break-glass accounts (never let a CA policy be able to lock out every admin).
2. Target resources: all cloud apps.
3. Conditions → Client apps: select Exchange ActiveSync clients and Other clients — these are the legacy buckets.
4. Grant: Block access.
5. Enable policy: Report-only first.

Let report-only run for a bit and watch the sign-in logs' report-only results: it tells you exactly who would have been blocked, without blocking them. When that list matches your migrated backlog, flip the policy to On.

Migrating what breaks

For each thing on your backlog, the fix is to move it to modern authentication:

• Printers/scanners: reconfigure scan-to-email to use OAuth/modern SMTP, or route through a modern relay; some devices need a firmware update to support it.
• Service/app accounts: move the app to an app registration or managed identity and OAuth instead of a mailbox password.
• User mail clients: update to a current client that supports modern auth.

The point of finding them first is that none of this has to be a fire drill — you migrate on your schedule, confirm the legacy sign-ins disappear from the logs, and only then enforce.

MFA with legacy auth still open isn't defence in depth. It's a locked front door beside an open window.

Questions people also ask

What is legacy authentication in Microsoft Entra ID?

Any sign-in using a protocol that can't do modern auth — mainly Basic authentication over IMAP, POP, SMTP AUTH, MAPI, EWS and older Office clients. They send a username and password directly and can't prompt for a second factor, so they bypass MFA.

Why does legacy authentication bypass MFA?

The protocols predate modern auth and have no way to challenge for a second factor, so a valid password alone completes the sign-in. While legacy auth is allowed, an attacker with a password can use it to skip MFA — which is why blocking it is required for MFA to protect you.

How do I find legacy authentication before I block it?

Filter the Entra sign-in logs' Client app column to the legacy clients (Other clients, IMAP, POP, SMTP, MAPI, Exchange ActiveSync) to see which users and apps still use it, and run the blocking policy in report-only first to preview the impact.

How do I block legacy authentication?

Create a Conditional Access policy targeting all users and the legacy client apps with grant set to Block access. Run it report-only first, exclude break-glass accounts, then enable it. The identity-layer block covers all workloads, unlike turning basic auth off per service.

What breaks when you block it?

Usually old mail clients, printers/scanners using SMTP AUTH, and service accounts on basic auth. Find them in the sign-in logs and migrate each to modern auth or OAuth before enforcing — blocking without migrating first is what causes the outage.