How to Block Legacy Authentication in Microsoft 365

How legacy auth bypasses your MFA

You deployed MFA. You set up Conditional Access. You assumed credential-stuffing attacks couldn't touch you. They can.

When an attacker buys a list of breached passwords and runs them against your tenant over IMAP or SMTP AUTH, the request never hits your MFA prompt. It often slips past your Conditional Access rules too, depending on how those policies were scoped. The login succeeds, mail flows out, and your security stack didn't even file an alert.

That's not a Microsoft bug. It's how the protocols were designed in the 1990s, before MFA existed. Username and password over a single TCP connection. No token exchange, no second-factor handshake.

Blocking legacy authentication is the single highest-ROI control in M365 security. It eliminates an entire class of attack (credential stuffing against your mail tenant) for a few hours of work and zero ongoing cost. Detailed reasoning, plus where this fits in the broader baseline, is in the ongoing M365 security operations playbook.

Why modern authentication can do MFA and basic auth can't

The shorthand version: basic auth sends username + password in the request itself, every request. Modern auth (OAuth 2.0) sends a token instead, and the token was issued earlier through a flow that can include MFA, device compliance checks, sign-in risk evaluation, and Conditional Access enforcement.

When Outlook for Microsoft 365 connects to your mailbox, the flow looks roughly like this: Outlook opens a browser-style auth window → Microsoft Entra ID prompts the user for credentials → Entra evaluates Conditional Access (is the device compliant? is the IP trusted? is the sign-in risk score elevated?) → if MFA is required, Entra prompts for it → on success, Entra issues an access token and a refresh token → Outlook stores those tokens and uses them on every subsequent request.

Every check happens at token-issue time. The mailbox API just sees a token and trusts it.

Legacy auth has none of that. The IMAP server gets a username and a password and either accepts or rejects. There's no place in the protocol to insert "wait, also approve this on your phone." That's why MFA can't apply: not because Microsoft chose not to enforce it, but because there's no mechanism to enforce it through. The only way to protect a basic-auth protocol is to disable it entirely.

Every legacy protocol still authenticating against Exchange Online

People hear "block legacy auth" and think POP, IMAP, and SMTP. There are eleven separate protocols that can still authenticate using basic auth in some configurations:

• POP3 — mail retrieval, older clients and consumer mail apps
• IMAP4 — mail sync, older clients
• Authenticated SMTP (SMTP AUTH) — scanners, line-of-business apps, alerting tools
• Exchange Web Services (EWS) — older Outlook, migration tools, calendar integrations
• Exchange ActiveSync (EAS) — older mobile mail clients
• MAPI over HTTP (basic auth) — older Outlook profiles
• Outlook Anywhere (RPC over HTTP) — Outlook 2010 and earlier
• AutoDiscover — sometimes hits basic auth during initial mailbox discovery
• Offline Address Book (OAB)
• Reporting Web Services
• Remote PowerShell

Microsoft retired most of these in the October 2022 round of basic auth deprecation. SMTP AUTH was excluded from that retirement and still works on tenants that haven't manually disabled it. If your tenant was provisioned before 2020, the default is "SMTP AUTH allowed" until you change it.

Step 1: Find what's actually using legacy auth in your tenant

Don't block first and ask questions later. Half the help-desk tickets you'll see in the first 48 hours come from the one device nobody remembered: the warehouse barcode scanner sending shipping confirmations via SMTP, the legacy phone system relaying voicemail-to-email.

Open Microsoft Entra admin center → Sign-in logs. Filter on Client app and select every "Legacy Authentication Clients" option:

• Authenticated SMTP, AutoDiscover, Exchange ActiveSync, Exchange Online PowerShell, Exchange Web Services, IMAP, MAPI Over HTTP, Offline Address Book, Outlook Anywhere (RPC over HTTP), POP, Reporting Web Services

Set the date range to the last 30 days and export to CSV. What you're looking for: usernames, IP addresses, and which protocol each is using. That's your remediation list.

For PowerShell-driven discovery, query the same data via Microsoft Graph:

Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"

$legacyClients = @(
  "Authenticated SMTP","Exchange ActiveSync","Exchange Online PowerShell",
  "Exchange Web Services","IMAP4","MAPI Over HTTP","Offline Address Book",
  "Other clients","Outlook Anywhere (RPC over HTTP)","POP3","Reporting Web Services"
)

$since = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgAuditLogSignIn -Filter "createdDateTime ge $since" -All |
  Where-Object { $legacyClients -contains $_.ClientAppUsed } |
  Select-Object UserPrincipalName, ClientAppUsed, IpAddress, CreatedDateTime, Status |
  Sort-Object UserPrincipalName |
  Export-Csv legacy-auth-usage.csv -NoTypeInformation

