Is MFA Enough to Protect Microsoft 365 from Phishing?

28 July 2026 8 min read 1542 words

Lead

MFA makes Microsoft 365 account takeover much harder, but it does not eliminate phishing risk. Modern attacks increasingly do not try to “break” the second authentication factor — instead, they persuade an employee to approve a legitimate sign-in or authorize an attacker-controlled device.

For a business, the result can be access to email, SharePoint files, Teams conversations, contacts, and commercial correspondence. Microsoft 365 security therefore needs to cover more than MFA: it should include authentication-flow controls, Conditional Access, session-token protection, email security, and identity monitoring.

Why MFA Alone Is Not Enough

MFA primarily protects against the use of a stolen password. However, if an employee approves a sign-in through a malicious intermediary or authorizes a device code generated by an attacker, MFA may be completed successfully — for the attacker’s benefit.

Two attack patterns are especially relevant to Microsoft 365 environments:

Adversary-in-the-Middle (AiTM) phishing — a fake login page proxies the user’s interaction with the real Microsoft service and captures credentials or session artifacts.
Device code phishing — a victim enters a code on a legitimate Microsoft sign-in page and authorizes a session or device initiated by the attacker.

Microsoft identifies device code flow as a high-risk authentication flow that can be used in phishing attacks or to access corporate resources from unmanaged devices. Microsoft recommends blocking device code flow wherever possible. Source: Microsoft Learn — authentication flows in Conditional Access.

How Device Code Phishing Works

Device code flow is a legitimate OAuth authentication mechanism designed for devices with limited input capabilities, such as certain meeting-room systems or devices without a convenient keyboard. The user opens a Microsoft sign-in page, enters a short code, and confirms their identity.

In a phishing scenario, the attacker starts this process on their own device and then convinces an employee to enter the supplied code and authenticate on the real Microsoft website. The victim may never see a fake login form, which makes domain-based phishing checks insufficient on their own.

After successful authorization, the attacker may obtain tokens that allow activity in Microsoft 365 services within the victim’s permissions. Microsoft recommends controlling device code flow through Conditional Access and allowing it only where it is genuinely required. Sources: authentication flows and blocking authentication flows.

An Important Distinction

Device code phishing is not a technical “break” of MFA. The employee completes authentication correctly but is socially engineered into authorizing an access flow initiated by the attacker.

Operationally, this matters because the issue is not simply a weak password. It is the combination of social engineering, overly broad identity settings, and insufficient monitoring of unusual authentication events.

How AiTM Session Hijacking Works

In an AiTM phishing attack, the attacker uses a website that imitates the Microsoft 365 sign-in process and relays communication to the real service in real time. The user may enter a password, complete MFA, and access their account normally — while the attacker captures the results of that authenticated session.

The attacker’s most valuable target may not be the password itself. It can be a live session token or cookie that proves the user has already authenticated. This may allow the attacker to continue accessing services without asking the victim for another MFA code.

A compromised Microsoft 365 mailbox can then be used to:

Send phishing emails from a trusted corporate address
Impersonate an employee in conversations with customers and suppliers
Access invoices, partner details, and business documents
Create mailbox forwarding rules to external addresses
Change payment details or support business email compromise fraud
Spread the attack inside the organization and across its partner network

What Companies Should Implement

Effective protection is not a single setting. It is a combination of technical controls, identity policies, monitoring, and a clear incident-response process.

