Legacy MFA and conditional access reduce some risk, but they do not stop attackers who abuse legacy protocols, stolen credentials, or session weaknesses. The report says 19 percent of BEC attempts bypassed MFA in Microsoft 365 using legacy protocols. Teams need stronger authentication enforcement, protocol restrictions, and continuous monitoring of account behavior to reduce unauthorized mailbox access and downstream fraud.
Why Legacy MFA and Conditional Access Still Miss the Real Failure Path
Legacy MFA and conditional access are usually strongest at the interactive sign-in step, but BEC often succeeds after that checkpoint. Attackers work around the front door by using legacy protocols that do not honor modern prompts, replaying stolen sessions, or authenticating with credentials that are already trusted by the tenant. The result is that mailbox abuse can happen without a clean “failed login” signal.
The practical lesson is that the control gap is often in protocol coverage and session governance, not in the existence of MFA itself. If IMAP, POP, SMTP AUTH, app passwords, or token-based access remain enabled, an attacker can often route around policy enforcement and still reach email data or send fraudulent messages.
One of the most relevant indicators in the source material is that 19 percent of BEC attempts bypassed MFA in Microsoft 365 using legacy protocols. That matters because it shows the failure is not theoretical, it is a repeatable path when older authentication methods are left available.
What Actually Changes in Cloud Email Environments
Cloud email systems change the shape of the attack surface. Instead of one perimeter login event, you get multiple authentication paths, mailbox delegation paths, OAuth consent paths, session refresh paths, and protocol-specific exceptions. Conditional access can reduce exposure, but only where it is actually enforced on the path being used.
This is why organizations can have “strong MFA” and still see mailbox compromise. A user may satisfy MFA once, then an attacker uses the resulting session token, a legacy protocol, or a separately trusted application path to continue access. In cloud environments, the decisive control is often whether every authentication and access path is covered consistently, not whether the primary login flow looks hardened.
- Disable legacy authentication where the business can tolerate it.
- Require modern auth for mailbox and admin access paths.
- Review conditional access exceptions for service and app flows.
- Monitor for anomalous mailbox rules, forwarding, and consent grants.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Legacy auth bypass often relies on secrets, tokens, and other identity material. |
| NHI-03 — Authentication and Session Management | The question centers on MFA bypass, legacy protocols, and session weaknesses. | |
| NHI-05 — Authorization and Least Privilege | Mailbox compromise becomes fraud when access paths and permissions are broader than needed. | |
| Recommendation — Eliminate legacy secrets and rotate any credentials that can still authenticate mailbox access. Enforce modern authentication and invalidate reusable sessions that can outlive MFA. Reduce mailbox and application privileges to limit what a compromised session can do. | ||
| CIS Controls v8 | 6 — Access Control Management | Directly addresses restricting authentication paths and access rights for email systems. |
| 8 — Audit Log Management | Mailbox abuse is often visible only after authentication through suspicious behavior. | |
| Recommendation — Remove legacy email protocols and restrict access paths to approved methods only. Centralize and review mailbox, sign-in, and forwarding-rule logs for abuse patterns. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Legacy MFA and conditional access failures are identity and access control failures. |
| DE.CM — Continuous Monitoring | BEC often succeeds through post-authentication behavior that login controls miss. | |
| Recommendation — Apply stronger authentication policy across every email access path and exception. Monitor mailbox behavior continuously for rule creation, forwarding, and unusual access. | ||
| NIST SP 800-63 | SP 800-63B — Authentication and Lifecycle Management | Supports modern authenticator and session requirements relevant to MFA bypass. |
| Recommendation — Use modern authenticators and retire legacy methods that cannot be consistently enforced. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | BEC commonly uses stolen, replayed, or abused legitimate cloud credentials. |
| Recommendation — Detect use of legitimate accounts performing abnormal mailbox or messaging activity. | ||
Practitioner Guidance
What to prioritise: Treat protocol restrictions and session control as first-class email security controls, not as tuning on top of MFA. The highest-value work is usually removing the authentication paths that bypass policy, then validating that mailbox access is still observable after sign-in.
What to verify: Confirm which clients, protocols, and apps can still reach email if MFA is satisfied once. Validate whether token replay, app passwords, and legacy mail protocols are blocked for all users except documented exceptions, and whether those exceptions are time-bounded and reviewed.
What changes at scale: As tenant size grows, unmanaged exceptions, stale accounts, and long-lived sessions become the main reason conditional access stops being decisive. Mailbox monitoring, not just login controls, becomes the control that reveals whether policy is being bypassed in practice.
Practitioner takeaway: Legacy MFA fails in BEC cases when it protects the login event but not the full email access chain, so the real control objective is to close alternate authentication paths and detect post-authentication mailbox abuse early.
Related resources from NHI Mgmt Group
- Why does MFA still fail to stop account compromise in environments with weak credentials and social engineering?
- Why do traditional access controls fail to protect sensitive data in cloud and AI environments?
- Why can MFA still fail in cloud environments?
- Why do role-based access controls still leave governance gaps in cloud environments?
