Device Code Phishing: what it is and how the attack on Microsoft Entra ID works

Attackers increasingly don’t need your password. It’s enough that they get you to type a few-digit code into the genuine Microsoft sign-in page — and the token that authorizes acting on your behalf lands on their device. This is the essence of Device Code Phishing, a technique that has grown markedly in recent months and is being actively tracked by threat intelligence teams.

This article explains what the attack is, how the OAuth2 flow it abuses works, and why it can bypass both the password and multi-factor authentication. If you’re looking for a concrete defensive configuration, jump to the guide: blocking the Device Code Flow in Microsoft Entra ID with Conditional Access.

What Device Code Phishing is

Device Code Phishing is a social-engineering attack that abuses the OAuth2 authorization flow known as the Device Code Flow (Device Authorization Grant). This flow is implemented in, among others, the Microsoft / Entra ID ecosystem and is used to sign in on devices that have no convenient way to enter data or to run a full browser.

Unlike classic phishing, which serves up a fake sign-in page, Device Code Phishing sends the victim to a genuine Microsoft URL. There is no spoofed domain or suspicious certificate that would be easy to catch — the victim signs in exactly where they should. That is precisely what makes the attack so effective.

How the OAuth2 Device Code Flow works

The Device Code Flow was designed for input-constrained devices: smart TVs, consoles, IoT devices and CLI tools run on systems without a browser. Instead of signing in on the device itself, the user moves the process to another device equipped with a browser.

The standard sequence looks like this:

1. The app or device asks the authorization service for a code (a device code and a shorter user code).
2. The device shows the user the code and a verification URL (in the Microsoft ecosystem usually https://microsoft.com/devicelogin).
3. On another device with a browser, the user goes to the indicated URL, enters the code, and completes authentication and consent.
4. The original device, polling the token endpoint in the background, receives an access token (and a refresh token) and continues working.

It’s a convenient mechanism wherever entering a username and password on the device itself would be cumbersome or impossible. You’ll find more about the standard itself in our overview of how OAuth works.

Anatomy of the attack

In a Device Code Phishing attack the roles are reversed: the code does not originate from your device, but from the attacker.

1. The attacker initiates the Device Code Flow for a chosen application (client) in Entra ID and receives a code and a verification URL from the authorization service.
2. The attacker passes that code to the victim together with the microsoft.com/devicelogin URL — most often by email, chat or messenger, under a pretext (“finish the setup”, “verify access”, “activate the conference device”).
3. Trusting the genuine Microsoft URL, the victim goes to the page and enters the supplied code.
4. If the victim completes the procedure, the attacker’s device receives a token that grants access to resources on the user’s behalf.

The crucial point is that the victim carries out the entire sign-in on their side — on genuine Microsoft infrastructure, with their own credentials and their own second factor. The attacker merely “hooks into” that process via a code generated earlier.

Why the attack is so dangerous

The password and MFA are performed by the victim

By “completing the procedure” we mean, in theory, the normal sign-in — entering a username and password and, if required, passing MFA. This means the attacker needs neither your password nor your second factor. The authentication is performed by the victim, and the attack captures the token issued after it succeeds. To Entra ID the whole event looks like a legitimate user sign-in.

An active session and prior consent hide the attack

In practice the victim’s browser often already has an active sign-in session, and consent to the app may have been granted earlier. In such cases credentials are not requested again, and the operation can succeed without the user’s conscious participation — the victim enters the code, sees a brief message, and does not notice that they have just authorized someone else’s device.

Tokens grant persistent access

As a result of the attack, the adversary receives an access token and often a refresh token as well, which lets them maintain access over an extended period without signing in again. This brings the consequences of Device Code Phishing close to session hijacking: the attacker operates within the victim’s permissions, and classic password-centric defenses (such as forcing a password reset) are not enough on their own to cut off access.

That is why we treat Device Code Phishing as a real and growing threat — how easily this flow can be abused is disproportionately high relative to how rarely it is actually needed in many organizations.

Warning signs and detection

On the user side, the following should raise suspicion:

• an unexpected request to enter a code at microsoft.com/devicelogin that you did not initiate on any of your devices;
• time pressure and a pretext context (“do it now or you’ll lose access”);
• a request concerning a sign-in on a device that does not actually exist in your environment (e.g. a “conference device” you aren’t configuring).

On the administrator side, it’s worth monitoring in the Entra ID sign-in logs:

• authentication events with a device code flow type — especially for applications where the flow is not used in the organization;
• device code sign-ins from unusual locations, IP addresses or anonymizing networks;
• correlation: a code generated in one context, with the token collected from an entirely different one.

Anti-phishing hygiene principles remain valid — if you want to refresh the basics, see the article on what phishing is and how to protect yourself and the overview of how multi-factor authentication (MFA) works.

When the Device Code Flow is needed at all

It’s worth asking a basic question: does your organization actually use the Device Code Flow? The flow makes sense for browserless devices — smart TVs, consoles, IoT, some CLI tools. In many corporate environments it is unnecessary, and if so, it represents an attack surface you can deliberately restrict or disable.

The good news is that Microsoft allows you — through Conditional Access options and related policies in Entra ID — to disable or limit the use of the Device Code Flow, or to confine it to controlled scenarios, thereby reducing the attack surface.

What’s next

Understanding the mechanism is the first step. The second is a concrete defensive action: disabling the flow where it isn’t needed, or restricting it to managed/compliant devices and selected groups. We describe the full, step-by-step configuration in the guide: blocking the Device Code Flow in Microsoft Entra ID with Conditional Access.

The descriptions above are educational. Before making changes in a production tenant, verify the impact of the configuration on your own scenarios and privileged accounts. If you need support assessing the risk and rolling out identity policies, the nFlo team can help you select and test the right safeguards.

Sources and reference materials

• Microsoft Learn — OAuth 2.0 device authorization grant flow
• Microsoft Learn — Conditional Access: authentication flows
• Microsoft Learn — Block authentication flows with Conditional Access policy