It's 2026, and I still come across tenants where legacy authentication hangs on, usually as Exchange ActiveSync or the vague "Other clients". Microsoft has warned about it for years and Conditional Access has been around just as long, yet these protocols survive in a handful of places. Closing that last gap is what turns a tenant that ticks the compliance boxes into one that actually holds up. Here is the final check I run to block legacy authentication for good.

Legacy authentication remains an easy target for attackers

Blocking legacy authentication is still one of the most important controls in any Microsoft 365 tenant. Attackers know Basic Auth protocols well, and I regularly see credential stuffing and brute-force attempts aimed at these older endpoints. Conditional Access stops old protocols, Exchange ActiveSync and Other clients included, before they get anywhere. I always start with the official Microsoft docs. The real work, though, is finding actual usage, tightening the protocol settings in Exchange Online and treating exceptions carefully, with documentation, and never as a permanent back door.

The sign-in logs reveal who still uses legacy protocols

I still start in the Entra admin center → Monitoring & health → Sign-in logs. If you filter by "Client app" and select "Legacy authentication clients", you see which users and devices still connect with outdated protocols. Pull at least 7–14 days of data so you catch recurring patterns and not just one-off sign-ins. The usual suspects are printers sending mail via SMTP AUTH, very old phones on ActiveSync and scripts that depend on IMAP/POP. This short PowerShell snippet gives me a focused list:

# PowerShell 7 locally or in Azure Cloud Shell (Microsoft.Graph module)
# Prerequisite: Global Reader or Security Reader role
# Last 14 days of legacy auth sign-ins
Get-MgAuditLogSignIn -Filter "ClientAppUsed eq 'Exchange ActiveSync' or ClientAppUsed eq 'Other clients'" -Top 1000 |
  Where-Object {$_.CreatedDateTime -gt (Get-Date).AddDays(-14)} |
  Select-Object UserDisplayName, ClientAppUsed, AppDisplayName, IPAddress, CreatedDateTime

Almost every time, the results turn up service accounts, external users and old devices that no current lifecycle process manages. If nobody goes looking for them, these leftovers can stay hidden for months or even years.

Conditional Access does the actual blocking of Exchange ActiveSync and Other clients

The block itself belongs in a Conditional Access policy that targets all users (minus the emergency accounts) and all cloud apps, with the client apps condition set to "Legacy authentication clients". Check that Exchange ActiveSync and "Other clients" are explicitly covered, because those two tend to linger longest. The policy usually looks like this:

  1. Users or groups: All (except break-glass accounts)
  2. Cloud apps: All
  3. Conditions → Client apps: Only "Legacy authentication clients"
  4. Grant: Block access
  5. Exceptions: Explicit, documented, strictly time-limited

Microsoft describes the setup in its guide to the block legacy authentication policy. For more hands-on advice, my earlier post Conditional Access in Microsoft Entra ID: The First Policies Every Tenant Needs covers the basics and the pitfalls I've run into with customers.

Pro tip: I log every exception with an expiry date and review the list on a schedule. A "temporary" exception without an end date tends to stay forever, and it will show up again at your next audit.

For special cases like printers on SMTP AUTH, agree on a clear migration plan and tell the affected people about it. You can (and should) disable SMTP AUTH per user in Exchange Online, which shuts down another major attack path.

Exchange Online lets you lock down protocols per mailbox and by authentication policy

Conditional Access does most of the work, but Exchange has its own settings that you shouldn't ignore. Set-CASMailbox disables ActiveSync, IMAP, POP and SMTP AUTH on individual mailboxes. Authentication policies (New-AuthenticationPolicy, Set-User -AuthenticationPolicy) block whole protocols for groups of users, which makes it easier to retire old dependencies step by step. To switch off ActiveSync for a single mailbox, for example:

# PowerShell 7 with Exchange Online module
Set-CASMailbox -Identity "[email protected]" -ActiveSyncEnabled $false

I like authentication policies for handling exceptions because they don't water down the baseline. Teams get time to migrate, and the tenant isn't exposed to more risk than necessary in the meantime. I go into the details in my post SMTP AUTH basic authentication: Exchange Online ends it.

The diagram shows where Conditional Access stops legacy auth

This simple flow shows how Conditional Access rejects legacy authentication attempts before they reach your data:

flowchart TD
    User["User"] --> ClientApp["Client app (e.g. ActiveSync)"]
    ClientApp --> EntraID["Entra ID"]
    EntraID --> CA["Conditional Access Policy"]
    CA -->|"Legacy auth blocked"| Blocked["Sign-in denied"]
    CA -->|"Modern auth allowed"| Allowed["Sign-in allowed"]

Figure: Conditional Access blocks legacy authentication based on the client type.

Exceptions are the biggest risk in my experience

Technically, blocking legacy authentication isn't hard anymore. What takes effort is tracking down and documenting the last users and scripts, and above all keeping exceptions from multiplying. Every legacy protocol exception should have a firm expiry date and get reviewed regularly. Honest documentation and steady cleanup do more for your security than any quick technical fix. If you haven't gone through this check yet, do it now, before the next incident rather than after it.