Device Code Flow — An Attack Vector That Bypasses MFA

Why This Topic Matters

In February 2025, Microsoft Threat Intelligence issued a warning: a Russia-linked threat group, Storm-2372, was using device code flow — Microsoft’s own legitimate authentication protocol — to compromise organizations.

This is not ordinary phishing. The victim doesn’t enter a password on a fake page — they authenticate themselves through the real Microsoft platform, pass MFA, and unknowingly hand the attacker a valid session. Antivirus doesn’t react because nothing malicious is executed.

In the second half of 2025, the technique spread from nation-state threat groups to common criminals. By early 2026, the situation has changed dramatically: according to Push Security data, device code flow phishing attacks have surged 37 times. The reason is simple — at least 11 phishing-as-a-service platforms have emerged on the market, offering this attack type as a ready-made solution. The largest of them, EvilTokens, appeared in February 2026 and has already hit over 340 organizations in five countries. The attacker no longer needs to be technical — they simply buy a service.

If your organization uses Microsoft 365, it’s worth thinking through this attack vector and closing it off.

How the Attack Works

Device code flow (RFC 8628) was created for devices without a keyboard: smart TVs, gaming consoles, IoT devices. The user opens a browser on their computer, enters a code at microsoft.com/devicelogin, and the device gains access to their account. A similar solution may be familiar to many from logging into YouTube through a smart TV.

The attacker uses the same mechanism — except the code isn’t requested by a smart TV, but by the attacker themselves.

A typical scenario:

The attacker contacts the victim via email, Teams message, WhatsApp, or Signal — often under someone familiar’s name.
The message contains an invitation to a meeting or shared document, along with a code.
The victim opens microsoft.com/devicelogin — Microsoft’s real page, not a fake.
The victim enters the code and completes MFA.
The attacker receives a valid access token and refresh token. The attacker no longer needs MFA.

Why does this work so well?

First — the victim interacts only with Microsoft’s own page throughout the entire authentication process. The certificate is correct, the URL is correct, the MFA prompt comes from the right application. There are no conventional warning signs for the user.

Second — the refresh token gives the attacker long-term access. By default, it’s valid for up to 90 days and allows access to the victim’s emails, SharePoint files, Teams conversations, and all connected applications — without the attacker needing to re-authenticate. After detecting the situation and responding, changing the password alone won’t help either, because the attacker has a token, not a password.

Protective Measures by Priority

1. Block Device Code Flow with a Conditional Access Policy

The most effective measure. Most organizations don’t need device code flow at all — if you don’t use keyboardless devices for sign-in, you can block it entirely.

In Conditional Access policies, you can disable device code flow under authentication flow conditions (Authentication Flows). The principle is simple: block for all users, exclude only break-glass accounts and those service accounts that genuinely need device code flow. Always start in report-only mode and monitor logs for at least 1–2 weeks before enforcing — this way you’ll see if the block affects anything important (see “Before Blocking: Map Existing Usage” below).

Detailed guide: Block authentication flows with Conditional Access policy (Microsoft Learn).

Check first whether Microsoft has already done this for you. Since late 2024, Microsoft has been automatically rolling out managed policies (Microsoft-managed policies), including “Block device code flow”. Check the Conditional Access policies list to see if any policy in the Created by column is from “Microsoft”. If so — it’s enough to review and enable the existing one; no need to create a new one. Read more: Microsoft-managed Conditional Access policies.

Note: Conditional Access requires an Entra ID P1 license. See the license overview below.

Prevent users from consenting to third-party applications on their own (admin consent required). Even if the attacker obtains a token, this blocks attacker-created applications from accessing organizational data.

3. Enable Risk-Based Blocking

Entra ID Identity Protection detects anomalies — sign-ins from unfamiliar locations, “impossible travel” patterns — and automatically blocks suspicious sessions.

Note: Identity Protection requires an Entra ID P2 license. See the license overview below.

4. Consider Phishing-Resistant MFA

FIDO2 hardware keys (e.g., YubiKey) or passkeys don’t directly block the device code flow attack, since the victim authenticates themselves. However, they do close other attack vectors that also bypass conventional MFA — adversary-in-the-middle and other token theft techniques.

5. Awareness

The simplest measure: a device code should only be entered by the person who initiated the process themselves. If someone sends a code with a request to enter it — that’s a red flag, regardless of the sender.

License Overview

A common question I hear: “Does our license even support this?”

Protective Measure	Required License	Price (approx.)
Conditional Access (block device code flow)	Entra ID P1 (included in M365 Business Premium)	~€6/user/month standalone
Identity Protection (risk-based blocking)	Entra ID P2	~€9/user/month standalone
Defender for Office 365 (advanced email filters)	M365 Business Premium	~€22/user/month in bundle
Basic MFA	All M365 licenses	€0

Practical recommendation: Business Basic and Standard licenses don’t include Conditional Access. Two approaches:

Upgrade all users to Business Premium — reasonable for up to ~300 users.
Purchase Entra ID P1 separately for highest-risk accounts — administrators, executives, accountants.

Before Blocking: Map Existing Usage

Don’t block blindly. First, determine whether your organization uses device code flow legitimately. Typical devices that need it:

Microsoft Teams Rooms devices (conference room screens and cameras)
Surface Hub tablets
Printers that require Microsoft 365 authentication (e.g., scan-to-email)
CLI tools like Azure CLI and Azure PowerShell (developers often use these)

How to check: open Entra ID sign-in logs and filter Authentication Protocol → Device code. Review the last 90 days of results — which users and applications have used it? In a Log Analytics workspace, the same result can be obtained with a KQL query, filtering by AuthenticationProtocol == "deviceCode".

If you find legitimate devices — create service accounts for them and add them to the Conditional Access policy exclusion list. Audit exclusions regularly.

Important nuance: Conditional Access tracks at the session level (protocol tracking). If a user signs in via device code flow and opens other applications within the same session, the block applies to those as well. If a service stops working after enabling the policy, check the Original transfer method column in sign-in logs.

How to Detect Potential Compromise

Entra ID sign-in logs — filter by “Device code” authentication protocol. In an enterprise context, every such entry deserves attention, especially if it originates from an unfamiliar IP address or location. Events flagged as “impossible travel” — for example, Tallinn at 9:00 AM, Moscow at 9:05 AM — are unambiguously suspicious.

OAuth application consents — check the Enterprise Applications list for applications that nobody has consciously authorized. Attackers often create an OAuth application that maintains access even after a password change.

Microsoft Purview Audit logs authentication events at the organizational level. The exact search filters change from time to time — always check Microsoft’s current documentation.

Responding to Compromise

Speed matters — the refresh token gives the attacker persistent access.

Revoke all user sessions — Entra ID → Users → Revoke sessions.
Remove suspicious OAuth application consents.
Change the password and force all sessions to end.
Map the blast radius — which emails, files, and messages were accessible?
Engage a specialist — assessing the blast radius and root cause analysis requires experience.

Summary

The device code flow attack exploits Microsoft’s own legitimate protocol and bypasses MFA because the victim authenticates themselves. The technique is easy to execute, hard to detect, and gives the attacker long-term access.

Three priorities:

Block device code flow with a Conditional Access policy — this eliminates the attack vector.
Restrict OAuth consent — this prevents abuse of access.
Check the logs — see if device code flow authentication has occurred in your environment.

If you’d like to assess whether your organization is vulnerable to this attack vector, or need help reviewing your Conditional Access policies — get in touch. I’ll help create clarity and set up the right protective measures.