Device Code Phishing as a Service: 3 Entra Settings to Block It

Device code phishing was a state-sponsored espionage technique eighteen months ago. Now it is a commodity attack sold in phishing-as-a-service kits to anyone willing to pay. Microsoft identified Storm-2372 running device code phishing campaigns against government and enterprise targets in February 2025. By mid-2026, the same playbook is being used by financially motivated criminals targeting small and mid-sized businesses, including M365 tenants across Texas.

The attack is effective because it bypasses MFA completely, uses Microsoft’s own login infrastructure, and generates no alerts in most default security configurations. We covered the full attack mechanics in our device code phishing breakdown. This post focuses on the three Entra ID Conditional Access settings that shut it down and the defense-in-depth measures that protect you if an attacker finds another way in.

What Changed: From Espionage Tool to Commercial Kit

Storm-2372’s original campaigns targeted government agencies, defense contractors, and large enterprises. The group sent phishing messages with device codes over Teams, email, and WhatsApp, tricking employees into authenticating sessions the attackers controlled. Microsoft attributed these campaigns publicly and pushed detection updates through Defender.

What made device code phishing dangerous at the state-sponsored level has made it even more effective as a commercial product. The technique requires no malware, no phishing infrastructure hosting fake login pages, and no technical sophistication on the attacker’s part. The phishing page is microsoft.com/devicelogin, which is Microsoft’s real, legitimate authentication endpoint. The attacker generates a device code, delivers it to the target, and waits for the target to authenticate. The entire attack fits into a simple API call and a convincing message.

Phishing-as-a-service platforms have packaged this into turnkey kits that handle code generation, delivery, and token harvesting automatically. An attacker subscribes to the service, customizes the phishing pretext, and receives harvested tokens as employees authenticate. The barrier to entry that once limited this technique to well-resourced nation-state groups has dropped to a monthly subscription fee.

For SMBs running Microsoft 365 Business Premium or E3, the default tenant configuration has device code flow enabled with no conditional access policy restricting it. Every employee in your organization can be targeted, and a single successful phish gives the attacker a fully authenticated session token with access to email, SharePoint, OneDrive, and Teams.

Why MFA Does Not Protect Against This Attack

Device code phishing does not bypass MFA through a technical exploit. It works because the employee completes the MFA challenge themselves on the attacker’s behalf.

When an employee enters a device code at microsoft.com/devicelogin, Microsoft prompts them for their credentials and their MFA factor, exactly as it would for any normal sign-in. The employee authenticates with their password and their authenticator app, push notification, or security key. Microsoft validates everything correctly and issues an OAuth access token plus a refresh token. The problem: those tokens go to the device that generated the code, which belongs to the attacker.

From Microsoft’s perspective, the authentication is legitimate. Every credential was correct, every MFA challenge was satisfied, and the session was established through official channels. No security tool watching for stolen passwords, brute force attempts, or adversary-in-the-middle proxy attacks will flag the event. The employee handed over access voluntarily.

This is why device code phishing requires a different defense than traditional credential theft. Turning on MFA protects against password compromise. It does not protect against an employee willingly authenticating a session they did not initiate. The fix is conditional access policies that block the authentication flow itself.

The 3 Entra Conditional Access Settings That Block It

These three settings address device code phishing directly. Each one adds a layer of protection, and together they eliminate the attack path for the vast majority of M365 tenants. All three are configurable in the Microsoft Entra admin center under Protection > Conditional Access.

1. Block Device Code Flow for All Users

This is the primary fix. If your organization does not use smart TVs, digital signage, or IoT devices that require device code authentication, block the flow entirely.

Create the policy:

• Go to Conditional Access > Create new policy
• Assignments > Users: All users. Exclude your break-glass emergency access accounts.
• Target resources: All cloud apps
• Conditions > Authentication flows: Configure to Yes, select Device code flow
• Grant: Block access
• Enable policy: On

