3 Entra ID Settings That Stop Device Code Phishing in Microsoft 365

Device code phishing gives attackers a fully authenticated Microsoft 365 session without stealing a single password. The employee visits the real microsoft.com/devicelogin page, enters a code, completes MFA, and unknowingly hands over an OAuth token to someone else’s machine. We covered how the attack works and why it bypasses MFA earlier this month. Since then, the technique has continued to spread from nation-state groups like Storm-2372 into commodity phishing kits, meaning it is no longer just an APT problem.

Most Microsoft 365 tenants have device code flow enabled by default and no policy restricting it. Three Entra ID Conditional Access settings change that. Here is how to configure each one.

Why MFA Doesn’t Help Here

Traditional phishing steals credentials by sending users to a fake login page. Device code phishing skips that entirely. The user authenticates on the real Microsoft page, completes their normal MFA challenge, and everything checks out. Microsoft issues a valid access token and refresh token, but they go to the attacker’s polling session instead of a legitimate device.

This is a token theft attack, not a credential theft attack. Microsoft’s own token theft playbook confirms it: “Because authentication requirements are met, the threat actor is granted access to organizational resources by using the stolen token.”

The refresh token is the bigger problem. Access tokens expire after about an hour. Refresh tokens can persist for days or weeks, giving attackers ongoing access to email, SharePoint, OneDrive, and Teams without re-authenticating. In the Storm-2372 campaigns, attackers used stolen refresh tokens to read email, exfiltrate files, and set up forwarding rules to maintain visibility even after the tokens were revoked.

The technique requires almost no infrastructure. The attacker generates a device code through Microsoft’s API, sends the user code via email, Teams, WhatsApp, or Signal, and polls for the token. No phishing domain, no adversary-in-the-middle proxy, no SSL certificate spoofing. Volexity reported multiple Russian threat groups using the technique simultaneously in early 2025, which suggests shared tooling and a low barrier to adoption. That same low barrier has made it attractive for financially motivated attackers targeting small and mid-sized businesses throughout 2026.

Setting 1: Block Device Code Flow in Conditional Access

This is the primary fix and the single most effective mitigation. Microsoft’s own documentation recommends organizations “get as close as possible to a unilateral block on device code flow.”

Most SMBs have no legitimate use for device code authentication. Unless your organization uses smart TVs, digital signage, conference room displays, or IoT devices that require this specific flow, you can block it outright.

Configuration steps:

1. Open the Microsoft Entra admin center and go to Protection > Conditional Access > Policies.
2. Select New policy and give it a clear name like “Block device code flow.”
3. Under Users, select All users. Exclude your emergency access (break-glass) accounts.
4. Under Target resources, select All resources.
5. Under Conditions, select Authentication flows. Set Configure to Yes, then check Device code flow.
6. Under Access controls > Grant, select Block access.
7. Set the policy to Report-only first. Leave it in report-only mode for a week and monitor the sign-in logs for any legitimate device code flow events. If nothing shows up, switch it to On.

If you find legitimate services that depend on device code flow, create a separate policy that allows it only for the specific user accounts or service principals that need it, scoped to specific applications. Everyone else stays blocked.

One important detail: Entra’s protocol tracking follows the session through token refreshes. If a session was initiated via device code flow, subsequent refresh requests are also blocked, even though the refresh itself doesn’t use the device code grant type. This prevents an attacker from getting past the block by immediately refreshing the token through a different flow.

Setting 2: Require Device Compliance (Token Protection)

Token Protection binds sign-in session tokens cryptographically to the device that performed the authentication. Even if an attacker steals a token, it cannot be replayed from a different machine.

This is effective against device code phishing because of a fundamental limitation in the protocol: the device performing the authentication (the user’s phone or laptop) is not the device that initiated the code request (the attacker’s machine). Device code flow inherently cannot provide device state to the authorization server. Microsoft’s Conditional Access documentation states it directly: “When you use the device-code OAuth flow, the required grant control for the managed device or a device state condition isn’t supported.”

That means a policy requiring a compliant or Entra-joined device blocks device code flow as a side effect, even without explicitly targeting the authentication flow.

