Microsoft customers are experiencing a 15x increase in device code phishing attacks this year, according to Push Security. These attacks exploit OAuth 2.0's Device Code Authorization Grant, facilitated by phishing-as-a-service platforms like EvilTokens. This raises a critical question for IAM architects: should you disable the device code flow entirely?
The Case for Disabling It
The device code flow (RFC 8628) has a fundamental flaw: it doesn't authenticate the client. An attacker can initiate a legitimate authorization request using a known Client ID, provide a user code to a victim, and wait for the victim to authorize the attacker's session. The authorization server can't differentiate between a legitimate app and an attacker's script polling for tokens.
Microsoft's architecture exacerbates this vulnerability. Every Microsoft customer authenticates through the same common endpoint (login.microsoft.com/common/oauth2/v2.0/devicecode). First-party Client IDs like Microsoft Office are assigned by default across all tenants. This means a single phishing kit can target every Microsoft customer globally without customization.
The attack surface is vast. Centralized authorization and shared Client IDs create a universal attack vector. EvilTokens exemplifies this by offering infrastructure and tools to low-skill attackers, enabling large-scale device code phishing with minimal effort.
If your team doesn't use the device code flow for legitimate business purposes, why keep it enabled? Most workforce applications don't require it. Your employees aren't signing into Entra ID from smart TVs or car systems. The flow was designed for input-constrained consumer devices, not enterprise SaaS apps. Disabling it removes an entire class of attacks that bypass Multi-Factor Cryptographic Devices and phishing-resistant authentication.
Some security teams have already disabled it. If your risk model can't tolerate token theft via social engineering, and there's no documented business case for device code authorization, blocking it is a straightforward decision.
The Case for Hardening It
Disabling the device code flow assumes you can identify every application that uses it, which isn't always feasible.
Some enterprise applications rely on device code authorization for workflows that aren't immediately obvious. IoT device management platforms, manufacturing systems, and certain DevOps tools use this flow because typing credentials is impractical. Blocking it globally without an inventory could disrupt operations.
Consider what you're solving. Device code phishing succeeds because users trust the authorization prompt. They see login.microsoft.com, recognize the domain, and assume it's legitimate. Disabling one flow doesn't fix the core issue: users can't reliably distinguish legitimate consent requests from malicious ones.
Instead of blocking the flow, you can constrain it. Conditional Access policies can ensure device code authorizations only succeed from managed devices or trusted networks. You can restrict which applications use the flow by filtering on Client IDs and enforce step-up authentication for high-risk consents. These controls reduce the attack surface without eliminating the flow entirely.
Microsoft's centralized architecture allows for centralized policy enforcement. If you can't enumerate every application dependency, hardening the flow through policy is less risky than a blanket block.
There's also the practical aspect: you can't always control what your identity provider supports. If you're a Microsoft customer, you're working within Microsoft's authorization architecture. Okta's decentralized model makes device code phishing harder to scale, but switching identity providers isn't a decision made lightly. For most teams, the question is "how do we reduce risk within the system we have?"
Practical Steps for IAM Teams
Most IAM architects don't make a binary decision. They start with visibility: which applications in your environment use the device code flow? If you can't answer that, you're not ready to block anything.
Next, evaluate business need. If you have legitimate use cases for input-constrained devices, harden the flow with Conditional Access and restrict it to known Client IDs. If not, test a block in a pilot group before rolling it out.
The fastest-moving teams have already mapped their OAuth 2.0 grants and Client ID inventory. If you're still discovering what's in production, you're already behind.
Our Take
Disable the device code flow unless there's a documented business requirement for it. The attack surface is too large, and the mitigations are too weak.
If you need to keep it enabled, treat it like any other high-risk authorization grant. Restrict it to managed devices, limit which Client IDs can use it, and monitor authorization logs for anomalies. Don't rely on user judgment to distinguish legitimate requests from phishing attempts.
The broader lesson isn't about one OAuth 2.0 flow. It's about architectural decisions that scale risk. Centralized authorization with shared Client IDs creates universal attack vectors. Decentralized models force attackers to do more reconnaissance per target. When evaluating identity platforms or designing authorization policies, that tradeoff matters.
Device code phishing exploits trust in familiar domains and default configurations. Your users will click through consent prompts they don't understand. The question is whether your architecture makes that mistake cheap or catastrophic.