Restrict Device Code Flow.
If the company does not use device code flow, it should consider blocking it through Microsoft Entra ID Conditional Access. Microsoft documents a policy that can target users, all resources, and the Authentication Flows → Device code flow condition, with Block access as the grant action. The policy should first run in report-only mode to assess operational impact. Source: blocking authentication flows in Conditional Access. If device code flow is needed for particular devices or workflows, access should be restricted to clearly defined groups, network locations, and use cases. Microsoft recommends allowing the flow only where necessary.
Deploy Phishing-Resistant MFA.
SMS, TOTP application codes, and push approvals remain useful controls, but they can be exposed to social engineering or sign-in proxying. For privileged accounts, finance teams, administrators, and users with access to sensitive data, companies should prioritize phishing-resistant methods such as FIDO2 security keys, passkeys, or Windows Hello for Business. Microsoft provides dedicated deployment guidance for phishing-resistant, passwordless authentication in Microsoft Entra ID.
Monitor Unusual Sign-Ins and OAuth Consent.
Internal IT teams or a cybersecurity provider should regularly review:
- Sign-ins from unusual countries, IP addresses, or devices
- Unexpected device code flow activity
- Newly added OAuth applications and user consents
- Mailbox-rule changes, forwarding rules, and delegation settings
- User-risk and sign-in-risk alerts
- Privileged-account activity and access to administrative portals
Microsoft notes that sign-in-risk policies can automate actions such as blocking access or requiring reauthentication. Source: configuring risk policies in Microsoft Entra ID Protection.
Limit Privileges and Improve Email Hygiene.
Organizations should minimize the number of global administrators, apply least privilege, and regularly review administrative roles. Legacy authentication should be disabled where it is not required, because it does not support modern MFA and Conditional Access controls. Source: Microsoft Learn — risk policies in ID Protection. Identity security should also be supported by strong domain and email hygiene. SPF, DKIM, and DMARC help reduce domain impersonation, although they cannot stop phishing sent from an already compromised company mailbox.

What to Do After Suspected Account Compromise

A password reset alone may not be enough. The right response depends on the incident, Microsoft Entra ID settings, and the type of session or token obtained by the attacker.

In practice, the organization should quickly:

Block or secure the user account under its incident-response procedure.
Reset the password and force reauthentication.
Revoke active sessions and investigate tokens and OAuth applications.
Review mailbox rules, automatic forwarding, and delegated access.
Verify sign-in history, locations, devices, and file-access activity.
Revoke unauthorized application consents and remove suspicious device registrations.
Check whether phishing emails were sent to employees, customers, or suppliers.
Document the incident and implement controls that reduce recurrence.

Expert Perspective from CHORS.NET

“For Microsoft 365 security, the essential question is not only: does the company use MFA? It is also: which authentication flows are permitted, who can approve applications, where session tokens go, and whether the organization can detect unusual activity quickly.”

— Marcin Białczyk, Founder and Cybersecurity Operator at CHORS.NET

How CHORS.NET Helps Reduce Risk

CHORS.NET helps B2B organizations strengthen their security foundations by reviewing visible domain exposure, email configuration, publicly accessible risks, and remediation priorities. Its Internet Exposure Screening covers areas including domains, DNS, email, TLS, headers, and basic misconfigurations.

When screening identifies broader risk, or when a company needs a deeper review of a selected domain, application, or website, the next step is an Authorized Vulnerability Assessment. This service provides authorized technical analysis, configuration review, and a prioritized remediation report.

An external exposure screening does not replace Microsoft Entra ID log analysis or a tenant-configuration review. However, it can reveal domain, email, and public attack-surface weaknesses that make phishing campaigns more effective.

Frequently asked questions

Does MFA protect Microsoft 365 against phishing?

MFA significantly reduces the risk of account takeover after password theft, but it does not provide complete protection against AiTM phishing or device code phishing. In these attacks, an attacker may persuade the user to complete legitimate authentication or may capture the output of an authenticated session.

Should we disable device code flow in Microsoft 365?

If an organization has no justified need for device code flow, it should consider blocking it with Conditional Access. Microsoft recommends blocking this flow wherever possible and limiting it to controlled exceptions when it is required. Sources: authentication flows and blocking authentication flows.

Is a password reset enough after a mailbox compromise?

Not always. After suspected compromise, the organization should also review active sessions, tokens, OAuth consent, mailbox rules, forwarding settings, and sign-in activity. The response scope should be based on the investigation of the specific incident.

Which accounts should receive FIDO2 keys or passkeys first?

Prioritize administrative accounts, finance users, executive leadership, HR, employees serving strategic customers, and users with access to sensitive data or administration portals.

Does DMARC stop phishing from a compromised company mailbox?

No. SPF, DKIM, and DMARC reduce domain impersonation, but messages sent from a genuinely compromised mailbox can still pass these checks. That is why identity protections, monitoring, and incident response are also necessary.

Check Your Company’s Exposure

If you want to determine whether your domain and email setup could make phishing easier, begin with a review of your public exposure. CHORS.NET provides Internet Exposure Screening and Authorized Vulnerability Assessments to identify remediation priorities in a format understandable to both leadership and IT teams.

Request an Authorized Vulnerability Assessment →

Precyzyjna wiedza
o ciemnych systemach.