Configuration steps:

1. In the Entra admin center, go to Protection > Conditional Access > Policies and create a new policy.
2. Under Users, select All users (with break-glass exclusions).
3. Under Target resources, select the applications you want to protect (Exchange Online, SharePoint Online, Microsoft Teams at minimum).
4. Under Access controls > Grant, select Require device to be marked as compliant or Require Microsoft Entra hybrid joined device.
5. Under Access controls > Session, enable Token Protection (currently GA on Windows, preview on iOS and macOS).
6. Deploy in report-only mode first, then enforce after confirming no disruption to legitimate workflows.

This setting works as a defense-in-depth layer alongside the explicit device code flow block. If an attacker finds a way around the first policy, the device compliance requirement catches it.

Setting 3: Continuous Access Evaluation and Sign-in Risk Policies

The first two settings prevent the attack. This one limits the damage when a token does get stolen through any method, including device code phishing, AiTM attacks, or session cookie theft.

Continuous Access Evaluation (CAE) allows resource providers like Exchange Online and SharePoint to reject tokens in near-real-time when critical security events occur. Without CAE, a stolen token stays valid until it expires (default one hour). With CAE, an administrator can revoke all refresh tokens for a compromised user and have that revocation take effect within minutes.

CAE responds to these events immediately:

• User account disabled or deleted
• Password changed or reset
• MFA re-enabled for the user
• Admin explicitly revokes all refresh tokens
• High user risk detected by Entra ID Protection
• User leaves a trusted network location

Pair CAE with sign-in risk policies from Entra ID Protection. Several of the built-in risk detections are directly relevant to device code phishing:

• Anomalous Token: Detects tokens with atypical characteristics or used from unfamiliar locations. Microsoft’s documentation notes this detection specifically identifies when “the attacker is replaying the token.”
• Unfamiliar sign-in properties: Triggers when sign-in properties like IP address, location, or device fingerprint don’t match the user’s history.
• Verified threat actor IP: Flags sign-ins from IP addresses associated with known nation-state actors or cybercrime groups.

Configure a Conditional Access policy that requires MFA re-authentication and password change when user risk is high. This creates a tripwire: even if the initial token grant succeeds, subsequent token use from the attacker’s infrastructure triggers a risk event that forces re-authentication on a device the attacker doesn’t control.

Beyond Conditional Access: Detection and Training

Conditional Access policies are preventive controls. You also need detection and awareness.

Monitor your sign-in logs. The Entra sign-in logs support filtering by Authentication Protocol. Filter for “Device code” events to identify any usage, legitimate or otherwise. If you have a managed SIEM, create an alert rule for device code authentication events, especially when followed by access from an unfamiliar IP or location. Your SOC team should correlate device code grants with subsequent mailbox access and SharePoint downloads to identify post-compromise activity within the first few minutes.

Train your employees. Security awareness training needs to cover device code phishing specifically because the usual “check the URL” advice doesn’t apply. The URL is real. The page is real. The MFA prompt is real. Employees need to learn one simple rule: never enter a device code you did not generate yourself. If someone sends you a code to enter at microsoft.com/devicelogin and you didn’t initiate the request, report it. This is the same category of awareness needed for identity-first security across the entire Microsoft 365 stack.

Review quarterly. Add device code flow policy review to your quarterly security posture check. Verify the blocking policy is still active, confirm no one has added overly broad exceptions, and review the sign-in logs for any device code events that slipped through. Microsoft regularly updates Conditional Access capabilities, so check for new authentication flow controls or Token Protection features that weren’t available when you first configured your policies.

What to Do This Week

If your organization runs Microsoft 365 and hasn’t touched these settings, start with the device code flow block. It takes about ten minutes to configure in report-only mode and another week to validate before enforcing. If your Dallas-Fort Worth business or team elsewhere in Texas needs help configuring these policies, our Microsoft 365 consulting team works with Entra ID Conditional Access daily.

For a comprehensive review of your identity security posture beyond just device code flow, a cybersecurity risk assessment covers the full surface: conditional access gaps, token lifetime policies, MFA method strength, and the monitoring infrastructure to detect attacks that get past preventive controls.