Legacy Authentication

Legacy authentication in the Microsoft 365 context means the old authentication protocols that predate modern OAuth-based authentication — POP3, IMAP4, SMTP AUTH with basic credentials, MAPI over HTTP basic, Exchange ActiveSync basic, Office 2010/2013 with legacy auth. These protocols can't enforce MFA — they only accept username and password — so they're a bypass route around your Conditional Access policies. Microsoft has progressively disabled legacy auth for most services since 2022. A Conditional Access policy blocking legacy authentication is item one on every modern security baseline. The replacement is modern authentication (OAuth 2.0), which supports MFA, CAE, and the rest of the modern security stack.

Why it's a security hole, specifically

Legacy protocols authenticate with nothing more than a username and password sent on every request — there's no token, no interactive challenge, and critically, no place for MFA to insert itself. That makes them the preferred entry point for password-spray attacks: an attacker with a list of leaked or guessed credentials sprays them against a tenant's legacy-auth endpoints (typically Exchange's), and because a correct password is sufficient on its own, a successful guess grants full mailbox access with no second factor to defeat. Microsoft's own threat telemetry cited legacy authentication as the entry point for the overwhelming majority of credential-based account compromises before it began disabling the protocols tenant-wide.

Worked example

A tenant enforces MFA for all users through Conditional Access, but a departing employee's old phone still has an Outlook-for-Android build from years earlier configured with basic-auth ActiveSync, and a finance system integration still authenticates via SMTP AUTH with a stored username and password. An attacker who obtains that stored SMTP password (from a breached third-party system, say) can send mail as that account with no MFA challenge at all, completely bypassing the Conditional Access MFA policy that appears — on paper — to protect every sign-in. A Conditional Access policy targeting the "legacy authentication clients" client-app condition and blocking it outright closes this gap regardless of which individual legacy protocol the attacker tries.

Where it still shows up

Even in tenants that believe they've eliminated it, legacy auth tends to survive in a handful of specific places: SMTP AUTH client submission for line-of-business systems and scanners/printers that relay mail through Microsoft 365 (Microsoft disabled this by default for new tenants but it can be re-enabled per-mailbox), older multi-function printers configured to scan-to-email using basic credentials, and legacy mobile mail clients that were never migrated to a modern-auth-capable app. Sign-in logs filtered to the "client app" column showing anything other than "Mobile Apps and Desktop clients" or "Browser" (modern auth) are the fastest way to find what's still using it.

Common pitfalls

The most common mistake is blocking legacy authentication tenant-wide without first auditing sign-in logs for a representative period — a scanner or automated reporting system quietly relying on SMTP AUTH will simply stop working with no obvious error message pointing back to the Conditional Access change, and the resulting outage can take longer to diagnose than the original security gap took to close. The fix for anything genuinely still needing basic-auth SMTP is per-mailbox authentication policies scoped narrowly to that one account, not a tenant-wide re-enablement.