Why is legacy authentication an MFA bypass and not just 'old'?

Legacy auth protocols (basic auth over IMAP/POP/SMTP, Exchange ActiveSync, 'Other clients') predate modern authentication and can't present an MFA challenge. When a sign-in uses them, your conditional-access MFA policy is never evaluated — so an attacker with a valid password walks straight in. That's why Microsoft has been disabling basic auth tenant-wide.

How do I confirm this is malicious versus a legitimate old client?

Check the source IP/ASN and geo, whether conditionalAccessStatus is 'failure' or 'notApplied', and whether the same account also has normal modern-auth sign-ins. LogTriage's Azure signal extractor surfaces conditionalAccessStatus, mfaDetail, and the applied CA policies on every event so you can tell instantly.

What's the fix beyond detecting it?

Block legacy authentication with a conditional-access policy (or Microsoft's Security Defaults), then inventory anything that breaks and migrate it to modern auth. This rule is most useful during that migration window and as a tripwire afterward.

Detect Legacy-Auth MFA Bypass in Azure AD Sign-In Logs

Sigma Rule

title: Azure AD Sign-In via Legacy Authentication (MFA Bypass)
id: 2f8c5d11-4a7e-4b90-9c33-7e1d6a2b4c04
status: experimental
description: >
  Detects interactive sign-ins using legacy authentication clients
  ("Other clients", Exchange ActiveSync, IMAP/POP/SMTP basic auth). Legacy auth
  protocols cannot satisfy a modern MFA challenge, so conditional-access MFA is
  simply not applied — making them the single most common path attackers use to
  replay stolen credentials past MFA.
references:
  - https://attack.mitre.org/techniques/T1078/004/
author: LogTriage
date: 2026/06/23
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    clientAppUsed:
      - 'Other clients'
      - 'Exchange ActiveSync'
      - 'IMAP4'
      - 'POP3'
      - 'Authenticated SMTP'
      - 'MAPI Over HTTP'
  condition: selection
falsepositives:
  - Legacy mail clients / LOB apps still on basic auth (inventory and migrate)
  - Documented service accounts on legacy protocols
level: high
tags:
  - attack.initial_access
  - attack.defense_evasion
  - attack.t1078.004

What this rule detects

Legacy authentication is the most common way attackers get a stolen Microsoft 365 / Entra credential past multi-factor authentication. Protocols like Exchange ActiveSync, IMAP/POP/SMTP basic auth, and the catch-all “Other clients” can’t present an MFA challenge, so your conditional-access MFA policy is never evaluated — the sign-in succeeds on password alone.

This Sigma rule fires on any sign-in whose clientAppUsed is a legacy protocol.

Detection logic

The signal is a single field: clientAppUsed. Modern sign-ins report “Browser” or “Mobile Apps and Desktop clients”; legacy ones report “Other clients”, “Exchange ActiveSync”, “IMAP4”, “POP3”, “Authenticated SMTP”, or “MAPI Over HTTP”. Any of those means MFA was structurally unable to apply.

Raise confidence by correlating with conditionalAccessStatus: failure/notApplied, an unfamiliar source IP/ASN, and whether the same user also signs in normally via modern auth. LogTriage’s Azure conditional-access signal extractor stamps all of these onto each event automatically.

Validated against a real sample

Validated against azure_mfa_bypass.json (shipped with LogTriage), which contains sign-ins via “Other clients” and Exchange ActiveSync with conditionalAccessStatus: failure. The rule fires on those events and stays silent on the matching benign corporate sign-in log.

False positives

A real legacy mail client or line-of-business app can trip this — that’s a finding too (it’s an exposure to close). Inventory the source, migrate it to modern auth, and scope a documented exception only if truly unavoidable.

Frequently Asked Questions

Why is legacy authentication an MFA bypass and not just 'old'?: Legacy auth protocols (basic auth over IMAP/POP/SMTP, Exchange ActiveSync, 'Other clients') predate modern authentication and can't present an MFA challenge. When a sign-in uses them, your conditional-access MFA policy is never evaluated — so an attacker with a valid password walks straight in. That's why Microsoft has been disabling basic auth tenant-wide.
How do I confirm this is malicious versus a legitimate old client?: Check the source IP/ASN and geo, whether conditionalAccessStatus is 'failure' or 'notApplied', and whether the same account also has normal modern-auth sign-ins. LogTriage's Azure signal extractor surfaces conditionalAccessStatus, mfaDetail, and the applied CA policies on every event so you can tell instantly.
What's the fix beyond detecting it?: Block legacy authentication with a conditional-access policy (or Microsoft's Security Defaults), then inventory anything that breaks and migrate it to modern auth. This rule is most useful during that migration window and as a tripwire afterward.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs