This issue has been assessed as high severity. Review affected configurations immediately.
The Silent MFA Bypass Hiding in Most Tenants
You have MFA enabled across your organisation. Your Conditional Access policies enforce it for every user. And yet attackers are successfully authenticating to your Exchange Online mailboxes, Teams accounts, and SharePoint sites without triggering a single MFA prompt. If this sounds familiar, legacy authentication is probably why.
Legacy authentication refers to authentication protocols that predate modern token-based flows — specifically, protocols that cannot negotiate an interactive Conditional Access challenge because they do not support it by design. When an application uses legacy auth to connect to Entra ID, the authentication request passes through without encountering Conditional Access policies that require MFA. From the attacker’s perspective, a tenant that has MFA enforced but hasn’t blocked legacy auth has left a highway open.
Which Protocols Are Affected
Legacy authentication encompasses a well-defined set of protocols:
- SMTP AUTH — used by mail clients and applications to send mail
- POP3 / IMAP — used by older email clients to retrieve mail
- Exchange ActiveSync (EAS) — used by mobile mail apps that do not use Modern Authentication
- HTTP Basic Auth — used in REST calls where the client sends username and password directly
- Office 2013 and older desktop clients — these do not support Modern Authentication (ADAL/MSAL) and fall back to basic auth
- Older Exchange Web Services (EWS) clients
None of these protocols can present an interactive browser window to a user. When Entra ID receives an authentication request via these protocols, it cannot redirect the session to an MFA prompt. The Conditional Access engine’s “require MFA” grant control simply does not apply. The authentication succeeds on credentials alone.
How Attackers Exploit It
Password spraying against legacy authentication endpoints is one of the most common initial access techniques against Microsoft 365 tenants. The technique is simple: test a small number of commonly used passwords (Password123!, Summer2026!, the organisation’s name plus a digit) against every valid email address in the directory. Use a slow spray rate — one attempt per hour per account — to stay under lockout thresholds. Target the SMTP AUTH or EWS endpoint rather than the web login, because legacy auth produces fewer detections in sign-in logs.
Microsoft’s sign-in log telemetry consistently shows that legacy authentication accounts for a disproportionate share of compromised accounts in cloud environments. In tenants without legacy auth blocked, a successful spray on a single executive account opens the full email history, calendar, Teams messages, and SharePoint content of that user — without the attacker ever triggering an MFA challenge.
Credential stuffing follows the same path. Credentials from third-party breaches (email address and password combinations) are automated against legacy auth endpoints. Hit rates in the 2-5% range are typical against enterprise tenants where password reuse is common and legacy auth is not blocked.
Detecting Legacy Authentication in Your Tenant
Before blocking legacy auth, understand your current exposure. Run this KQL in Microsoft Sentinel or Microsoft 365 Defender:
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed !in (
"Browser",
"Mobile Apps and Desktop clients",
"Exchange ActiveSync (Supported)"
)
| where ClientAppUsed has_any (
"Exchange ActiveSync",
"IMAP4",
"POP3",
"SMTP",
"Other clients",
"Authenticated SMTP",
"AutoDiscover",
"Exchange Web Services",
"MAPI Over HTTP",
"Offline Address Book"
)
| summarize
LegacyAuthSignins = count(),
UniqueUsers = dcount(UserPrincipalName),
UniqueIPs = dcount(IPAddress),
Apps = make_set(ClientAppUsed),
UserList = make_set(UserPrincipalName, 20)
by bin(TimeGenerated, 1d)
| order by TimeGenerated descA companion query that shows which users and applications are generating legacy auth, useful for stakeholder communication before enforcement:
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed has_any (
"IMAP4", "POP3", "SMTP", "Authenticated SMTP",
"Exchange Web Services", "Exchange ActiveSync",
"MAPI Over HTTP", "Other clients"
)
| where ResultType == 0
| summarize
SigninCount = count(),
LastSeen = max(TimeGenerated),
IPList = make_set(IPAddress, 5)
by UserPrincipalName, ClientAppUsed, AppDisplayName
| order by SigninCount descBlocking Legacy Authentication with Conditional Access
The recommended remediation is a Conditional Access policy that blocks all legacy authentication. The scope should be all users; exclusions should be minimal and time-bounded.
In the Entra admin portal:
- Navigate to Protection > Conditional Access
- Create a new policy:
- Users: All users (scope exclusions for break-glass accounts)
- Target resources: All cloud apps
- Conditions > Client apps: Check “Exchange ActiveSync clients” and “Other clients”
- Grant: Block access
- Set to Report-only first, then validate via the sign-in logs for 1-2 weeks before enabling
The Conditional Access JSON equivalent (for Terraform/policy-as-code):
{
"displayName": "Block Legacy Authentication",
"state": "enabledForReportingButNotEnforced",
"conditions": {
"clientAppTypes": [
"exchangeActiveSync",
"other"
],
"users": {
"includeUsers": ["All"],
"excludeGroups": ["<break-glass-group-id>"]
},
"applications": {
"includeApplications": ["All"]
}
},
"grantControls": {
"operator": "OR",
"builtInControls": ["block"]
}
}Handling Legitimate Legacy Auth Dependencies
In almost every enterprise tenant, some legacy auth traffic exists for legitimate reasons. The most common sources:
SMTP AUTH from applications. Line-of-business applications, scanners, and monitoring tools that send alert emails often use SMTP AUTH. Remediation options: switch to Microsoft Graph Mail Send (OAuth), use Exchange Online’s “send mail as” via the Graph API, or move to a dedicated outbound mail relay that handles authentication separately.
Older mobile email clients using EAS. Devices running iOS Mail or Android’s native mail app with basic auth enabled. Remediation: enforce Modern Authentication via Intune MAM/MDM policy, require Outlook for iOS/Android which defaults to Modern Auth.
Service accounts using IMAP/POP. Audit these against actual usage — many are inherited configurations that are no longer actively used. Query your sign-in logs: if a service account’s last IMAP sign-in was six months ago, it is a candidate for migration rather than an exception.
Break-glass accounts. Exclude from the blocking policy but monitor sign-in activity on these accounts separately.
What to Expect After Blocking
Blocking legacy auth is one of the highest-impact, lowest-cost security improvements available for Microsoft 365 tenants. Microsoft’s data from the Secure Score programme consistently shows it as a top recommendation, and tenants that block it see measurable reductions in compromised account incidents.
The disruption during rollout is real — users with legacy email clients will lose access until they switch to Outlook or enable Modern Auth on their existing client. Plan the change management before flipping the policy to enforcement mode. A week in report-only mode, combined with targeted communication to the users generating the most legacy auth traffic, reduces the blast radius significantly.
Monitoring After Enforcement
Once blocking is active, monitor for:
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 53003 // Blocked by Conditional Access
| where ConditionalAccessStatus == "failure"
| where ClientAppUsed has_any (
"IMAP4", "POP3", "SMTP", "Other clients",
"Exchange ActiveSync", "Exchange Web Services"
)
| summarize
BlockedAttempts = count(),
UniqueIPs = dcount(IPAddress),
IPList = make_set(IPAddress, 10)
by UserPrincipalName, ClientAppUsed
| order by BlockedAttempts descHigh volumes of blocked legacy auth attempts from a single IP targeting multiple accounts is a password spray in progress. Escalate to identity investigation immediately and consider adding the source IP to your named locations block list.