Lately I've run into more and more phishing attacks against Microsoft 365 and Azure tenants where the attacker sends users a device code and pushes them to enter it at microsoft.com/devicelogin. Anyone who falls for it hands the attacker access tokens, and strong authentication often doesn't stop that. Device code flow phishing has turned into a real problem because it gets around the security controls most of us rely on. The good news is that Conditional Access can now block device code flow. If you switch it on without doing your homework first, though, you can break legitimate workflows.

Device code flow hands attackers a valid token

Device code flow exists for situations where a user can't sign in directly on the device itself, such as Teams Rooms screens, IoT hardware or headless CLIs. The user opens microsoft.com/devicelogin and types in a code to authorize the app. Phishers turn this around. They start the flow themselves and get the user to finish it, and the attacker ends up with a fresh token. These sign-ins do show up in the logs, but plenty of admins overlook them or simply don't watch closely enough. Microsoft covers the technical background in its documentation on authentication flows.

A new Conditional Access condition blocks device code flow

Conditional Access has a new condition in preview called Authentication flows. With it you can block device code flow and authentication transfer specifically. In the Conditional Access policy wizard you'll find it under Conditions > Authentication flows (Preview), where you can select device code flow and block it. Don't rush this step. In many tenants, Teams Rooms devices, a few legacy CLI tools and some scripts still depend on device code flow. A blanket block can lead to outages or a pile of support calls, so take a careful look at your environment beforehand.

Sign-in logs show where device code flow is in use

Before you enforce anything, find out whether device code flow is actually being used and by what. In the Microsoft Entra admin center, open Sign-in logs and filter on Authentication protocol = Device code. If you export your logs to Log Analytics (this needs a suitable diagnostic setting, at least Log Analytics Reader, and Azure Monitor licensing), you can run this short KQL query in your Log Analytics workspace:

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| summarize Count = count() by AppDisplayName, UserPrincipalName

The result tells you which apps and accounts use device code flow. In my projects, Teams Rooms, monitoring tools and the occasional admin script turn up regularly. Once you know which of these are legitimate, you can move ahead safely.

Pro tip: Start every new Conditional Access policy for authentication flows in report-only mode. You see right away which users or devices would be affected, and production isn't touched.

The policy runs in report-only mode before you enforce it

Create the policy under Protection > Conditional Access in the Entra admin center. Turn on the preview Authentication flows condition and select device code flow. Run it in report-only mode first and watch the sign-in logs and your support channels for several days. Look at which authentications would have been blocked and whether any tickets or errors come in. Switch to enforce only when you're confident that no legitimate use is affected.

A typical rollout goes like this:

  • Review sign-in logs for device code flow usage
  • Document the apps and devices that really need it
  • Create a Conditional Access policy scoping Authentication flows (Preview) in report-only mode
  • Watch for blocked attempts and user problems
  • Switch to enforce once everything looks clean

The diagram below shows how device code phishing usually plays out. The attacker obtains the code, tricks the user into entering it and ends up with an access token.

flowchart TD
Attacker["Attacker requests device code"]
User["User receives code via phishing email"]
Entry["User enters code at microsoft.com/devicelogin"]
Token["Token is issued to attacker"]
Attacker --> User --> Entry --> Token

Figure: How device code phishing works in practice.

Some legitimate use needs targeted exceptions

In 2024 you'll still find some device code flow usage out there, mostly older Teams Rooms, a handful of monitoring or deployment tools and a few scripts. Where you truly can't avoid it, build targeted exceptions into your Conditional Access policy and scope them to specific apps or device groups. It's also worth checking whether these cases can move to modern methods such as interactive browser sign-in or certificate-based device authentication. Details are in Microsoft's policy documentation.

I block device code flow with care, not on autopilot

Device code phishing is happening right now. In most modern Microsoft 365 tenants, blocking device code flow makes sense, provided you've checked carefully where it's still needed and set up the right exceptions. Even in preview, the new authentication flows condition in Conditional Access is a big improvement. If you begin with report-only and take it step by step, you'll harden your tenant noticeably without causing needless disruption. I've collected more advice on rolling out Conditional Access in /blog/conditional-access-entra-id-getting-started.