Disable legacy authentication on cloud tenants

What the control is

Legacy authentication is the umbrella term for the pre-modern authentication protocols that most cloud tenants still allow by default for backwards-compatibility reasons. On Microsoft 365 the family includes Basic auth (a username and password sent in the HTTP header), IMAP, POP3, SMTP AUTH, older Exchange Web Services flows, MAPI/HTTP without modern auth, and several older Office client authentication paths. On Google Workspace the equivalent population is the “Less secure app access” set and the older IMAP/POP3 password authentication flows. On Salesforce, ServiceNow and the rest of the SaaS ecosystem the equivalent is whatever pre-OAuth password-based programmatic authentication still exists in the tenant.

The shared property is that legacy authentication does not participate in the modern identity stack. Conditional access policies, risk-based step-up authentication, MFA enforcement and modern identity governance are bypassed because the legacy flow does not surface to the policy engine. A tenant with MFA strictly enforced for “all users, all apps” via the modern policy can still be entered by a credential-stuffing attacker who chooses a legacy protocol, because the MFA prompt never fires for that flow.

The control is to block legacy authentication tenant-wide via conditional access policy or the equivalent platform-level control, with explicit exceptions only for documented, time-bound business-process needs.

Why it matters

Legacy authentication is the single largest residual MFA-bypass channel in most enterprise identity environments. The catalogue’s relevance is upstream of named events rather than the named event itself. The 16-billion-credential exposure of June 2025 fed account-takeover attempts at every major SaaS platform across the following twelve months; tenants with legacy authentication enabled saw the cleanest hits because MFA never fired against the credential-stuffing traffic. The 23andMe credential-stuffing breach of October 2023 (14,000 accounts compromised, 6.9 million users affected via the DNA Relatives feature) is the cleanest catalogue example of a credential-stuffing-led compromise where MFA enforcement would have constrained the entry vector. The Snowflake-customer breach wave of 2024 — Ticketmaster, AT&T, Santander and others — pivoted on infostealer-harvested credentials being walked into Snowflake tenants without MFA. The Coinbase 2024 contractor compromise is a different shape but in the same identity-tier family.

The control does not stop initial credential theft. It stops the post-theft credential-stuffing economy from working against the cloud tenants where most regulated data now lives. Combined with phishing-resistant MFA on the privileged-account population (a separate, higher-priority control), it closes the channel that allows credential-stuffing attacks to succeed at scale against the user-account population.

Where the regulators sit

Microsoft’s published guidance has been clear for several years: legacy authentication should be blocked, with explicit exceptions only for documented business-process needs, and Microsoft has been progressively retiring legacy-auth-supporting infrastructure across Microsoft 365 service tiers. NCSC’s cloud security principles and identity-and-access-management collection point at modern OAuth-based authentication as the only sensible default. CISA’s Microsoft 365 secure configuration baseline mandates blocking legacy authentication. The CIS Microsoft 365 Foundations Benchmark — version 3.x at the time of writing — makes it an explicit benchmark requirement.

The framework view is unanimous and the platform vendors have been winding the legacy protocols down for years. The configuration is a single conditional-access policy in most enterprise tenants.

Where it usually breaks

The single failure mode is the long-tail business-process inventory. Most enterprises have a handful of legitimate, sometimes-important workflows that still depend on legacy authentication: an old line-of-business application authenticating to Exchange via SMTP AUTH; a multi-functional printer scanning to email via SMTP basic auth; a backup tool using IMAP password authentication; a third-party integration that has not been migrated to OAuth. Each of these creates a small window of legacy auth that has to be either migrated or explicitly time-boxed.

The fix is the standard one: enable legacy-auth audit logging, identify the actual sources of legacy authentication traffic over a four-to-six-week window, contact the owners, document the migration plan, and then enforce the block with a small, documented allowlist for any traffic that genuinely cannot be migrated within the enforcement window. The allowlist entries are reviewed quarterly until the legitimate dependency is migrated.

What good looks like

A tenant-wide conditional-access policy blocking all legacy authentication. Explicit, documented, owner-attached exceptions only for traffic that genuinely cannot be migrated, reviewed quarterly. Continuous monitoring of legacy-auth audit logs to surface new, undocumented usage. The same policy applied to every cloud tenant in the estate, not just the primary identity tenant.

The cost is configuration time and the operational work to migrate the long-tail dependencies. The benefit is closing the largest residual MFA-bypass channel in cloud-tenant identity architecture.