How to block device code phishing in Microsoft 365 (Entra ID)
Identity security · 6-min read · Find end-of-life software → · updated August 2026
An attacker can read your email with no password and without tripping MFA — the FBI and IC3 have warned on it. It’s called device code phishing, and it works because nothing in the flow is fake: every request hits genuine Microsoft infrastructure, and your successful MFA is what hands over the keys. The good news: one Conditional Access policy shuts it down.
How the attack works
- The attacker starts a device-code sign-in and gets a real Microsoft code.
- They email it to you and ask you to enter it on the real Microsoft page.
- You enter it and complete your own MFA — authorising their device.
- They walk off with your Outlook, Teams and OneDrive tokens. No password, no second prompt, nothing to alert on.
How to stop it — the runbook
In device code phishing, the attacker starts a real device-code sign-in, then emails you a genuine Microsoft code and asks you to enter it on the real Microsoft page. You pass your own MFA — and authorise the attacker's device. They walk off with your Outlook/Teams/OneDrive tokens. No password, no second prompt, nothing fake to alert on.
Create the Conditional Access policy in report-only mode and watch your sign-in logs for legitimate device-code use — kiosks, smart TVs and old CLI tools rely on this flow. Find and migrate them before you enforce, so you don't break anything.
Create a CA policy with the Authentication flows condition (now generally available) and block both "Device code flow" and "Authentication transfer". That's the two checkboxes that shut the technique down at the protocol level.
Exempt your emergency access (break-glass) accounts from the policy so a misconfiguration can never lock you out of your own tenant. This applies to every blocking CA policy.
Blocking stops NEW sign-ins; it does not kill a token an attacker already holds. If an account is compromised, revoke its sessions — a password reset alone won't cut it. Revoke-MgUserSignInSession -UserId user@example.com invalidates refresh tokens and forces re-auth, killing the stolen token.
The policy at a glance
| Setting | Value |
|---|---|
| Policy type | Conditional Access — Authentication flows condition (generally available) |
| Block | Device code flow + Authentication transfer |
| Grant | Block access |
| Roll out as | Report-only first → review sign-in logs → enforce |
| Always exclude | Break-glass / emergency-access accounts |
| If compromised | Revoke-MgUserSignInSession -UserId user@example.com |
Turn this into action. Device code phishing walks straight past MFA — nothing is fake, so nothing alerts. Stop it with one Conditional Access policy: what the attack is, the two checkboxes that block it, and what to do if an account is already compromised.
Find end-of-life software — free →Frequently asked questions
What is device code phishing?
A phishing technique that abuses the OAuth device authorization grant (device code flow). The attacker initiates a sign-in, sends the victim a legitimate Microsoft device code, and tricks them into entering it on the real Microsoft page. The victim completes their own MFA and unknowingly authorises the attacker's device — handing over access tokens without a password.
Why doesn't MFA stop it?
Because nothing is fake. Every request hits genuine Microsoft infrastructure and the victim completes a real, successful MFA challenge. The MFA itself is what authorises the attacker's device — so MFA passing is the problem, not the protection. That is why it walks straight past it.
How do I block device code flow?
With a single Conditional Access policy using the Authentication flows condition (generally available in Entra ID): block "Device code flow" and "Authentication transfer". Roll it out in report-only mode first, exclude break-glass accounts, then enforce.
Will blocking it break anything?
It can. Kiosks, smart-display devices and older CLI tools legitimately use device code flow. Run the policy in report-only first and review your sign-in logs to find those cases, then migrate or scope an exception for them before you enforce the block.
Does blocking the flow kick out an attacker who already has tokens?
No. The block only stops new sign-ins via that flow — it does not revoke tokens already issued. If an account is already compromised, revoke its sessions with Revoke-MgUserSignInSession (which invalidates refresh tokens and forces re-authentication). A password reset on its own does not invalidate an existing stolen token.
Is this a CVE or a patch?
Neither. Device code flow is a legitimate, by-design authentication feature — there is no software bug to patch. It is mitigated by configuration (a Conditional Access policy), not by upgrading. The related cleanup is retiring legacy/end-of-life tooling that still depends on the flow.
This guide is vendor-neutral and informational, grounded in publicly-available guidance from bodies such as OWASP, NIST and CISA. IsItPatched is independent and not affiliated with them, and this is not legal or compliance advice. See our disclaimer.