Blocking the Device Code Flow in Microsoft Entra ID with Conditional Access

In the article on Device Code Phishing we showed how an attacker abuses the OAuth2 Device Code Flow to capture a token and act on the victim’s behalf — without knowing the password and while bypassing MFA. This guide is the second half of the topic: what exactly to do to close that attack surface in Microsoft Entra ID using Conditional Access.

Starting point: two strategies

Microsoft allows you — through Conditional Access options and policies — to disable or limit the use of the Device Code Flow, or to confine it to controlled scenarios. You essentially have two paths:

• Option A — full disablement. If your organization does not use the Device Code Flow, block it entirely. This is the simplest and most effective solution: the entire attack surface disappears.
• Option B — scope reduction. If some scenarios genuinely require the flow (e.g. selected CLI tools or IoT devices), block it for everyone but exclude a narrow group of accounts or applications that need it — optionally tying the allowed flow to managed/compliant devices.

In both cases, the enforcement mechanism is a Conditional Access policy with the Authentication flows condition and the Block access control.

Licensing requirement: Conditional Access policies require an Entra ID P1 license for the users they cover. Without it, the Authentication flows condition will not be available for enforcement.

Before you click: preparation

1. Inventory actual usage. Review the Entra ID sign-in logs and filter events by authentication flow type (device code). Check which applications and accounts actually use the flow — this is the basis for choosing between option A and B.
2. Protect break-glass accounts. Microsoft recommends always excluding at least two emergency accounts from Conditional Access policies, in case a misconfiguration cuts off access.
3. Plan validation in Report-only mode. Don’t enable the policy in enforcement mode straight away — observe its impact first.

Option A — fully disabling the Device Code Flow (step by step)

1. Sign in to the Microsoft Entra admin center with at least the Conditional Access Administrator role.
2. Go to Protection → Conditional Access → Policies and choose New policy.
3. Give the policy a clear name, e.g. Block Device Code Flow.
4. Users → select All users, and in the Exclude tab add the emergency (break-glass) accounts and any groups that need the flow (see option B).
5. Target resources → set to All resources (formerly “All cloud apps”) to cover the full scope.
6. Conditions → Authentication flows → toggle to Configured: Yes and select Device code flow.
7. Access controls → Grant → choose Block access and confirm.
8. Enable policy → set to Report-only first.
9. Click Create.

Keep the policy in Report-only mode long enough to collect representative sign-ins (e.g. a one-week cycle), then — after validation — switch Enable policy to On.

Option B — reducing the scope

If your inventory revealed legitimate use of the Device Code Flow, don’t abandon the block — narrow it:

• Create the same blocking policy as in option A, but under Users → Exclude add a narrow, named group of accounts or applications that genuinely need the flow (e.g. a dedicated service account for a CLI tool or IoT device).
• This keeps the Device Code Flow available only to that group, while it remains blocked for the rest of the organization.
• For the excluded group, consider an additional, separate policy that strengthens the trust context — e.g. requiring a compliant device or an Entra-joined (hybrid/Entra joined) device — so that legitimate use happens only from managed devices.

The principle is simple: block by default, and grant access selectively and deliberately. This aligns with the Zero Trust approach and identity management (IAM).

Pitfalls worth avoiding

• Failing to exclude break-glass accounts. The most common mistake with any Conditional Access policy. Always exclude emergency accounts before switching the policy to enforcement.
• Enabling straight into On mode. Skipping Report-only risks unexpectedly cutting off legitimate scenarios. Observe first, enforce later.
• Overly broad exclusions. In option B, exclude the narrowest possible group. Every excepted account is a potentially open door for Device Code Phishing.
• Confusing blocking the flow with blocking the app. The Authentication flows condition targets the device code flow itself, not the application as such — applications using other flows (e.g. browser-based) keep working.
• Assuming MFA is enough. MFA does not protect against Device Code Phishing, because it is the victim who performs MFA. Blocking the flow operates on a different layer and is the right measure here.

Post-deployment validation

1. Report-only reports. In the policy details and in the Conditional Access reports, check how many sign-ins would have been blocked and whether they include business scenarios you don’t want to cut off.
2. Entra ID sign-in logs. After switching to On, filter events by authentication flow type (device code) and confirm that the covered accounts are blocked and the exclusions work.
3. Controlled test. Try initiating a device code sign-in (e.g. for a CLI tool) on an account covered by the policy and confirm access is blocked; repeat for an excluded account and confirm it works as intended.

Checklist

• Actual Device Code Flow usage inventoried (sign-in logs).
• Strategy chosen: A (full block) or B (block with a narrow exclusion).
• Conditional Access policy: Authentication flows condition → Device code flow → Block access.
• Break-glass accounts excluded and — in option B — a narrow group of legitimate accounts/apps.
• Launched in Report-only mode and impact validated.
• Switched to On and confirmed with a controlled test.
• Exceptions documented and a review cycle established.

The configuration above is an educational example. Screen names and layout in the Microsoft Entra admin center may change, and the policy’s impact depends on the specifics of your tenant. Before a production rollout, test the changes in Report-only mode. If you need support designing and rolling out Conditional Access policies and an identity strategy, the nFlo team can help you do it safely.

Sources and reference materials

• Microsoft Learn — Conditional Access: authentication flows
• Microsoft Learn — Block authentication flows with Conditional Access policy
• Microsoft Learn — OAuth 2.0 device authorization grant flow