Device code phishing on Microsoft 365, explained

Device code phishing tricks someone into typing a short code into Microsoft's genuine sign-in page, and the attacker walks away with a working session even though your staff member passed multi-factor authentication correctly.

There is no fake website in this attack. That is what makes it worth ten minutes of your attention.

Microsoft Threat Intelligence published the campaign that put this technique in front of ordinary businesses in February 2025, tracking the actor as Storm-2372 and describing lures that imitated Microsoft Teams meeting invitations. Microsoft updated that post on February 14, 2025 and again on July 31, 2026.

How the attack works

The device code sign-in flow exists for devices that cannot show a sign-in page: a smart TV, a conference room display, a tool that only runs in a terminal. The device shows a short code, you type the code on your phone or laptop, and the device gets signed in.

The attack borrows that flow, in four steps.

1. A message arrives with a reason to enter a code. In the campaign Microsoft described, the lure was a meeting invitation, built after some rapport over WhatsApp, Signal or Teams. The message supplies the code and the link.
2. The code goes into Microsoft's real page. Microsoft's words: the attacker "generates a legitimate device code request and tricks the target into entering it into a legitimate sign-in page". The address bar is correct, the certificate is correct, and the page is genuinely Microsoft's, because it is.
3. Your staff member passes their own MFA. They are the real account holder, signing in to the real service, so the prompt is approved and nothing looks wrong.
4. The attacker's session collects the tokens. The sign-in completes against the request the attacker started, so the access and refresh tokens land in the attacker's hands. Microsoft notes the attacker can then reach other services the account can reach, including email, without ever needing the password, and keeps that access for as long as the tokens stay valid.

In its February 14, 2025 update, Microsoft described the same actor going one step further: using the Microsoft Authentication Broker client to register an attacker-controlled device in Entra ID and obtain a Primary Refresh Token, which is a much more durable foothold than a single session.

Why this is not the same as the fake sign-in page

We have written about the attack where a proxy sits in front of a fake sign-in page and steals the session cookie. The advice there is passkeys, because a passkey is bound to the real site and will not sign you in to a copy.

Device code phishing is different in one specific way: there is no copy. The page is Microsoft's own, the sign-in really is yours, and the thing that goes wrong is that it authorises a session you did not start. A factor that proves the site is real cannot help when the site is real.

That is not a reason to skip phishing-resistant MFA. Microsoft's guidance in the same post still recommends MFA as an essential pillar of identity security and points to phishing-resistant methods such as FIDO tokens and passkeys. It stops the attacks it was built to stop. This is simply not one of them, and the control that addresses this one is a policy, not a factor.

The fix: block the device code flow

Microsoft's own recommendation is blunt. On the page covering this policy, Microsoft writes: "We recommend organizations get as close as possible to a unilateral block on device code flow."

The policy lives in Conditional Access, and Microsoft's documented steps (last updated April 7, 2026) are:

1. In the Microsoft Entra admin center, go to Entra ID, then Conditional Access, then Policies, and select New policy.
2. Under Assignments, include the users you want covered. Microsoft recommends all users.
3. Under Exclude, select your emergency access or break-glass accounts. Microsoft says to audit that exclusion list regularly.
4. Under Target resources, include all resources.
5. Under Conditions, then Authentication Flows, set Configure to Yes and select Device code flow.
6. Under Access controls, then Grant, select Block access.
7. Set Enable policy to Report-only, create it, and move it to On once you have reviewed the results.

Report-only first is not optional caution. It is how you find the one person in the office who signs in to a conference room display this way before you lock them out of it.

This is also a benchmark control, not just a vendor recommendation. The CIS Microsoft 365 Foundations Benchmark lists it as 5.2.2.12 (L1) Ensure the device code sign-in flow is blocked, with the same steps and the same note about excluding break-glass accounts.

The license question, answered plainly

Conditional Access requires Microsoft Entra ID P1. Microsoft states it directly on the Conditional Access overview: "Using this feature requires Microsoft Entra ID P1 licenses", and adds that "Customers with Microsoft 365 Business Premium licenses can also use Conditional Access features."

So if your firm is on Business Premium, you already have what you need. If you are on Business Standard or Business Basic, you do not, and no amount of clicking will produce this policy. Microsoft's Security Defaults are available to everyone, but we have not found a Microsoft source saying Security Defaults block the device code flow, so we are not going to tell you they do. If that is your situation, the honest options are to watch the sign-in logs as described below, or to add Entra ID P1 for the people who matter most.

How to see whether anyone uses it today

Before you block anything, look. Microsoft's authentication flows documentation (last updated March 24, 2026) describes device code flow as "a high-risk authentication method that can be part of a phishing attack", and says that "filtering the sign-in logs for device code flow events with the authentication protocol filter can help" before you restrict it.

In practice: open the Microsoft Entra sign-in logs, add the Authentication Protocol filter, and select Device code. In most small offices the result is an empty list, which is the easiest version of this decision you will ever make.

If someone has already typed in a code

Treat it as a compromised account, not a near miss. The tokens are already issued.

• Revoke the sessions. Microsoft's guidance is to revoke the user's refresh tokens, which invalidates what the attacker is holding, and to consider a Conditional Access policy that forces re-authentication.
• Look for a device registered around the same time. This is the step people skip. Microsoft's February 14, 2025 update describes the attacker registering their own device to obtain a Primary Refresh Token, so a new device enrollment minutes after the sign-in is a finding, not a coincidence.
• Read the mailbox rules. Forwarding rules, rules that delete on receipt, and rules that hide messages mentioning invoices or payments are the standard next move after an account takeover.
• Reset the password and re-enroll MFA once the sessions are gone, in that order, so the attacker does not simply continue on an old token.

If nobody in your firm is watching for the stolen session, revoking it is a job that starts whenever someone happens to notice. That is the gap Managed ITDR is for: Huntress's security operations center watches Microsoft 365 and Google Workspace sign-ins around the clock and can revoke a confirmed stolen session, and Obsidian Ridge picks up everything after containment within one business day.

Why identity is where this lands

Huntress, whose platform we operate, reported on June 30, 2026 that over the past year "identity-based attacks accounted for 79% of all critical and high-severity incidents" it responded to. Device code phishing is one route into that number, and it is one of the few with a single setting behind it.

The short version

1. Device code phishing uses Microsoft's real sign-in page, so MFA is passed, not bypassed.
2. Block the device code flow in Conditional Access, starting in report-only mode, excluding break-glass accounts.
3. Conditional Access needs Entra ID P1, which Microsoft 365 Business Premium includes.
4. Check the sign-in logs with the Authentication Protocol filter before you block, and after.
5. If someone entered a code, revoke the sessions, check for a newly registered device, and read the mailbox rules.

Ridge Core includes Managed ITDR on Microsoft 365 or Google Workspace, which is the part that watches for a stolen session and gets it revoked. If you would like someone to look at how your own tenant is configured before anything goes wrong, that is what the free review is for.