The question at hand
Your Conditional Access policies probably don't cover device-code authentication. That's a problem because attackers are using Microsoft's OAuth 2.0 device authorization grant flow to bypass your MFA and register unauthorized devices in your tenant.
This flow is legitimate, designed for IoT devices, smart TVs, and printers that can't handle browser-based logins. The device displays a code, you enter it on another device, and authentication completes. However, campaigns like GhostCode have turned this into an access vector. Once an attacker tricks a user into entering a device code, they can register devices, obtain Primary Refresh Tokens that last 14 days by default, and enroll into Intune in ways that survive token revocation.
So, should you disable device-code authentication entirely, or is that discarding a capability your organization needs?
The case for blocking it
The security argument is straightforward. Device-code authentication bypasses most of your existing controls. When eSentire analyzed the GhostCode campaign in late August 2026, they observed three devices registered in 78 seconds following a single authentication event. The third device enrolled into Intune and remained in the tenant even after token revocation. This isn't a vulnerability in the traditional sense; it's the flow working as designed, just with an attacker controlling the "device."
The Primary Refresh Token obtained through this method gives SSO-equivalent access to your entire Microsoft 365 environment for 14 days. Any service not explicitly protected by a Conditional Access policy requiring a compliant device becomes accessible. If you're running a Zero Trust architecture built on device trust signals, device-code authentication undermines your entire model.
From a detection perspective, look for patterns like multiple device registrations from a single non-interactive session or python-requests user agents following device-code authentication. But that's reactive. You're already compromised by the time those indicators fire.
The pragmatic question is: How many users in your organization actually need to authenticate IoT devices or smart TVs to your corporate Microsoft 365 tenant? In most enterprises, the answer is close to zero. Conference room displays might authenticate to a shared account, but those can be handled through service accounts with restricted permissions. Individual users authenticating their personal smart TV to corporate email is not a use case you want to support.
If you don't have a legitimate business requirement for device-code authentication, blocking it removes an entire attack surface. Configure Conditional Access to block the device-code flow outright, or restrict it to a small group of service accounts that actually need it. The Microsoft Device Registration Service can still function for managed endpoints going through normal enrollment processes.
The case for conditional restriction
The counterargument isn't that device-code authentication is risk-free. It's that blanket blocking creates operational friction in environments where the flow serves a real purpose.
Some organizations run IoT deployments that authenticate to Microsoft 365 or Azure resources. Industrial sensors, building automation systems, and digital signage platforms might use device-code authentication because they lack the input mechanisms for conventional login. Blocking the flow entirely breaks those integrations, and your facilities team will be filing tickets within hours.
There's also the question of third-party applications. Some legitimate SaaS tools use device-code authentication as a fallback when their primary OAuth flow fails or when they're running in headless environments. If you block it globally, you might find that a critical business application stops working, and the vendor's support response is "enable device-code authentication."
A more nuanced approach is Conditional Access policies that restrict device-code authentication to specific users, applications, or device compliance states. You can require that device-code authentication only succeeds from known IP ranges or that it triggers step-up authentication. Log every device-code attempt and route those logs to your SIEM for correlation with device registration events.
This approach requires more configuration work. You need to identify which users and applications legitimately need the flow, create security groups, and build policies that balance access with visibility. But it preserves the capability for cases where you need it, while still giving you detection and response options.
Where practitioners actually land
Most organizations fall into one of three patterns. Small to mid-size enterprises with straightforward Microsoft 365 deployments tend to block device-code authentication entirely. They don't have IoT use cases that touch corporate identity, and they'd rather eliminate the risk than manage exceptions.
Larger enterprises with complex environments usually take the conditional restriction approach. They identify a handful of service accounts used for conference room systems or industrial IoT, restrict device-code authentication to those accounts, and monitor everything. The operational overhead is higher, but they avoid breaking existing integrations.
The third pattern is organizations that haven't configured Conditional Access for device-code authentication at all. They're relying on default Microsoft settings, which allow the flow. These organizations are getting compromised by campaigns like GhostCode, because their users can complete device-code authentication without additional controls, and the resulting device registrations look legitimate to their monitoring tools.
Our take
Block it unless you have a documented business requirement that can't be met another way. The security risk is too high relative to the legitimate use cases in most environments.
If you need to support device-code authentication, treat it like any high-risk access method. Restrict it to named service accounts, require compliant devices where possible, and log every authentication attempt to the Device Registration Service with alerting on multiple registrations from a single session. Monitor for python-requests user agents following device-code authentication, and audit Entra ID for unexpected device registrations.
The tradeoff isn't between security and functionality. It's between proactive risk reduction and reactive incident response. Device-code phishing works because the authentication flow is legitimate. Your MFA completes normally. The device registers through official APIs. By the time you detect the compromise, the attacker has a Primary Refresh Token that persists for two weeks.
You can't patch the OAuth 2.0 device authorization grant flow. But you can decide whether your organization needs to expose it at all.