If that CSV is empty after 30 days, you have nothing using legacy auth. Block away, no remediation needed. If it has entries, fix those before you flip anything.

Step 2: The Conditional Access policy that blocks it

One Conditional Access policy turns off legacy auth for the whole tenant. In Microsoft Entra → Protection → Conditional Access → New policy:

• Name: CA-Block-Legacy-Auth-001
• Users: All users. Add an exclusion group called CA-Break-Glass-Excluded containing two emergency-access accounts that don't otherwise log in. You always exclude break-glass accounts from access-blocking policies. Always.
• Target resources: All cloud apps.
• Conditions → Client apps: Yes. Check Exchange ActiveSync clients and Other clients. Uncheck Browser, Mobile apps, and desktop clients.
• Grant: Block access.
• Enable policy: Report-only.

Save it. Don't flip to "On" yet. Report-only mode shows you exactly which sign-ins would have been blocked, without actually blocking them. Wait seven days, then check the Workbook at Entra → Monitoring → Workbooks → Conditional Access Insights and Reporting.

After seven days, with a clean report or all triggers remediated, flip the policy to On.

Step 3: Backstop with an Exchange Online authentication policy

The Conditional Access rule covers most of it. Belt-and-suspenders move: pair it with an Exchange Online authentication policy that disables basic auth on every supported protocol at the mailbox layer. If the CA policy is misconfigured or accidentally disabled, this one catches it.

Connect to Exchange Online PowerShell, then:

Connect-ExchangeOnline

New-AuthenticationPolicy -Name "Block-Basic-Auth" `
  -AllowBasicAuthActiveSync $false `
  -AllowBasicAuthAutodiscover $false `
  -AllowBasicAuthImap $false `
  -AllowBasicAuthMapi $false `
  -AllowBasicAuthOfflineAddressBook $false `
  -AllowBasicAuthOutlookService $false `
  -AllowBasicAuthPop $false `
  -AllowBasicAuthPowershell $false `
  -AllowBasicAuthReportingWebServices $false `
  -AllowBasicAuthRpc $false `
  -AllowBasicAuthSmtp $false `
  -AllowBasicAuthWebServices $false

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block-Basic-Auth"

That sets the policy as the tenant default. New mailboxes inherit it on creation; existing mailboxes pick it up within 24 hours. If one specific mailbox genuinely needs SMTP AUTH (a scanner, an alerting system), exclude just that one with Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false and treat that account as quarantined. Use a separate strong password, no other privileges, and a Conditional Access policy that locks it to the source IP.

What breaks when you flip the switch

Realistic breakage list, ranked by what we see most often:

• Outlook 2013 and earlier stop syncing mail. Fix: upgrade to a current Outlook build with modern auth enabled.
• Old Android stock mail apps (pre-2018) lose connection. Fix: install Outlook for Android or a current Gmail app.
• iOS Mail on iOS 11 and older fails to authenticate. Fix: upgrade iOS, or push Outlook for iOS via MDM.
• Multifunction printers and scanners sending scan-to-email via SMTP AUTH stop working. Fix: switch to SMTP relay with IP allow-listing on a connector, or move to Microsoft Graph for sending. SMTP AUTH-with-app-password is no longer supported.
• Line-of-business apps with hardcoded SMTP creds (alerting tools, monitoring scripts, custom apps). Fix: audit the inventory in Step 1 and migrate each to Graph or a connector-based relay.
• Third-party migration tools connecting via EWS basic auth. Fix: vendor probably has an OAuth update available — check before you cut over.

Plan on one to three help-desk tickets per fifty seats. Most are 5-minute fixes once you know what's calling.

The rollout sequence

The order matters. Don't reverse it.

1. Week 0: Run the discovery query in Step 1. Inventory every account, IP, and protocol pulling legacy auth.
2. Week 0: Create the Conditional Access policy in Report-only. Don't enforce.
3. Week 1: Review the Conditional Access Insights workbook daily. For every account in the report, fix the underlying client (upgrade Outlook, replace the scanner config, update the app).
4. End of week 1: Re-run discovery. The list should be down to known exceptions only.
5. Week 2 start: Flip the CA policy to On. Watch sign-in failures for 24 to 48 hours.
6. Week 2 mid: Apply the Exchange Online authentication policy at the tenant level.
7. Week 2 end: Validate with the Step 1 query again. Failed sign-ins should now show "blocked by Conditional Access" in the status. Successful legacy-auth logins should be zero.

Total elapsed time: about 10 working days, of which maybe 6 to 8 hours is actual configuration. The rest is the wait-and-watch built into the process. If you'd rather skip the rollout entirely, see how managed M365 security compares to running this in-house.

Monitor for drift after the block

