IMAP, POP3, SMTP AUTH, and older MAPI/RPC clients using basic authentication cannot enforce MFA. While those endpoints remain active, they are an open back door into the directory.

Preface

Legacy authentication protocols are inherently insecure and do not support modern interactive authentication. Strict modern policies elsewhere do not help if legacy endpoints stay enabled.

"Legacy authentication" here means any sign-in where the client sends a username and password directly to the service, usually with basic authentication, instead of redirecting the user to Entra ID for an OAuth 2.0 flow. Because the password is the only factor and there is no interactive session, Entra ID cannot show an MFA prompt, evaluate device compliance, or apply most Conditional Access grant controls.

Problem

Attackers use legacy endpoints for password spray and brute force because no interactive MFA challenge is presented. Successful legacy auth can lead to mailbox access, persistence, and lateral movement, often with weak monitoring coverage.

Microsoft has disabled basic authentication for most Exchange Online protocols, and security defaults block legacy authentication outright. In practice, many tenants still have gaps: SMTP AUTH left enabled for printers and line-of-business applications, exceptions granted during the retirement and never removed, Conditional Access policies that exclude service accounts, and hybrid or on-premises services that Entra policies do not cover at all. Microsoft is also retiring basic authentication for SMTP AUTH in Exchange Online; check the current announcements for the dates that apply to your tenant.

How the Attack Works in Practice

A password spray tries a small number of common passwords against many accounts, slowly enough to avoid lockouts. Legacy endpoints are attractive because a valid password is enough: there is no second factor to defeat. A successful attempt gives the attacker mailbox access, which is often enough for invoice fraud, internal phishing and password resets on other services. Accounts excluded from MFA "because they use an old app" are the most exposed, and they are often shared or service accounts with weak oversight.

Solution

Align with CIS Microsoft 365 Foundations Benchmark and NIST SP 800-171:

  1. Block legacy clients in Conditional Access: Target all cloud apps and block "Exchange ActiveSync clients" and "Other clients".
  2. Monitor legacy sign-ins: Audit Entra sign-in logs for non-modern protocol success.
  3. Move clients to modern authentication: OAuth 2.0 for Outlook Mobile, OWA, and related clients.

Design Guidance

One policy, all users, all resources

Create a single Conditional Access policy that targets all users and all resources, with the client apps condition set to the two legacy categories, and the grant control set to block. Exclude only emergency access accounts. Every other exclusion should be a documented, time-limited exception with an owner.

Fix the service, not just the identity

Conditional Access is evaluated at Entra ID. Also disable the protocols at the service: use Exchange Online authentication policies to block basic authentication per protocol, disable SMTP AUTH at the organization level and enable it only on the mailboxes that truly need it, and turn off POP and IMAP on mailboxes that do not use them. Defense in depth matters here because exceptions at one layer are common.

Plan for devices and applications

The hardest cases are rarely users. Multifunction printers that scan to email, older line-of-business applications and monitoring tools that send alerts by SMTP are typical blockers. Options include firmware that supports OAuth, an SMTP relay connector restricted by certificate or IP address, or moving the application to Microsoft Graph with an application identity.

Implementation Steps

  1. Discover: run the sign-in query below for at least 30 days and list every user, application and client type still using legacy protocols.
  2. Remediate clients: update or replace each client, starting with interactive users, who are usually the easiest.
  3. Deploy the policy in report-only mode and review which sign-ins it would have blocked.
  4. Enable the policy, with emergency access accounts excluded and any remaining exceptions tracked.
  5. Disable protocols at the service layer with Exchange Online authentication policies and per-mailbox protocol settings.
  6. Close exceptions on a schedule, and alert when a new exception is added to the policy.

PowerShell: Review Conditional Access Coverage for Legacy Clients

The authentication methods policy controls which MFA methods users can register; it does not block legacy protocols. Coverage is set in Conditional Access, so review those policies instead: 

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
    Where-Object {
        ($_.Conditions.ClientAppTypes -contains "exchangeActiveSync" -or
         $_.Conditions.ClientAppTypes -contains "other") -and
        $_.GrantControls.BuiltInControls -contains "block"
    } |
    Select-Object DisplayName, State,
        @{n="ExcludedUsers";e={$_.Conditions.Users.ExcludeUsers -join ", "}},
        @{n="ExcludedGroups";e={$_.Conditions.Users.ExcludeGroups -join ", "}}

Confirm the policy is enabled rather than report-only, and that exclusions are limited to emergency access accounts and documented exceptions.

Monitoring and Detection

In Microsoft Sentinel or Log Analytics, the ClientAppUsed field identifies the protocol. Modern clients report "Browser" or "Mobile Apps and Desktop clients". 

// Legacy authentication attempts over the last 30 days
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where isnotempty(ClientAppUsed)
| where ClientAppUsed !in ("Browser", "Mobile Apps and Desktop clients")
| summarize Attempts = count(), Successes = countif(ResultType == "0")
    by UserPrincipalName, ClientAppUsed, AppDisplayName
| order by Successes desc
// Possible password spray over legacy protocols: one IP, many accounts
SigninLogs
| where TimeGenerated > ago(1d)
| where ClientAppUsed !in ("Browser", "Mobile Apps and Desktop clients")
| where ResultType == "50126"
| summarize Accounts = dcount(UserPrincipalName), Attempts = count() by IPAddress
| where Accounts > 10

Once the block is in place, any successful legacy sign-in is an alert, not a statistic. Also watch the audit log for changes to the blocking policy itself.

Common Mistakes

  • Selecting only "Other clients" and leaving Exchange ActiveSync with basic authentication allowed.
  • Leaving the policy in report-only mode indefinitely after the pilot.
  • Permanent exclusions for service accounts, which are the accounts attackers look for.
  • Assuming Microsoft's retirement covered everything: SMTP AUTH, on-premises Exchange and third-party services still need checking.
  • Not collecting non-interactive sign-in logs, which hides much of the legacy traffic.

Where to Start

Run the 30-day legacy sign-in query today. If it returns nothing, enable the block policy and move on to service-layer settings. If it returns results, work through the list owner by owner, deploy the policy in report-only mode, and set a firm date for enforcement.