If you only fix one thing in your Microsoft 365 tenant this year, fix legacy authentication. It is the single highest-leverage change most organizations can make, because legacy protocols cannot enforce MFA — which means every other control you have can be walked around by a client that speaks an old protocol.
This post is the practical version: what legacy authentication is, how to find it, how to block it without breaking anyone, and how to prove it is gone.
What legacy authentication is
Legacy authentication refers to sign-ins that use protocols which do not support modern authentication (and therefore cannot enforce MFA or Conditional Access). The usual offenders:
- IMAP and POP for mail clients
- SMTP AUTH for authenticated mail submission
- Exchange ActiveSync on older configurations
- Other basic-authentication clients that predate modern auth
These protocols authenticate with a username and password and nothing else. Conditional Access does not apply. MFA does not apply. If credentials are leaked or sprayed, an attacker signs in.
Why it is so dangerous
Microsoft has reported that the large majority of password-spray attacks target legacy authentication protocols, precisely because they bypass MFA. Attackers do not need a sophisticated exploit — they need a list of usernames and a password that works on a protocol nothing is protecting.
From there, access looks legitimate: mailbox reading, mail sending, data access. It is a quiet way in.
How to find it
You find legacy authentication in two places:
1. Sign-in logs. Filter Entra ID sign-in logs for client apps that use legacy protocols (IMAP, POP, SMTP, Exchange ActiveSync, "Other clients"). The sign-in logs show you who is still using them and from where. This is the authoritative view of what is actually happening.
2. Configuration. Check whether any Conditional Access policy blocks legacy authentication client types. If none does, it is open — regardless of what the logs show on a given day.
The audit check is simple: is there an enabled policy that blocks legacy authentication for all users? If the answer is no, that is a critical finding.
How to block it safely
Blocking legacy auth is a one-policy change, but doing it without disruption takes a sequence:
- Find out who relies on it. The sign-in logs tell you. If a service, a scanner, or a mail client depends on IMAP or SMTP AUTH, you need a plan for it.
- Block legacy auth in Conditional Access. Create (or verify) a policy that blocks legacy client types for all users. This is the control that closes the hole.
- Disable SMTP AUTH where it is not needed. For the accounts that genuinely need it (multifunction devices, some scanners), scope it tightly.
- Re-test. Confirm the legacy sign-ins stop and that legitimate users are unaffected.
- Re-audit. Confirm the policy is still enabled next quarter — someone disabling it during an incident is a classic drift.
Prove it is gone
The evidence an auditor wants is not "we blocked it once." It is:
- A current, enabled Conditional Access policy blocking legacy authentication, and
- Sign-in logs showing no legacy-protocol authentication
Both are check-level outputs. In a hosted audit they map to the relevant control (CISA SCUBA's legacy-auth policy, CIS, and EIDSCA all include it) and appear in the report. You can see the identity coverage on our EIDSCA page.
The short version
Legacy authentication is the highest-return fix in Microsoft 365 because it bypasses MFA and is heavily targeted. Find it in the sign-in logs, block it with a Conditional Access policy, handle the genuine exceptions deliberately, and re-audit on a cadence so it stays blocked.
Run an audit to check whether legacy authentication is blocked in your tenant — and what else needs attention.