What is device code phishing, and how do you stop it in Microsoft 365?

Device code phishing doesn't need a fake login page. The attacker sends the victim to Microsoft's real sign-in site, the victim types a short code and approves their own MFA prompt, and the attacker walks away with a working session. Passwords, MFA and a careful look at the URL all check out, which is why the technique has spread fast.

This guide explains how it works, why MFA doesn't stop it, how to block it in Microsoft 365 and what to do if someone has already entered a code.

What is device code phishing?

Device code phishing is an attack that abuses the OAuth device code flow to get a victim to sign an attacker's session into their Microsoft 365 account. Microsoft's threat researchers describe it simply: "threat actors exploit the device code authentication flow" (Microsoft Threat Intelligence).

The device code flow is a legitimate standard, the OAuth 2.0 device authorization grant in RFC 8628. It lets devices without a keyboard or browser, "such as a smart TV, IoT device, or a printer", sign in. The device shows a short code, you open a browser on your phone or PC, enter the code and sign in, and then "the device is able to get access tokens and refresh tokens as needed" (Microsoft Learn).

In the attack, the "device" is the attacker's script. Microsoft's Entra documentation calls device code flow "a high-risk authentication method that can be part of a phishing attack" (Microsoft Learn).

How does a device code phishing attack work?

Microsoft's September 2026 analysis of the EvilTokens phishing kit lays out the steps (Microsoft Threat Intelligence):

1. The lure. An email contains a link, a PDF or an HTML attachment about something routine: a shared file, a voicemail, an invoice, a request for proposal.
2. The landing page. The link opens a page that may show a fake CAPTCHA, then asks Microsoft for a fresh device code in the background and displays it with Copy Code and Continue with Microsoft buttons.
3. The real Microsoft page. The victim is sent to microsoft.com/devicelogin, pastes the code and signs in with their password and MFA.
4. The token grab. The attacker's script polls Microsoft every few seconds. Once the victim finishes, Microsoft issues access and refresh tokens to the attacker's session.

Here's an example of the kind of lure involved. It's illustrative, not a captured sample:

Subject: Action required: confirm your mailbox password expiry
From: IT Service Desk <it-support@helpdesk-notice.example>

Your password expires today. To keep access, verify your account.
Your secure verification code: KX7P-QT9M
Go to microsoft.com/devicelogin and enter the code within 15 minutes.

The 15 minutes isn't arbitrary. Microsoft's documentation says the user has "15 minutes to sign in" after a code is requested. Earlier campaigns sent codes inside emails and raced that clock. Modern kits generate a live code only when the victim opens the page.

What attackers do next

Once inside, the attacker uses Microsoft Graph, the API behind Microsoft 365. In the 2025 Storm-2372 campaign, Microsoft saw keyword searches of mail for words "such as username, password, admin" and exfiltration of the results (Microsoft Threat Intelligence). In the EvilTokens cases, Microsoft reports that "within 10 minutes of the breach, threat actors registered new devices" to generate a Primary Refresh Token, a long-lived credential for persistence. Attackers also created malicious inbox rules for email exfiltration and persistence, setting up business email compromise.

Why doesn't MFA stop device code phishing?

MFA doesn't stop device code phishing because the victim completes MFA themselves, on Microsoft's real site, for the attacker's session. The Cloud Security Alliance puts it this way: "The attack does not defeat MFA; it redirects it" (Cloud Security Alliance).

It also explains why the domain check built into phishing-resistant methods such as passkeys doesn't catch it on its own. Those methods block fake sites by checking the domain, but this flow "routes authentication through the legitimate Microsoft domain, so no RP mismatch exists for the authenticator to observe." The CSA says they help only when Conditional Access combines them with device-compliance or network-based controls. Compare it with other techniques:

The other guides in that table cover their attacks in depth. For the general look-alike page, see fake Microsoft login phishing.

How common is device code phishing?

It moved from a niche technique to a commodity service. At the time of writing (October 2026):

• February 2025: Microsoft reported Storm-2372 using fake Microsoft Teams meeting invitations that asked targets to enter a device code. In a July 2026 update, Microsoft assessed Storm-2372 as "an initial access operations sub-cluster of Midnight Blizzard."
• February 2026: the EvilTokens phishing-as-a-service kit emerged. By September 2026, Microsoft said it had "compromised more than 12,000 inboxes in over 10,000 organizations worldwide." Microsoft's Digital Crimes Unit helped disrupt its infrastructure.

