Find and block legacy authentication in Microsoft 365

Legacy authentication means older mail protocols and clients that send a username and password with every request and can't do MFA: IMAP, POP3, SMTP AUTH, Exchange ActiveSync with basic auth, and older Outlook versions. Because they can't show an MFA prompt, they let an attacker skip it. That's why most password spraying against Microsoft 365 uses them.

Microsoft has turned off basic authentication for most Exchange Online protocols, and many admins take that to mean the job is done. It isn't quite. Legacy attempts still show up in your sign-in logs, exceptions and SMTP AUTH have lingered in many tenants, and the block in Entra ID is what stops these requests whatever Exchange does. Finding and blocking legacy authentication takes an afternoon, and it's one of the highest-value changes you can make to a tenant.

How do I find legacy authentication in the sign-in logs?

In the Entra admin center, open Sign-in logs, add the Client app filter and select every option under Legacy authentication clients. Look at the last 30 days, and check both successes and failures.

• Failures from IPs you don't know, spread over many users: that's password spraying. It's blocked or failing, but it tells you someone has your user list.
• Successes: these are the ones to act on. Each one is a real device or app still signing in without MFA.

If you send sign-in logs to Log Analytics or Sentinel, this summarises who and what:

SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed in ("Exchange ActiveSync", "IMAP4", "POP3", "Authenticated SMTP",
    "Exchange Web Services", "MAPI Over HTTP", "Offline Address Book", "Outlook Anywhere (RPC over HTTP)",
    "AutoDiscover", "Exchange Online PowerShell", "Other clients")
| summarize Attempts = count(), Successes = countif(ResultType == "0"), IPs = dcount(IPAddress)
    by UserPrincipalName, ClientAppUsed
| order by Successes desc, Attempts desc

No Log Analytics? Download the sign-in log as CSV from the portal and filter the Client app column in a spreadsheet, or load it into a sign-in review tool.

What usually still uses legacy authentication?

• Printers and scanners that send scan-to-email with SMTP AUTH. By far the most common.
• Line-of-business apps and scripts sending notifications through smtp.office365.com with a stored password.
• Old mail clients: Outlook 2010, older Apple Mail or a phone's built-in mail app set up years ago.
• Monitoring and backup tools using IMAP to read a mailbox.

Each of these needs a replacement before you block, or something stops working on a Monday morning. Most are quick to fix once you know they exist.

What about printers and apps using SMTP AUTH?

You have three ways to keep them sending mail without legacy authentication:

Then turn SMTP AUTH off for the whole organisation and allow it only for any mailbox that genuinely still needs it while you migrate:

Set-TransportConfig -SmtpClientAuthenticationDisabled $true
Set-CASMailbox -Identity scanner@contoso.com -SmtpClientAuthenticationDisabled $false   # temporary exception

How do I block legacy authentication?

Without Entra ID P1 (Business Basic or Standard), turn on security defaults. They block legacy authentication and require MFA registration in one switch. If your tenant already has Conditional Access policies, you have to use those instead; the two can't run together.

With Entra ID P1 (Business Premium, E3, E5), create a Conditional Access policy. The built-in template "Block legacy authentication" is the quickest route:

1. Users: All users. Exclude your break-glass accounts only.
2. Target resources: All resources (cloud apps).
3. Conditions > Client apps: tick Exchange ActiveSync clients and Other clients only.
4. Grant: Block access.
5. Enable policy: Report-only first.

Leave it in report-only for a week, then filter the sign-in logs on the policy's result. Anything that "would have been blocked" and isn't on your migration list is something you didn't know about. Once that list is empty, switch the policy to On.

How do I confirm it worked?

After the policy is on, legacy sign-in attempts don't disappear from the logs. Spraying continues; it just fails. What changes is the result: the attempts now fail with error 53003 (blocked by Conditional Access) instead of reaching password validation. Run the query above again after a week. Successes should be zero, and any remaining failures should show the policy as the reason.

The failed logon guide covers the on-premises side of password spraying, and the impossible travel guide covers what to check when a sign-in does get through.

FAQ

Didn't Microsoft already disable basic authentication?

For most Exchange Online protocols, yes. But sign-in attempts using these clients still reach Entra ID, SMTP AUTH and exceptions have lasted longer in many tenants, and other apps can still use legacy flows. A Conditional Access block or security defaults close all of it in one place, whatever Exchange does.

Will blocking legacy authentication break Outlook?

Not current Outlook versions. Outlook for Microsoft 365, Outlook 2016 and later, the new Outlook, and the Outlook mobile app all use modern authentication. Very old Outlook versions and some built-in phone mail apps can break, which is why report-only mode comes first.

Is "Other clients" the same as legacy authentication?

Mostly. In Conditional Access, Other clients covers the older protocols that aren't Exchange ActiveSync, such as IMAP, POP3, SMTP and older Office clients. Tick both options to cover everything.

Can I block legacy authentication on Business Basic or Standard?

Yes, with security defaults. Conditional Access needs Entra ID P1, which is in Business Premium.