Before you block legacy authentication, find out who still uses it
Blocking legacy auth is a one-click policy and one of the most effective. The click is easy. Knowing what breaks when you click it is the actual work.
Legacy authentication is any sign-in that uses a protocol which can't do MFA: IMAP, POP, SMTP AUTH, Exchange ActiveSync with basic auth, older Office clients, and a long tail of "other clients". If an attacker has a password, legacy auth is how they use it without being challenged.
Microsoft turned basic auth off in Exchange Online for most protocols a while ago, so a lot of people assume this is done. It isn't quite. SMTP AUTH can still be enabled per mailbox, third-party apps still try, and Conditional Access is the thing that actually says no.
Look first
The Entra sign-in logs will tell you exactly who is still using it. Filter on Client app and tick everything under Legacy Authentication Clients. Go back thirty days. What you'll find, nearly every time:
- a multifunction printer scanning to email over SMTP AUTH using a real user's credentials,
- a line-of-business system sending notifications the same way,
- a shared mailbox someone checks from an old mail client on their phone,
- a handful of service accounts whose owners left years ago.
There is also a built-in workbook, Sign-ins using Legacy Authentication, which gives you the same view with charts, which is useful when you have to show someone why this matters.
Fix the holdouts, then block
Each holdout has a proper home:
Printers and apps that send mail. Options, in order of preference: Microsoft's High Volume Email or Azure Communication Services Email for anything that sends a lot; direct send via your MX record for internal-only notifications; an SMTP relay connector scoped to the device's IP if it must relay externally; or, as a last resort, SMTP AUTH enabled on one dedicated mailbox with a strong password and no other access. The thing to avoid is the printer using a person's account.
Old mail clients. The person updates the app, or uses Outlook. This is a conversation, not a project.
Orphaned service accounts. Disable, wait two weeks, delete.
Then the policy. Conditional Access has a template for it: Block legacy authentication, all users, all resources, client apps set to the legacy categories, grant block. Put the break-glass accounts in the exclusion and nothing else. Run it in report-only for a week first and check the log for anything you missed, then turn it on.
The part people forget
The policy stops the sign-in. It doesn't change the mailbox setting that allows SMTP AUTH, which means if someone later creates an exclusion, the door is open again. Disable SMTP AUTH at the organisation level in Exchange Online (Set-TransportConfig -SmtpClientAuthenticationDisabled $true) and enable it only on the one mailbox that genuinely needs it. Two layers; either one covers for the other.
It is a small piece of work, usually a day or two spread across a fortnight. I'd put it ahead of almost anything else on a tenant hardening list, because it closes the one path where a stolen password is enough on its own.
Written from the field, not a lab. If something here has changed since, it probably has; the newer posts are the place to look.