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

URL: https://iblockspam.com/blog/device-code-phishing-microsoft-365
Last updated: 2026-10-22
Published: 2026-10-22
Topic: Phishing & threats
Author: iBlockSpam Team

> Device code phishing tricks users into signing attackers in at microsoft.com/devicelogin. How it beats MFA, how to block device code flow and how to respond.

## Short answer

Device code phishing tricks a user into entering an attacker's code at the real microsoft.com/devicelogin page. The user signs in with their password and MFA, and Microsoft issues tokens to the attacker's session. Stop it by blocking device code flow with Conditional Access or security defaults, and revoke sessions, not just passwords, after an incident.

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](https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/)).

The **device code flow** is a legitimate standard, the OAuth 2.0 device authorization grant in [RFC 8628](https://www.rfc-editor.org/rfc/rfc8628). 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](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code)).

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](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows)).

## 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](https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/)):

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:

```text
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](https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/)). 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](https://iblockspam.com/blog/malicious-inbox-rules-auto-forwarding) for email exfiltration and persistence, setting up [business email compromise](https://iblockspam.com/blog/business-email-compromise-prevention).

## 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](https://labs.cloudsecurityalliance.org/research/csa-research-note-oauth-device-code-phishing-eviltokens-2026/)).

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:

| Technique | Where the victim signs in | What the attacker gets | Main defense |
|---|---|---|---|
| Fake login page | Attacker's look-alike site | Password, maybe an MFA code | MFA, user training |
| [Adversary-in-the-middle (AiTM)](https://iblockspam.com/blog/adversary-in-the-middle-phishing-mfa-bypass) | Attacker's proxy of the real site | Session cookie | Phishing-resistant MFA |
| [OAuth consent phishing](https://iblockspam.com/blog/oauth-consent-phishing-microsoft-365) | Real Microsoft site | Permissions for a malicious app | Restrict user consent |
| Device code phishing | Real `microsoft.com/devicelogin` | Access and refresh tokens | Block device code flow |

The other guides in that table cover their attacks in depth. For the general look-alike page, see [fake Microsoft login phishing](https://iblockspam.com/blog/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](https://iblockspam.com/blog/phishing-as-a-service-kits) 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](https://iblockspam.com/blog/voicemail-phishing-emails) and [fake e-signature requests](https://iblockspam.com/blog/fake-docusign-e-signature-phishing) 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:

| Option | License | Exceptions possible? | Notes |
|---|---|---|---|
| Security defaults | None | No, on or off | Block device code flow; Microsoft says all new tenants block it this way from July 1, 2026 |
| Conditional Access policy | At least Microsoft Entra ID P1 | Yes, by user, app, device or location | Start in report-only mode |

Security defaults also require MFA registration and block legacy authentication ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults)). 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](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows)):

1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) 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](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)). 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](https://iblockspam.com/blog/signs-email-account-compromised) has the commands.
5. **Find other recipients.** Search for the lure in other mailboxes and remove it. [Message trace](https://iblockspam.com/blog/microsoft-365-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](https://iblockspam.com/blog/what-to-do-after-clicking-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](https://iblockspam.com/platforms/microsoft-365).

Browse our other [phishing and threat guides](https://iblockspam.com/blog/topic/threats).

## Frequently asked questions

### Is microsoft.com/devicelogin a real Microsoft page?

Yes, and that's what makes this attack work. It's Microsoft's genuine page for signing in devices that have no keyboard or browser, such as a smart TV or conference room device. The page is safe; entering a code someone else gave you is not. Only enter a code that your own device is showing you right now.

### Does a password reset remove an attacker who used device code phishing?

Not on its own. The attacker holds tokens, not your password. Microsoft recommends revoking the user's refresh tokens and temporarily disabling the account, because existing access tokens can stay active for up to an hour after revocation. Also check for devices the attacker registered, which Microsoft observed within 10 minutes of a breach.

### Will blocking device code flow break Microsoft Teams Rooms or other shared devices?

It can, if those devices sign in with device code flow. Run the Conditional Access policy in report-only mode first and filter sign-in logs for the Device code authentication protocol. If a device type needs it, exclude only those accounts or locations. Microsoft's example allows Android conference room devices in one network location.

### Do I need Microsoft Entra ID P1 to block device code flow?

Not necessarily. Security defaults, which need no extra license, block device code flow, and from July 1, 2026 they do so on all new tenants. Conditional Access policies, which let you add exceptions, need at least Microsoft Entra ID P1. Choose one approach: Microsoft says organizations moving to Conditional Access must disable security defaults.

### How long is a Microsoft device code valid?

Fifteen minutes by default. Microsoft's identity platform documentation says the user has 15 minutes to sign in from the moment the code is requested. Phishing kits work around this by generating a fresh, live code when the victim opens the page, then polling every few seconds until the victim completes sign-in.

## Sources

- [Microsoft Learn: Authentication flows as a condition in Conditional Access policy](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows)
- [Microsoft Learn: Block authentication flows with Conditional Access policy](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows)
- [Microsoft Learn: Security defaults in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults)
- [Microsoft Learn: OAuth 2.0 device authorization grant](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code)
- [Microsoft Threat Intelligence: Unmasking EvilTokens, getting to the root of device code phishing (September 2026)](https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/)
- [Microsoft Threat Intelligence: Storm-2372 conducts device code phishing campaign (February 2025, updated)](https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/)
- [Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)
- [Cloud Security Alliance: EvilTokens, device-code phishing renders MFA irrelevant (May 2026)](https://labs.cloudsecurityalliance.org/research/csa-research-note-oauth-device-code-phishing-eviltokens-2026/)

## Free tools for this guide

- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.

---

Source: iBlockSpam, https://iblockspam.com/blog/device-code-phishing-microsoft-365 (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt