How to find and block legacy authentication in Microsoft 365

Modern authentication in Microsoft 365 uses OAuth 2.0: the app sends the user to Microsoft Entra ID, which can require MFA, check the device and evaluate Conditional Access. Legacy (basic) authentication skips all of that. The app collects a username and password and sends them straight to the service, so there's no opportunity for MFA. That's why password-spraying attacks have long targeted legacy protocols.

Microsoft has been retiring basic authentication in Exchange Online for years; see deprecation of basic authentication in Exchange Online for the current status of each protocol, including SMTP AUTH. Even so, legacy sign-in attempts still show up in most tenants, and blocking them explicitly is part of every Conditional Access baseline.

What counts as legacy authentication

In the sign-in logs and in Conditional Access, legacy authentication appears as these client app types:

• Exchange ActiveSync clients using basic authentication (older phone mail apps).
• Other clients: IMAP, POP3, SMTP AUTH, Exchange Web Services, MAPI over HTTP, Autodiscover, Offline Address Book and similar protocols when used with basic authentication, plus older Office clients that don't use modern authentication.

Note that IMAP, POP and SMTP can also be used with modern authentication (OAuth). The protocol isn't the problem; the authentication method is.

Step 1: Find what still uses it

In the Microsoft Entra admin center

1. Open Monitoring & health › Sign-in logs (the location varies slightly between portal versions).

2. Set the date range as wide as your retention allows, ideally 30 days.

3. Add the Client app filter and select the legacy authentication clients (Exchange ActiveSync and the "Other clients" entries).

4. Look at both successful and failed sign-ins. Successes are live dependencies to fix. Failures from unfamiliar locations are often password-spraying attempts.

5. Export the results and group by user, client app and IP address.

Microsoft's sign-in logs documentation explains each field. If the tenant sends sign-in logs to Log Analytics, the sign-ins using legacy authentication workbook summarizes the same data.

With Microsoft Graph PowerShell

For repeatable checks, the sign-in log is also available through Microsoft Graph (it needs AuditLog.Read.All):

Connect-MgGraph -Scopes "AuditLog.Read.All"
        $since = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
        Get-MgAuditLogSignIn -Filter "createdDateTime ge $since" -All |
          Where-Object { $_.ClientAppUsed -in @('Exchange ActiveSync','IMAP4','POP3','Authenticated SMTP','Other clients','Exchange Web Services','MAPI Over HTTP','Autodiscover','Offline Address Book') } |
          Group-Object UserPrincipalName, ClientAppUsed |
          Select-Object Count, Name | Sort-Object Count -Descending

Large tenants generate a lot of sign-ins; narrow the date range or filter server-side if the query is slow. Check the client app names in your own logs, as labels can differ.

Step 2: Fix each source

Turn off what nobody needs

SMTP AUTH is a common leftover. Disable it for the organization and allow it only on the specific mailboxes that must use it:

# Organization-wide off
        Set-TransportConfig -SmtpClientAuthenticationDisabled $true
        # Allow a single mailbox that still needs it
        Set-CASMailbox -Identity scanner@contoso.com -SmtpClientAuthenticationDisabled $false

Microsoft documents the setting in enable or disable SMTP AUTH in Exchange Online. Similarly, IMAP and POP can be disabled per mailbox with Set-CASMailbox, and for new mailboxes through CAS mailbox plans.

Step 3: Block it with Conditional Access

Once the dependencies are dealt with, create a policy (Microsoft publishes it as a template):

1. Users: All users. Exclude your emergency access group and, temporarily, any named account that still has an approved exception.

2. Target resources: All resources.

3. Conditions › Client apps: select Exchange ActiveSync clients and Other clients only.

4. Grant: Block access.

5. Enable policy: Report-only first. After a week with no unexpected results in the sign-in logs, switch it to On.

See Microsoft's guidance on blocking legacy authentication with Conditional Access. If the tenant doesn't have Microsoft Entra ID P1, security defaults block legacy authentication too. Unsure which applies? See Security Defaults vs Conditional Access.

Handling exceptions properly

Sometimes a device or app can't be fixed immediately. Don't leave the whole tenant unprotected for it:

• Exclude only the specific account from the block policy, using a group named for the exception.
• Give that account a long, unique password, no admin roles and access only to what it needs.
• Where possible, restrict it to a known location with a separate Conditional Access policy.
• Set an end date and review it. Exceptions have a habit of becoming permanent.

Step 4: Verify and keep watching

• Sign-in logs show no successful legacy authentication sign-ins except approved exceptions.
• Failed legacy attempts appear with the failure reason "blocked by Conditional Access" (or security defaults).
• SMTP AUTH is off at the organization level.
• The block policy is On, not report-only, and its exclusions are documented.
• New devices and apps are checked for modern authentication support before purchase.

Common questions

Hasn't Microsoft already turned basic authentication off?

For most Exchange Online protocols, yes, and Microsoft has announced the retirement of basic authentication for SMTP AUTH client submission too. But sign-in attempts using legacy protocols still reach Microsoft Entra ID, other services and older configurations may still accept them, and a Conditional Access block gives you a clear, auditable control and log entries you can alert on. Blocking explicitly costs nothing.

Will blocking legacy authentication break Outlook?

Not supported versions. Current Outlook for Windows, Mac, iOS and Android use modern authentication. Very old versions, or installations with modern authentication disabled by a registry setting, are the ones to find in the logs first.

What about the built-in mail apps on phones?

Current iOS and Android mail apps support modern authentication for Microsoft 365 accounts, but older account profiles may still be set up with basic authentication. Removing and re-adding the account usually fixes it; moving users to Outlook for iOS and Android also lets you apply app protection policies.

How M365Assessments helps

M365Assessments checks whether legacy authentication is blocked, through a Conditional Access policy or security defaults, and flags it as a priority finding when it isn’t. Because assessments are kept in run history, you can show the before and after once the block is in place. See what we assess and comparing assessments.