Device Code Phishing: The MFA-Protected Sign-In That Still Hands Attackers a Session

Most phishing advice starts with the same rule: check the URL before you sign in. Device code phishing is dangerous because the final sign-in page really is Microsoft's.

The attacker does not need to clone the Microsoft login screen, steal a password, intercept a one-time code, or proxy a passkey ceremony. They start a legitimate OAuth device code flow, hand the resulting code to the victim, and persuade the victim to complete the sign-in at microsoft.com/devicelogin. Microsoft accepts the authentication and the attacker's waiting client receives the tokens.

That is why calling this an “MFA bypass” can be misleading. MFA works. The user satisfies it. The problem is that they are authenticating the wrong session.

Recent research shows this is no longer a niche red-team technique. Lexfo reconstructed a device code campaign that ran for more than a year and recorded 218 confirmed victims across 12 countries. Roughly 94% were corporate accounts. Microsoft has separately documented automated campaigns that generate fresh codes on demand, copy them to the victim's clipboard, and poll for success in real time.

The most effective control is not another MFA method. It is a Conditional Access policy that blocks device code flow wherever it is not genuinely required.

How the Attack Works

The legitimate device authorization grant exists for devices that cannot offer a normal browser-based sign-in experience: smart TVs, shared displays, command-line tools, and some meeting-room hardware.

A normal flow looks like this:

1. A device requests a code from Microsoft.
2. The device shows that code to its user.
3. The user visits Microsoft's device login page on another device.
4. The user authenticates and approves the request.
5. The original device polls Microsoft and receives tokens.

The phishing version changes only the first device. The attacker starts the request, then uses an email, Teams message, fake document notification, or phone call to convince the victim that the code belongs to something they are trying to open.

The phishing site may be fake, but the code is real and the Microsoft page is real. Modern kits generate the code only after the victim arrives, preserving its full 15-minute lifetime. Some copy it directly to the clipboard and poll every few seconds so the operator knows the moment authentication succeeds.

Why MFA and Passkeys Do Not Solve This Particular Problem

Passkeys are still one of the best defences against credential phishing and adversary-in-the-middle proxy kits. Their origin binding prevents a fake domain from asking an authenticator to complete a ceremony for microsoft.com.

Device code phishing takes a different route. The victim is sent to the real Microsoft origin. Their passkey correctly verifies Microsoft, and Microsoft correctly verifies the user. The failure is contextual: the user has approved a device authorization request initiated by the attacker.

So passkeys have not failed, and this is not an argument against deploying them. They close an enormous class of phishing attacks. They simply do not express the question that matters here: “Did you initiate the device that is waiting for this token?”

The same applies to push MFA and number matching. If the user has been convinced that the request is legitimate, completing a stronger challenge still completes the attacker's authorization flow.

What the Attacker Gets

After the victim approves the request, the attacker can receive access and refresh tokens for the requested client and resources. Microsoft has observed post-compromise activity including mailbox searches, email collection through Microsoft Graph, lateral phishing from the compromised account, malicious inbox rules, and attacker-controlled device registration.

Lexfo's investigation found tokens configured for automatic refresh, with some refreshed as many as 25 times. That matters because the visible phishing moment may last only a few minutes while the resulting access persists much longer.

Password reset alone is not a sufficient response to a confirmed incident. You also need to revoke sign-in sessions and refresh tokens, investigate device registrations and inbox rules, and review activity performed through Microsoft Graph.

The Conditional Access Policy That Stops the Flow

Microsoft recommends getting as close as possible to a unilateral block on device code flow. For a tenant that does not use it, the target shape is straightforward:

Report-only is not optional ceremony. Device code flow is still legitimately used by some Teams Android devices, Teams phones, panels, shared displays, device-registration scenarios, and older command-line tooling. A broad block can turn a security improvement into an outage if you do not inventory those dependencies first.

Use Entra sign-in logs to filter for the Device code authentication protocol and inspect the Original transfer method field. Microsoft protocol-tracks sessions that began with device code flow, so later token refreshes can continue to match an authentication-flows policy even when the current event does not look like a fresh device code sign-in.

If legitimate use exists, scope the exception narrowly. A conference-room account on a known network location is a much better exception than allowing the flow for the entire workforce. Document every exception and give it an owner.

Harden device registration as well

The original Email Security Weekly write-up highlights a second control that is worth adding. Microsoft has observed device-code attackers using the Microsoft Authentication Broker client to request a token for Device Registration Service, register an attacker-controlled device in Entra ID, and obtain a Primary Refresh Token for longer-term access.

