Legacy authentication protocols — IMAP, POP, SMTP AUTH, Exchange ActiveSync with basic auth, and older Office client authentication — do not support modern MFA challenges. An account that can be accessed through these protocols can be authenticated with just a username and password, bypassing any Conditional Access policy that requires MFA.

Overe flags user accounts and tenant configurations where legacy authentication is not blocked. This is relevant even in environments that have enabled Security Defaults or broad MFA Conditional Access policies, because legacy protocol access may not be covered by those controls depending on how they are scoped.

Attackers specifically use legacy authentication in password spray attacks precisely because it bypasses modern controls. These attacks are difficult to detect because authentication attempts look like normal application sign-ins and often originate from cloud infrastructure rather than obviously suspicious locations.

• Attacker conducts a password spray attack using IMAP or Exchange ActiveSync against a large number of accounts, bypassing MFA entirely
• Single compromised account accessed through a legacy protocol without any MFA prompt
• Credential reuse attack succeeds against accounts with passwords exposed in previous data breaches
• Legacy authentication used as a persistence channel even after a compromised account's MFA is updated or enforced
• Account compromise attributed to a complex attack vector when a simple legacy auth spray was actually used
• Attacker enumerates valid accounts through legacy authentication responses before launching a targeted credential attack
• Legacy protocol access used after a forced password reset to re-authenticate without triggering an MFA challenge, because the protocol does not support one
• Sign-in attempts via Exchange ActiveSync from a cloud-hosted attacker IP look like a typical mobile device sync and are harder to distinguish from legitimate use in standard logs

Some legacy protocols remain in use for legitimate reasons. SMTP AUTH is still used by printers, scanners, and line-of-business applications that send email. POP or IMAP may be required by older mail clients or automation tools that have not been updated to support modern authentication.

The key question is whether any specific account or device actually requires legacy protocol access and whether that need has been reviewed and documented. A blanket allowance for legacy authentication across the tenant is not acceptable. Targeted exclusions for specific accounts used by specific systems — with those accounts restricted to the relevant protocol, IP range, and monitored closely — represent a managed exception rather than an open door.

Before blocking legacy authentication:

• Review sign-in logs filtered by legacy authentication clients to understand current usage before making any changes
• Identify which users or apps are still signing in via legacy protocols
• Check whether any block policy has exclusions that keep legacy authentication open for certain users or groups
• Confirm whether any business applications — printers, scanners, line-of-business apps — depend on SMTP AUTH or similar protocols
• Review whether accounts using legacy authentication have any other risk signals — password spray alerts, unusual locations, or dormancy
• Confirm with application owners whether any legacy authentication dependencies can be migrated to modern authentication

1. Review sign-in logs filtered by legacy authentication clients to understand current usage before blocking
2. Identify and contact application owners for any systems still using SMTP AUTH or legacy mail protocols
3. Where possible, migrate applications to modern authentication or OAuth-based alternatives
4. Create a Conditional Access policy blocking legacy authentication for all users, with narrow exclusions only for documented and unavoidable dependencies
5. For accounts that legitimately require legacy authentication, restrict them to the specific protocol and IP range required
6. Monitor legacy authentication sign-ins and set up alerting for unexpected usage after blocking is applied
7. Review Security Defaults status — if enabled, legacy authentication should already be blocked for most scenarios

Where direct remediation is required, Overe provides links to the appropriate Microsoft admin controls to complete the action safely.

Microsoft: Block legacy authentication with Conditional Access - https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-block-legacy-authentication

Microsoft: How to identify legacy authentication sign-ins - https://learn.microsoft.com/en-us/entra/identity/conditional-access/block-legacy-authentication

Microsoft: SMTP AUTH in Exchange Online - https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission

After reviewing legacy authentication exposure, also check these related risk areas:

• CA MFA Bypass Paths — legacy authentication is itself a form of CA bypass; review both at the same time to understand the full scope of authentication gaps in your tenant
• Conditional Access Exclusions — check whether any policy that blocks legacy auth has exclusions that inadvertently preserve access for certain user groups or applications
• Admins with Risky MFA Settings — if admin accounts can also be reached via legacy protocols, their MFA configuration becomes irrelevant; both risks compound each other
• Users with Risky MFA Settings — users with weak or no MFA and access via legacy protocols face a double exposure; address authentication strength and protocol access together
• Excessive Authentication Failures — legacy auth password spray attacks generate distinctive sign-in failure patterns; check for high-volume failures from legacy clients as part of this review