Why MFA Is Not Enough Anymore: Real Microsoft 365 Attack Paths
MFA is still mandatory, but it is not a complete Microsoft 365 security boundary. Attackers now steal sessions, abuse OAuth consent, target help desk workflows, and find Conditional Access gaps that MFA was never designed to close.
MFA stopped being the finish line when attackers stopped attacking only passwords
MFA still matters. Any account without MFA, especially an administrator account, is an avoidable exposure.
The problem is treating MFA coverage as the main measure of identity security. In Microsoft 365 incidents, attackers often do not need to break MFA cryptographically. They need one valid session, one approved prompt, one Conditional Access exclusion, one over-permissioned OAuth app, or one support process that lets them take over the account.
Microsoft Secure Score may show strong MFA adoption. Microsoft Entra ID sign-in logs may show successful MFA. The tenant can still be exposed if a stolen token from an unmanaged device is allowed to reach Exchange Online, SharePoint, Teams, or Microsoft Graph.
The better question is not, "Do we have MFA?" It is, "What can an attacker still do after MFA is present?"
Attack path 1: Adversary-in-the-middle phishing steals the session
MFA stops many basic credential attacks. It does not reliably stop adversary-in-the-middle phishing.
In this path, the user opens a fake SharePoint, Teams, voicemail, DocuSign, or Microsoft 365 sign-in link. The page proxies the real Microsoft sign-in flow. The user enters the password, completes MFA, and sees a normal result. The attacker captures the authenticated session token or cookie.
From the attacker's perspective, MFA has already succeeded. If Conditional Access allows browser access from unmanaged devices, untrusted locations, or unknown endpoints, the stolen session can be useful until it expires, is revoked, or is blocked by risk and device controls.
Common follow-on actions include:
- Creating inbox rules that hide security alerts, payment discussions, or vendor messages.
- Searching mailbox history for invoices, wire instructions, contracts, and password reset emails.
- Adding or changing authentication methods if registration policies allow it.
- Accessing OneDrive and SharePoint content.
- Sending internal phishing from the compromised account.
A QR code in the message does the same job with one extra step: the user scans it with a personal phone, leaves the managed browser, and completes the proxied sign-in where the device conditions in Conditional Access may not apply. Treat QR-code phishing as this path with a weaker device.
The control is not more prompts. Use phishing-resistant authentication, Conditional Access authentication strengths, device compliance requirements for sensitive apps, sign-in risk policies where Microsoft Entra ID P2 is licensed, and a tested token revocation process.
Attack path 2: Push fatigue and social engineering still work
Push-based MFA is convenient, but it can still be abused. After obtaining a password through phishing, credential reuse, infostealer logs, or password spraying, attackers try to get the user to approve access.
Microsoft Authenticator number matching reduces accidental approvals and is now the expected baseline for Microsoft push notifications. It does not eliminate social engineering. Attackers can call a user pretending to be IT, reference a real maintenance window, and coach the user through the approval.
High-risk users should not rely on commodity push MFA. Prioritize phishing-resistant methods for administrators, finance, payroll, executives, help desk staff, and users with access to regulated or customer-sensitive data. Strong options include FIDO2 security keys, passkeys where available, Windows Hello for Business, and Microsoft Entra certificate-based authentication.
Use Conditional Access authentication strengths to require stronger methods for privileged actions and sensitive apps.
Attack path 3: Conditional Access exceptions become the real perimeter
MFA deployments often decay through exceptions. A break-glass account is excluded. A legacy workflow is excluded. A public IP range is trusted. A third-party integration is bypassed. A VIP receives a temporary exception that never expires.
Common findings include:
- Policies scoped to "All users" with long exclusion lists and no owner.
- Administrator roles excluded from user policies but not covered by dedicated admin policies.
- Guest users accessing sensitive SharePoint sites with weaker requirements.
- Trusted locations based on broad public IP ranges, including VPN egress used by unmanaged devices.
- Policies that require MFA but do not require compliant devices for high-value apps.
- Service accounts or old clients that keep legacy sign-in paths alive.
MFA coverage is not the same as effective access control. Strong Conditional Access design evaluates the user, role, device, location, application, sign-in risk, user risk, authentication strength, and session controls.
Treat Conditional Access like production infrastructure: document policies, test changes in report-only mode, use named owners for exceptions, set expiration dates for bypasses, and review sign-in logs from an attacker’s perspective.
Attack path 4: OAuth consent creates durable access
OAuth abuse is a common Microsoft 365 persistence path. Instead of stealing only a password or session, an attacker convinces a user or administrator to consent to a malicious application. The app may request delegated or application permissions to read mail, read files, send mail, or maintain access through Microsoft Graph.
Once consent is granted, password resets may not remove the access. MFA may not be prompted in the way stakeholders expect. The user may not realize that they authorized ongoing access.
This is most dangerous when users can consent to third-party apps broadly, admin consent is granted without permission review, or enterprise applications and service principals are not monitored.
Reduce the risk by restricting user consent, allowing only verified low-risk permissions where appropriate, using admin consent workflows, reviewing enterprise applications and service principals, monitoring new OAuth grants, and using Microsoft Defender for Cloud Apps app governance capabilities where licensed.
An account-takeover response that only resets the password and requires MFA can leave OAuth persistence untouched.
Attack path 5: Help desk and authentication method reset abuse
Attackers target the processes around MFA. If a help desk can reset MFA, add a phone number, issue a Temporary Access Pass, or approve an authentication method change after weak identity proofing, the attacker may not need the original factor.
Review who can manage authentication methods in Microsoft Entra ID. Limit these rights to dedicated administrative roles, use separate admin accounts, and require stronger verification for executives, finance users, administrators, and help desk staff.
Monitor and alert on authentication method registration, deletion, default method changes, Temporary Access Pass creation, and suspicious self-service password reset activity. These events often appear before mailbox abuse or data access.
Attack path 6: Legacy clients and service account patterns bypass modern controls
Some older clients, protocols, and service account patterns do not support the same controls as modern authentication flows. Exchange Online Basic authentication has been broadly disabled by Microsoft, but tenants can still carry risk through SMTP AUTH exceptions, outdated clients, unattended scripts, weak app registrations, and shared accounts.
Inventory non-interactive sign-ins, service principals, SMTP AUTH usage, and accounts excluded from Conditional Access. Replace shared service accounts with managed identities, certificates, workload identity controls, or properly scoped app registrations where possible.
Every exception should have an owner, business justification, compensating controls, monitoring, and a retirement date.
Which MFA methods to allow, and what Microsoft already enforces
Not every second factor resists the paths above. Rank them:
- Phishing-resistant: passkeys and FIDO2 security keys, Windows Hello for Business, Microsoft Entra certificate-based authentication. Required for administrators, finance, payroll, executives and help desk staff; the passkey rollout order covers the sequence for 20 to 500 seats.
- Acceptable baseline: Microsoft Authenticator push with number matching and additional context.
- Fallback only: SMS and voice calls. SIM swap, call forwarding and social engineering defeat them, so keep them for account recovery, not daily sign-in.
- Temporary Access Pass: for onboarding and recovery, time-limited and issued by a restricted role.
Two tenant settings decide how the methods are enforced. Security defaults need no license and may already be on in a tenant created on or after 22 October 2019; they require MFA registration for everyone and block legacy authentication, with no exceptions and no per-app control. Conditional Access replaces them when you need device, location, risk or app conditions; Microsoft Learn states it requires Microsoft Entra ID P1 or Microsoft 365 Business Premium. On the October 2026 price list, Microsoft Entra ID P1 is $84.00 per user per year ($7.00 per month), Business Premium $264.00 ($22.00), and Entra ID P2, which adds sign-in and user risk policies and Privileged Identity Management, $120.00 ($10.00); our P1 vs P2 vs Entra Suite article has the full comparison.
Microsoft also enforces MFA on its own. Per Microsoft Learn (3 April 2026), sign-ins to the Azure portal, Microsoft Entra admin center and Intune admin center have required MFA since October 2024, the Microsoft 365 admin center since February 2025, and Azure CLI, Azure PowerShell, infrastructure-as-code tools and the control-plane REST API for create, update and delete operations since 1 October 2025. Scripts and service accounts that still sign in with a password fail on those operations, which is why path 6 needs managed identities rather than exceptions.
Two more Microsoft numbers belong in the design: keep the Global Administrator role on fewer than five people, and keep two or more cloud-only emergency access accounts, excluded from the Conditional Access policies that block sign-in and alerted on every use.
The email layer in front of MFA
Most of the paths start with a message. Microsoft Defender for Office 365 Plan 1 ($24.00 per user per year, $2.00 per month, and included in Business Premium) adds Safe Links, Safe Attachments, anti-phishing and impersonation protection to Exchange Online Protection; Plan 2 ($60.00 per user per year, $5.00 per month) adds Attack Simulation Training, Threat Explorer and automated investigation and response. Microsoft list price, October 2026 price list.
Domain authentication closes direct spoofing of your own domain: publish SPF and DKIM, add DMARC at p=none, read the reports for a few weeks, fix the legitimate senders that fail, then move to quarantine and reject. The order and the mistakes are in SPF, DKIM and DMARC for Microsoft 365. DMARC does nothing against a lookalike domain or a compromised partner mailbox, which is why the identity controls above still carry the weight.
What to add around MFA
Start with identity hygiene. Use separate admin accounts for administration. Protect privileged accounts with phishing-resistant MFA. Use Microsoft Entra Privileged Identity Management where Microsoft Entra ID P2 is licensed. Keep emergency access accounts cloud-only, intentionally excluded from Conditional Access dependencies, tightly monitored, and tested.
Harden authentication. Move administrators and high-risk users away from basic push approval. Use Conditional Access authentication strengths for privileged roles and sensitive apps. Remove legacy sign-in paths and document any remaining exceptions.
Bind access to trusted conditions. For high-value apps, require compliant devices, Microsoft Entra hybrid joined devices, or approved mobile app protection patterns where appropriate. Do not allow a stolen browser session from an unmanaged device to have the same access as a known corporate endpoint. Use Microsoft Entra ID Protection risk signals when licensed.
Control sessions. Use sign-in frequency, persistent browser session settings, Continuous Access Evaluation-aware apps, Microsoft Defender for Cloud Apps session controls where licensed, and a repeatable process to revoke refresh tokens after compromise.
Monitor the actions attackers use: inbox rules, mailbox forwarding, suspicious sign-in properties, impossible travel, authentication method changes, OAuth consent grants, new service principals, privileged role activations, mass file access, and unusual Microsoft Graph activity.
MFA is one control. The goal is to make stolen credentials, stolen sessions, and tricked users insufficient for meaningful compromise.
Frequently asked questions
Is MFA required for every Microsoft 365 user?
Microsoft enforces it for its admin portals and Azure management; for everyone else the requirement is yours to set. Require it for all users through security defaults or Conditional Access, and require phishing-resistant methods for privileged and high-risk roles.
Is Microsoft Authenticator enough?
With number matching it is a reasonable baseline for ordinary users. It is not phishing-resistant: an adversary-in-the-middle page or a coached approval still gets through. Administrators, finance and executives should move to passkeys, FIDO2 keys or Windows Hello for Business.
Should we still allow SMS or voice-call MFA?
Only as a recovery fallback, and not for administrators. Both are exposed to SIM swap and call forwarding and are weaker than any app-based or phishing-resistant method.
Can MFA stop phishing?
It stops password-only attacks. It does not stop session-token theft, OAuth consent abuse or help desk social engineering; those need Conditional Access device and risk conditions, consent restrictions, phishing-resistant methods and monitoring.
When should MFA go on during a Microsoft 365 migration?
Before cutover: administrators first, then a pilot group, then everyone, with registration campaigns, a help desk script and a Temporary Access Pass process ready. Adding it after users are live doubles the support load.
Sources
- Mandatory multifactor authentication for Azure sign-in — Microsoft Learn, ms.date 3 April 2026, read from the MicrosoftDocs GitHub source on 2026-10-11
- Security defaults in Microsoft Entra ID — Microsoft Learn, ms.date 21 July 2025, read from the MicrosoftDocs GitHub source on 2026-10-11
- What is Conditional Access? — Microsoft Learn, ms.date 27 April 2026, read from the MicrosoftDocs GitHub source on 2026-10-11
- Best practices for Microsoft Entra roles — Microsoft Learn, ms.date 1 June 2026, read from the MicrosoftDocs GitHub source on 2026-10-11
- Manage emergency access accounts in Microsoft Entra ID — Microsoft Learn, ms.date 4 June 2026, read from the MicrosoftDocs GitHub source on 2026-10-11
- Microsoft, US commercial price list, October 2026 (all Microsoft list prices above)
| Real attack path | Why MFA alone fails | Microsoft 365 controls to add |
|---|---|---|
| Adversary-in-the-middle phishing | User completes MFA on a proxied Microsoft sign-in flow; attacker captures the authenticated session token or cookie. | Phishing-resistant authentication, Conditional Access authentication strengths, compliant-device requirements for sensitive apps, Microsoft Entra ID Protection sign-in risk policies where licensed, token revocation runbook. |
| Push fatigue or social engineering | User is tricked or coached into approving access, even when the password was stolen elsewhere. | Microsoft Authenticator number matching as a baseline, phishing-resistant methods for high-risk users, Conditional Access authentication strengths, targeted training for finance, help desk, and admin roles. |
| Conditional Access exception abuse | MFA exists, but exclusions, trusted locations, weak scoping, or unmanaged devices create bypass paths. | Policy rationalization, report-only testing, admin-specific policies, named exception owners, expiration dates, regular sign-in log review. |
| OAuth consent abuse | Attacker gains Microsoft Graph/API access that may persist beyond password resets and may not trigger expected MFA prompts. | Restrict user consent, use admin consent workflows, review enterprise applications and service principals, monitor OAuth grants, use Microsoft Defender for Cloud Apps app governance where licensed. |
| Help desk or authentication method reset abuse | Attacker convinces support to reset MFA, add a method, or issue temporary access. | Strong identity proofing, limited authentication administrator roles, approval workflows for high-risk users, alerts on authentication method changes and Temporary Access Pass creation. |
| Legacy client, protocol, or service account path | Older clients, SMTP AUTH exceptions, shared accounts, or scripts may not enforce modern Conditional Access patterns. | Disable or restrict legacy paths, inventory SMTP AUTH and non-interactive sign-ins, replace shared accounts, use managed identities or scoped app registrations, monitor exceptions. |
Key takeaways
- MFA is mandatory, but it is not a complete security boundary for Microsoft 365.
- Modern account takeover often uses stolen sessions, OAuth consent, Conditional Access exceptions, and weak support workflows.
- Conditional Access quality matters more than the MFA coverage number in a dashboard.
- Privileged and high-risk users should use phishing-resistant authentication, not simple push approval.
- Incident response must include token revocation, OAuth grant review, inbox rule inspection, authentication method auditing, and service principal review.
- Keep the Global Administrator role on fewer than five people and two or more cloud-only emergency access accounts; Microsoft already requires MFA for its admin portals and, since 1 October 2025, for Azure CLI, PowerShell and API changes.
If you want a practical view of where MFA can still be bypassed in your tenant, IT Partner's Microsoft 365 Security Baseline and Secure Score Remediation engagement ($3,450 per project, quoted in writing before work begins) reviews Conditional Access, authentication methods, OAuth exposure and the Secure Score gaps and leaves you a remediation plan tied to the six paths above. If only the policies need a second look, the Conditional Access Policy Review and Break-Glass Validation is $2,450 per project, or book 30 minutes with your sign-in logs open.
Questions this article didn’t answer?
Thirty minutes with Mike — our CEO, not a sales rep. Bring the hard version of the question.