The Client Apps Toggle That Bypasses Azure MFA

Overview

When a Conditional Access MFA policy scopes Client apps to only Browser and Mobile apps and desktop clients, IMAP, POP3, SMTP AUTH and EAS sign-ins fall outside enforcement entirely. Legacy-protocol authentication succeeds with password alone, no challenge, no risk evaluation, enabling undetected password-spray campaigns against Exchange Online mailboxes.

At a glance

Unsafe setting: Client apps condition enabled but scoped only to Browser and Mobile apps/desktop clients categories.
Failure trigger: Admin assumes a separate legacy-auth block policy already covers EAS/Other clients, leaving them unscoped in the MFA policy.
Blast radius: Legacy protocol sign-ins bypass MFA entirely, letting password-spray attacks compromise mailboxes holding Send As or Impersonation rights.
Recommended control: Create a dedicated policy blocking Exchange ActiveSync and Other clients outright; disable IMAP/POP/SMTP AUTH via Set-CASMailbox.

Fix commands and configuration

Get-CASMailbox -ResultSize Unlimited | Where {$_.ImapEnabled -eq $true -or $_.PopEnabled -eq $true}

Set-CASMailbox -ImapEnabled $false -PopEnabled $false -SmtpClientAuthenticationDisabled $true

The Trap

A Conditional Access policy where the "Client apps" condition is enabled and scoped to only "Browser" and "Mobile apps and desktop clients", while "Exchange ActiveSync clients" and "Other clients" are left unticked.

The Default State

Out of the box, the Client apps condition in a new Conditional Access policy defaults to Configure: No. That means the condition isn’t evaluated at all, and the policy applies to every client app type by inheritance, legacy included. Administrators following Microsoft’s own hardening templates or third-party audit checklists routinely flip that toggle to Yes and then select only the two modern-auth categories, assuming legacy protocols are already disabled tenant-wide by a separate block policy. In practice that separate policy is frequently half-deployed, scoped to a pilot group, or was written before a hybrid Exchange migration reintroduced Basic Auth on a subset of mailboxes.

The Blast Radius

IMAP4, POP3, SMTP AUTH and older Exchange Web Services connections identify themselves as "Other clients" or "Exchange ActiveSync clients" in the sign-in log. With the Client apps condition scoped away from those categories, the MFA-requiring policy simply doesn’t apply to them, no challenge, no device check, no risk evaluation. Any valid username and password authenticates cleanly. This is the exact mechanism behind large-scale password-spray campaigns against Exchange Online: attackers hammer EWS or IMAP endpoints because those protocols can’t render an MFA prompt and, more importantly, because the CA engine never gets asked to enforce one. Sign-in risk scoring on basic-auth events behaves differently to interactive sign-ins, so Identity Protection often stays quiet. Compromised accounts show as MFA-satisfied in reporting because the policy that should have blocked them was never in scope to begin with. Service accounts and legacy connectors using these protocols frequently hold Send As or ApplicationImpersonation rights, so a single successful spray can expose entire mailbox estates.

The Lead Mechanic Fix

Stop trying to fit legacy protocols into an MFA grant control, block them outright. Build a dedicated policy: Conditions > Client apps > Configure Yes, select only "Exchange ActiveSync clients" and "Other clients", Grant control set to Block, applied to All users excluding the break-glass account. Confirm at the protocol layer with Get-CASMailbox -ResultSize Unlimited | Where {$_.ImapEnabled -eq $true -or $_.PopEnabled -eq $true} and remediate with Set-CASMailbox -ImapEnabled $false -PopEnabled $false -SmtpClientAuthenticationDisabled $true. Verify closure by filtering sign-in logs for Client App = IMAP4, POP3, SMTP and checking the Applied Policies column no longer reads "Not applied".