Test this on a pilot group first. Check whether any legitimate services in your environment depend on device code flow. Meeting room displays, shared kiosk devices, and some IoT integrations sometimes use it. If they do, exclude those specific service accounts from the policy rather than leaving the flow open for everyone.

Once this policy is active, any attempt to authenticate through microsoft.com/devicelogin is blocked by Entra. Even if an employee enters a malicious device code, the token grant fails.

2. Require Compliant or Managed Devices

Even with device code flow blocked, conditional access should require that authentication requests come from devices your organization manages through Intune. This protects against device code phishing and every other attack that involves an attacker authenticating from an unmanaged machine.

Create or update the policy:

• Assignments > Users: All users (same break-glass exclusions)
• Target resources: Office 365 (or All cloud apps, depending on your environment)
• Grant: Require device to be marked as compliant

This means that even if an attacker obtains valid credentials and completes MFA, the token is only issued if the request originates from a device enrolled in your Intune instance. The attacker’s machine will never meet this requirement. Your M365 administrator or managed IT provider should already have device compliance policies defined in Intune.

3. Enforce Sign-in Frequency and Disable Persistent Sessions

Stolen tokens expire. The question is whether they expire in hours or in weeks. By default, M365 refresh tokens can remain valid for up to 90 days, giving an attacker prolonged access from a single successful phish.

Create or update the policy:

• Assignments > Users: All users
• Target resources: All cloud apps
• Session controls:
  • Sign-in frequency: 8 hours (or your organization’s typical work-shift length)
  • Persistent browser session: Disabled

This limits the window of access if a token is compromised through any method, not just device code phishing. An attacker with a stolen token gets hours of access rather than weeks. Combined with setting #1, this serves as a backstop for other token theft techniques like infostealer malware and AiTM phishing.

Defense in Depth Beyond Conditional Access

Conditional access policies are the primary technical control. The following measures add detection and response capabilities that catch attacks when preventive controls fail.

Monitor device code authentication events. Your SIEM should alert on any authentication using the device code grant type (urn:ietf:params:oauth:grant-type:device_code). If you blocked device code flow in setting #1, these events should never appear in your tenant. If one does, it means someone is using an excluded account and you need to investigate immediately.

Enable Continuous Access Evaluation. CAE allows Entra ID to revoke tokens in near real-time when conditions change, such as a user account being disabled, a password reset, or a network location shift to a high-risk region. Without CAE, a revoked session may remain active until the cached token expires naturally. CAE is available with Microsoft 365 E3 and Business Premium licenses.

Train employees on device code phishing specifically. General phishing awareness training does not cover this attack because the phishing page is genuinely Microsoft’s. Security awareness training should teach employees one simple rule: never enter a code at microsoft.com/devicelogin unless you personally initiated the request from your own device. If you did not start the process yourself, the code came from someone else.

Audit existing inbox rules. After any suspected compromise, check for email forwarding rules that redirect messages to external addresses. Attackers commonly set these up immediately after gaining access to maintain visibility even after the initial token expires. Your IT team should review forwarding rules across all mailboxes at least quarterly.

What to Do This Week

If you have not configured these three settings, the time to act is now. Device code flow is enabled by default in every M365 tenant, and the barrier to exploiting it has dropped from a nation-state capability to a subscription service.

1. Block device code flow in Conditional Access for all users except documented exceptions
2. Require compliant devices for M365 authentication
3. Set sign-in frequency to 8 hours and disable persistent browser sessions

If your Dallas-Fort Worth business needs help implementing these changes, or if you want a broader review of your M365 security configuration, our team can walk through the settings with you and verify nothing in your environment breaks when device code flow is disabled.

For the complete attack breakdown, including how attackers craft the phishing messages and what happens after token theft, see our full device code phishing analysis. For related MFA bypass techniques including adversary-in-the-middle attacks, see our AiTM phishing defense guide.