Blocking device code flow remains the primary prevention. As defence in depth, review Entra ID → Devices → Device settings: restrict which users may register or join devices, apply appropriate enrollment restrictions, and set the maximum number of devices per user to a value that reflects your real endpoint estate. Microsoft's default is 50. The newsletter recommends one or two, but that number is not universally safe for organisations where users legitimately have several managed endpoints. The important control is an intentional, supportable limit rather than an untouched default.

For detection, correlate device-code sign-ins with close-in-time device registrations, Primary Refresh Token activity, new authentication-method changes, malicious inbox rules, and unusual Microsoft Graph access. Any one signal can be legitimate; the sequence is what makes it high-confidence.

How AccessLens Helps Close the Gap

AccessLens does not sit in the authentication path and it does not replace Microsoft Entra Conditional Access. The Entra policy is what blocks the attack. AccessLens helps make sure that policy exists, has the intended scope, and can be enabled without discovering its side effects in production.

1. It detects the missing control

AccessLens Gap Analysis checks imported Conditional Access policies for an enabled block policy whose Authentication flows condition includes deviceCodeFlow. If no matching policy exists, it raises Block Device Code Authentication Flow as a gap and gives you the target policy shape.

That answers the first question quickly: is this tenant protected at all?

2. It exposes false confidence

A policy named “Block device code” is not proof. It may be disabled, left in report-only mode indefinitely, scoped to a small group, targeted at the wrong resources, or configured with exclusions that swallow most of the tenant.

AccessLens normalises the Graph policy data and shows the actual assignments, authentication-flow condition, grant control, state, and exclusions. The policy flow and matrix views make it easier to verify that the logic says what the display name claims.

3. It warns about the devices you could break

AccessLens also checks the other side of the change. Its Device Code Flow Blocks Teams Android Devices finding identifies broad device-code blocks that target all users and may affect Teams Android devices, phones, and panels.

That does not mean the block is wrong. It means you have a dependency to validate before enforcement. The right response is usually a tightly controlled exception for the specific resource accounts or trusted location—not abandoning the block for everyone.

4. It lets you model the flow before enforcement

In the What-If Simulator, select Device Code Flow as the authentication flow and test representative users, applications, locations, and device contexts. Use that alongside Microsoft's report-only results to check that ordinary users are blocked and approved scenarios behave as expected.

This gives you two complementary views: AccessLens explains the policy logic before deployment, while Entra report-only data shows what real sign-ins would have experienced.

5. It keeps the exception visible

The long-term risk is policy drift. A temporary exception becomes permanent, a new tool begins using device code flow, or somebody disables the policy during troubleshooting and never turns it back on.

Re-running Gap Analysis and reviewing the policy matrix makes those changes visible. The goal is not merely to create the policy once. It is to keep the protection true as the tenant changes.

A Practical Rollout

1. Inventory usage. Filter Entra sign-in logs for Device code and review Original transfer method. Identify the users, client applications, resources, locations, and hardware involved.
2. Import policies into AccessLens. Confirm whether GAP-096 reports a missing block and inspect any existing policy's real scope.
3. Build the block in report-only. Target all users and all resources, select Device code flow, and use Block access. Keep exclusions minimal and documented.
4. Test dependencies. Use AccessLens What-If for representative scenarios, review the Teams-device impact warning, and compare the result with Entra report-only events.
5. Enforce and monitor. Turn the policy on once expected use is accounted for. Alert on anomalous device-code authentication and correlate it with device registration, PRT activity, authentication-method changes, inbox rules, and post-authentication Graph activity.

If you confirm compromise, revoke the user's sessions and refresh tokens immediately. Then investigate mailbox rules, registered devices, OAuth activity, lateral messages, and data access. Do not stop at a password reset.

The Real Lesson

The Reddit discussion that prompted this article got the central point right: a user can follow the familiar advice, authenticate on Microsoft's real page, satisfy MFA, and still hand an attacker a valid session.

The defensive lesson is not that MFA or passkeys are useless. It is that authentication strength and authentication flow are separate controls. Passkeys answer who is signing in and protect the origin. Conditional Access decides whether this kind of sign-in should be allowed in the first place.

For most users, there is no reason to use device code flow. If your tenant leaves it open globally, you are carrying an authentication path that attackers can turn into a convincing phishing primitive. Find the path, test the dependencies, and close it.

Sources

• Reddit: Device-code phishing is beating MFA by walking users through Microsoft's real login page
• Email Security Weekly: Week 29 of 2026
• Lexfo: One Misconfigured Server, Three Active Campaigns
• Microsoft Security: Inside an AI-enabled device code phishing campaign
• Microsoft Security: Storm-2372 conducts device code phishing campaign
• Microsoft Learn: Conditional Access authentication flows
• Microsoft Learn: Block authentication flows with Conditional Access
• Microsoft Learn: Manage Microsoft Entra device settings