The most common failure mode isn't the block failing on day one. It's the block getting silently undone six months later. A new admin gets onboarded, a third-party support ticket asks for a "temporary" exception, the policy gets disabled "just to test something." Six weeks later you're back to square one and nobody noticed.

Two checks worth running monthly:

1. Verify the Conditional Access policy is still On.

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy |
  Where-Object { $_.DisplayName -like "*Legacy*Auth*" } |
  Select-Object DisplayName, State, ModifiedDateTime |
  Format-Table -AutoSize

State should be enabled. Anything else is a finding.

2. Verify the Exchange Online authentication policy is still the tenant default.

Connect-ExchangeOnline

Get-OrganizationConfig | Select-Object DefaultAuthenticationPolicy

Get-AuthenticationPolicy "Block-Basic-Auth" |
  Select-Object Name, AllowBasicAuth* |
  Format-List

Every AllowBasicAuth* field should be False. If any flipped to True, find out who and when via the unified audit log:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) `
  -Operations "Set-AuthenticationPolicy","Set-OrganizationConfig","Set-CASMailbox" |
  Select-Object CreationDate, UserIds, Operations, AuditData

Schedule both checks as part of monthly tenant maintenance. Better yet, wire them into a monitoring dashboard so deviations alert immediately. The full M365 monitoring approach is in the M365 security FAQ.

What this doesn't protect you from

Blocking legacy auth closes one specific door: credential stuffing against legacy protocols. Four other doors are still wide open:

• Token theft via adversary-in-the-middle phishing. Tools like Evilginx and EvilNoVNC sit between the user and Microsoft, harvest the session cookie post-MFA, and replay it. Modern auth, MFA-completed — the attacker still gets in. Defense: deploy phishing-resistant MFA (FIDO2 keys, Windows Hello, certificate-based auth).
• OAuth consent phishing. An attacker sends a "Microsoft" link asking the user to grant a third-party app permission to read their mail. User clicks accept. Defense: lock down user consent in Entra ID admin settings and require admin approval for new app registrations.
• Compromised modern-auth tokens. Stolen refresh tokens, malware-grabbed session cookies, malicious browser extensions. The follow-on damage usually shows up as email forwarding rules added to compromised mailboxes. Defense: short token lifetimes, sign-in risk policies, EDR on endpoints.
• Privileged account compromise from inside. Defense: separate admin accounts, Privileged Identity Management, just-in-time elevation.

Legacy auth blocking is necessary, not sufficient. It's the lowest-hanging fruit and the one most often left undone, but it's the start of a full-tenant security baseline, not the end of one. The full baseline a 30-person business should run is in secure Microsoft 365 for small business.

Common questions

Will this break Outlook for users on current builds?

No. Outlook 2016 and newer use modern authentication by default. Outlook for Microsoft 365 (the subscription version) has used modern auth since 2016. The only Outlook clients affected are 2013 and earlier, and 2016 / 2019 builds where modern auth was manually disabled via the legacy EnableADAL registry key.

Conditional Access blocks legacy auth — do I still need the Exchange Online policy?

Yes. They protect against different failure modes. Conditional Access can be accidentally disabled, scoped wrong, or excluded for specific users. The Exchange Online authentication policy disables basic auth at the mailbox protocol layer and runs independent of Conditional Access. If one is wrong, the other catches it. Two failures have to coincide to expose the tenant.

My multifunction printer needs SMTP AUTH for scan-to-email. What now?

Don't carve a tenant-wide exception for it. Three better options, in order of preference: (1) Configure the printer to send via SMTP relay over a connector authenticated by IP rather than basic auth credentials; most modern MFPs support this. (2) Use Microsoft Graph for sending if the printer firmware supports it. (3) If neither works, create a dedicated mailbox [email protected], allow SMTP AUTH on that one mailbox via Set-CASMailbox, give it a 64-character password stored in a vault, and write a Conditional Access policy that locks that account to the printer's static IP only.

How do I tell if Conditional Access actually blocked something versus just logged it?

In Entra sign-in logs, look at the Conditional Access column for each sign-in. Values of "Failure" with the policy name listed mean it was blocked. "Report-only: Failure" means it would have been blocked but wasn't (the policy was still in Report-only mode). "Not Applied" means the policy didn't match the sign-in conditions. If you're seeing this on legacy-auth sign-ins, your policy scoping is wrong.

Microsoft already retired basic auth in 2022 — why does this still matter?

Two reasons. First, Microsoft's October 2022 deprecation excluded SMTP AUTH and Authenticated SMTP submission, both still on by default for tenants provisioned before 2020. Second, "deprecation" doesn't equal "permanently blocked." Tenant admins can re-enable disabled protocols via diagnostics setting overrides; we still find tenants where basic auth was re-enabled to fix one problem and never re-disabled afterward. The Conditional Access + Exchange Online auth policy combination above is the only durable fix.