Microsoft 365 Device Code Phishing: Why MFA Is Not Enough

Device code phishing can give an attacker access to Microsoft 365 even when MFA is enforced. The attacker does not bypass or break MFA. They trick the user into completing authentication for a session the attacker initiated through Microsoft’s legitimate device login page.

Microsoft recently linked this technique to EvilTokens, a phishing-as-a-service platform associated with more than 12,000 compromised inboxes across over 10,000 organizations. Microsoft disrupted its infrastructure in September 2026, but the authentication flow it abused remains available in many existing tenants.

The user completes a real Microsoft sign-in

Device code flow is designed for devices with limited input, such as shared screens and some meeting-room equipment. A device displays a short code, and the user enters it in a browser on another device.

In a phishing attack, the criminal starts that flow and sends the code to the victim. The lure may look like a document, meeting invitation, or password notice. The victim reaches the real Microsoft sign-in page, enters the code, and completes the usual authentication steps, including MFA.

The resulting session belongs to the attacker.

Microsoft says EvilTokens used this access to search inboxes, map organizations, identify financial conversations, and create malicious inbox rules. Its AI features helped criminals move from account access to targeted fraud more quickly. Microsoft’s technical analysis of EvilTokens and disruption report describe the operation.

MFA alone does not close this path

MFA is still essential. It stops many attacks that begin with a stolen password. Device code phishing succeeds differently: the user authenticates a session initiated by someone else.

That distinction matters when reviewing a tenant. Confirming that MFA is registered or enforced does not prove that risky authentication flows are blocked. It is a separate access decision.

Microsoft recommends blocking device code flow wherever possible. Organizations that genuinely need it should limit the exception to documented devices or accounts rather than leaving the flow open tenant-wide.

Protection depends on the tenant and licence

Microsoft added device code blocking to Security Defaults for new Entra tenants from 1 July 2026. Existing tenants should not assume that enabling Security Defaults provides the same protection.

Granular control requires Conditional Access, which needs Microsoft Entra ID P1. Microsoft 365 Business Premium includes P1; Microsoft 365 Business Standard does not. A Business Standard tenant can use Security Defaults, but an existing tenant cannot create the dedicated Conditional Access policy without an additional licence.

For tenants with Conditional Access, credible evidence is an enabled policy that blocks device code flow for the intended users and resources. A policy in report-only mode records what would happen but does not stop the sign-in. Exclusions also need review because one broad exception can preserve the attack path.

Microsoft’s authentication-flow guidance recommends checking current usage in sign-in logs, testing the block in report-only mode, and then enforcing it.

Check the effective protection

PosturIQ assesses whether an enforced Conditional Access policy blocks device code flow across the tenant and highlights exclusions that need review. It also identifies when the current licence does not provide Conditional Access, so the limitation is visible rather than mistaken for a passing control.

The assessment is read-only. The administrator or MSP reviews legitimate use, applies the policy change, and runs another assessment to verify the result.

This is why MFA registration is not the same as enforcement, and why MFA enforcement is not the end of an identity review. A useful small business security posture audit checks the paths around the control as well as the control itself.