How MFA is Being Bypassed in Microsoft 365
May 15, 2026
Nicole Walker
Security & Compliance
|
Microsoft 365
|
Cybersecurity
|
Sourcepass MCOE
5 min read
Multi-factor authentication is widely deployed across Microsoft 365 tenants. Yet account compromise continues at scale.
This is not because MFA does not work. It is because attackers have largely stopped trying to defeat authentication itself.
Instead, they operate after authentication. Session tokens, OAuth grants, and quiet configuration changes give attackers what they need. They can stay in place without triggering obvious alerts. Over the last 18 months, Microsoft and third-party threat research have shown this pattern repeatedly. MFA is being bypassed without being broken.
This helps explain why organizations with strong password policies and universal MFA enforcement still experience business email compromise and lateral account abuse.
Business Email Compromise Remains a High-Impact Risk
Business email compromise continues to be one of the costliest cybercrime categories globally.
According to the FBI, BEC accounts for billions in reported losses each year. Most incidents are tied to invoice fraud, wire transfer redirection, and vendor impersonation.
The attack sequence is consistent across industries:
- A user mailbox is compromised
- The attacker stays quiet to avoid detection
- Existing email threads and financial workflows are quietly monitored
- Legitimate conversations are hijacked at the moment of payment or approval
This is not random phishing. It is deliberate fraud that depends on long-term access inside Microsoft 365 mailboxes.
That persistence is exactly what modern MFA bypass techniques are designed to enable.
Why MFA Alone Does Not Stop Modern Microsoft 365 Attacks
Session Theft Enables MFA Bypass Without Credential Theft
Adversary-in-the-middle phishing attacks intercept legitimate Microsoft sign-in flows in real time. Users authenticate successfully, complete MFA, and receive valid sessions tokens. Attackers capture those tokens and reuse them from another device or location.
At that point:
- Passwords are no longer required
- MFA challenges are not triggered again
- Sign-ins appear successful and legitimate in logs
MFA protects the moment of sign-in. It does not protect the session that follows unless additional controls are in place.
OAuth Consent Attacks Create Persistent Access Paths
OAuth consent phishing relies on users approving access for malicious applications. These applications impersonate legitimate services. Once consent is granted, they gain API-level access to mail, files, and calendar data.
After consent is approved:
- Password resets do not revoke access
- MFA re-registration does not remove access
- Mailbox rules and user behavior may appear unchanged
This attack path persists until enterprise application permissions are explicitly reviewed and revoked. That is why it often survives standard incident response steps.
MFA Fatigue Still Works at Scale
Push-based MFA remains vulnerable to approval fatigue. Repeated prompts increase the chance of accidental approval, especially during high-volume work periods or off-hours.
Microsoft guidance now treats number matching as a baseline control rather than an optional enhancement. It directly reduces accidental approvals without adding session complexity.
What Attackers do After Access is Gained
Once inside a tenant, attackers prioritize persistence and invisibility over speed. The goal is to stay present without disrupting normal activity or triggering security controls.
Common post-compromise actions include:
- Mailbox rules created to suppress security notifications or hide specific messages
- External auto-forwarding configured for quiet, ongoing data theft
- Additional authentication methods added to maintain independent access
- OAuth applications registered to preserve long-term control
These techniques let attackers stay hidden long enough to study financial workflows. They can then impersonate legitimate activity. The longer they stay undetected, the less likely compromise triggers an immediate investigation.
Microsoft 365 Security Baseline for Modern Identity and Token-Based Attacks
These controls focus on where modern attacks actually succeed, not just how they begin.
Adopt Phishing-Resistant Authentication
Phishing-resistant authentication methods reduce exposure to adversary-in-the-middle attacks. They work by removing browser-bound credentials from the authentication flow.
These methods include:
- FIDO2 security keys
- Windows Hello for Business
- Certificate-based authentication
- Passkeys
Authentication occurs outside the browser session. This prevents tokens from being captured or replayed by phishing infrastructure, even after the user completes a legitimate sign-in.
Bind Session Tokens to Devices with Conditional Access
Conditional Access Token Protection binds Microsoft Entra session tokens to a specific device. If a token is copied and replayed from another device or location, access fails.
This control targets session theft directly rather than attempting to stop the initial phishing event.
Apply Risk-Based Access Controls in Entra ID Protection
Risk-based access policies watch for sign-in patterns tied to token theft or hidden infrastructure. When those patterns appear, they trigger automated responses.
This approach is effective at detecting:
- Session reuse from unfamiliar environments
- Atypical sign-in behavior that completes successfully
- Access patterns that would otherwise appear legitimate in logs
Risk-based enforcement adds a check where it matters most, without treating all users or all sign-ins the same.
Remove External Auto-Forwarding as a Default Capability
External auto-forwarding remains one of the most reliable BEC persistence mechanisms. Disabling it tenant-wide and granting scoped exceptions removes a low-visibility data exfiltration path that attackers consistently abuse.
Strengthen Defender for Office 365 Email Protections
Impersonation protection, Safe Links, and Safe Attachments reduce the volume of successful phishing attempts that reach inboxes. These controls do not prevent MFA bypass on their own. However, they reduce exposure to the attack paths that lead to token theft and consent abuse.
Control OAuth Consent and Govern Enterprise Applications
OAuth abuse does not surface through mailbox rules or traditional email indicators. It persists at the application and token level.
Controls should include:
- Restricting user consent to verified publishers and low-risk scopes
- Requiring admin approval for broad or persistent permissions
- Regular review of enterprise applications with defined ownership and removal criteria
Effective app governance closes a persistence channel that standard account remediation does not address.
Remove Conditions that Enable MFA Fatigue
Push-based MFA remains open to accidental approval under repeated prompting. To reduce fatigue-driven acceptance without adding unnecessary friction:
- Enforce number matching as a baseline
- Monitor for repeated failed challenges
- Limit approval-only methods where possible
Common Questions about MFA Bypass and Microsoft 365 Security
-
Does MFA stop business email compromise?
MFA eliminates credential-based account takeover, which is one of the most common BEC entry points. It does not protect against session token theft or OAuth consent abuse. Both occur after authentication has already completed successfully. Closing those gaps requires phishing-resistant MFA, token binding, and application consent governance.
-
Why do MFA-protected accounts still get compromised?
Most modern compromises occur after successful authentication. Stolen tokens and delegated permissions allow attackers to bypass MFA without triggering failures.
-
How can you tell if MFA bypass has already occurred?
In many cases, MFA bypass does not generate failed sign-in alerts. Access often appears successful because attackers are using valid session or OAuth tokens issued after legitimate authentication. Detection relies on unusual sign-in context, session reuse, or post-authentication activity that does not match normal behavior.
-
What control provides the most immediate risk reduction?
Phishing-resistant MFA combined with token protection addresses the most common MFA bypass techniques in use today.
-
Why don't password resets stop OAuth-based attacks?
OAuth-based attacks do not depend on passwords after consent is granted. When a malicious application has delegated permissions, resetting the password or MFA does not remove access. The application retains access until the enterprise application or service principal is explicitly revoked.
Where MFA Fits in Modern Microsoft 365 Security
Security failures in Microsoft 365 are rarely caused by a single missing control. More often, they come from assumptions about where authentication ends and how trust is maintained afterward.
MFA remains foundational. But its effectiveness depends on what surrounds it. Modern attacks operate inside authenticated sessions. They rely on stolen tokens, delegated access, and quiet persistence rather than credential misuse.
Organizations that design controls with these realities in mind reduce both the likelihood and impact of compromise. Prioritizing session integrity, consent governance, and post-authentication visibility strengthens the tenant without adding unnecessary complexity.
Interested in understanding how these risks apply to your Microsoft 365 environment or learning more about our Security Assessment? The Sourcepass MCOE team can help you identify gaps across sessions, tokens, and OAuth access.
Subscribe To
Sourcepass Insights
Sourcepass Insights
Stay in the loop and never miss out on the latest updates by subscribing to our newsletter today!