Microsoft lists 44 lure themes in the kit, from invoices and requests for proposals to shared files, voicemail and eFax. Our guides to voicemail phishing and fake e-signature requests cover two of the most common.

How do you block device code flow in Microsoft 365?

Microsoft recommends "blocking device code flow wherever possible." You have two ways to do it:

Security defaults also require MFA registration and block legacy authentication (Microsoft Learn). To check them, go to Entra ID > Overview > Properties > Manage security defaults in the Microsoft Entra admin center. Microsoft says organizations that replace them with Conditional Access policies must disable security defaults.

Create the Conditional Access policy

From Microsoft's procedure (Microsoft Learn):

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Go to Entra ID > Conditional Access > Policies and select New policy.
3. Under Users or workload identities, include All users. Exclude your emergency access (break-glass) accounts.
4. Under Target resources > Resources (formerly cloud apps), include All resources (formerly 'All cloud apps').
5. Under Conditions > Authentication Flows, set Configure to Yes, select Device code flow and select Done.
6. Under Access controls > Grant, select Block access.
7. Set Enable policy to Report-only and select Create.
8. After reviewing the report-only results, switch the policy to On.

Two catches. If you use device code flow to register devices and target all resources, Microsoft says to exclude the Device Registration Service resource from the policy. And blocks apply to "protocol tracked" sessions, so a session first opened with device code flow can be blocked later even when it uses another flow. That's by design.

How do you find out who uses device code flow today?

Before you switch the block on, check what would break. In the Microsoft Entra admin center, open the sign-in logs and filter by Authentication Protocol: Device code. Microsoft suggests this filter, or a report-only policy, "to understand if and how device code flow is used in your organization."

Legitimate uses are usually shared devices without keyboards and some command-line tools. If you find one, allow it narrowly. Microsoft's example is blocking device code flow "everywhere except for Android devices in a specific network location." Any device code sign-in by an ordinary office user, from an unusual location, deserves a closer look.

What should you do if a user entered a code?

Treat it as a compromised account, even if the user can't remember approving anything.

1. Disable the account. In the Entra admin center, go to Entra ID > Users > All users, select the user, clear Account enabled and save.
2. Revoke sessions. On the user's Overview page, select Revoke sessions, or run Revoke-MgUserSignInSession -UserId <id> in Microsoft Graph PowerShell (Microsoft Learn). Microsoft notes that access tokens "last for 1 hour" by default, so an attacker's existing token can keep working for up to an hour after you revoke sessions. That's why disabling the account comes first.
3. Remove attacker devices. Check the user's registered devices for anything new and disable it.
4. Check the mailbox. Look for new inbox rules, forwarding and sent mail you don't recognize. Our compromised account checklist has the commands.
5. Find other recipients. Search for the lure in other mailboxes and remove it. Message trace shows who received it.
6. Re-enable, then block. Reset the password, re-enable the account and put the device code flow block in place so it can't happen again.

A password reset alone isn't enough. The Cloud Security Alliance notes that a stolen refresh token "remains valid for its full window unless explicitly revoked."

How do you teach users to spot it?

Keep it to one rule: never enter a code that someone else gave you. A code at microsoft.com/devicelogin should only ever come from a screen in front of you, such as a TV or conference room device you're setting up. Codes in emails, chat messages, PDFs or web pages are always suspicious, whatever the reason given.

Other signals: urgency about an expiring password or mailbox, a "verification code" to read a document, a Teams meeting ID you're told to enter on a Microsoft page, and buttons labelled Copy Code. If someone already entered a code, they should report it immediately; see what to do after clicking a phishing link.

Next steps

1. Filter your sign-in logs for the Device code authentication protocol to see current use.
2. Turn on security defaults, or create the Conditional Access block in report-only mode, then enforce it.
3. Add "never enter a code someone sent you" to your security awareness training.
4. Write the revoke-sessions steps into your incident response plan.
5. Fewer lures reaching inboxes means fewer chances to enter a code. See how iBlockSpam filters phishing before it reaches Microsoft 365.

Browse our other phishing and threat guides.