Tutorials › Microsoft 365 / Entra

Block device code flow with Conditional Access

Device code flow lets someone sign in on a device without a keyboard, such as a meeting room screen, by typing a code on another device. Microsoft calls it a high-risk sign-in method because it can be used in phishing, and it recommends blocking it wherever you can. This guide blocks it with a Conditional Access policy, starting in report-only mode so nothing breaks.

Before you start

  • You need at least the Conditional Access Administrator role.
  • Know your emergency access (break-glass) accounts. They must be excluded from the policy.
  • Find out whether anything legitimate uses device code flow, such as Android-based meeting room devices or device registration.

Step 1: Check who uses device code flow today

  1. Go to entra.microsoft.com and sign in.
  2. Open the Sign-in logs. The quickest way is to type Sign-in logs into the search bar at the top of the admin center.
  3. Select Add filters, choose Authentication Protocol, then select Device code and apply it.
  4. Set the date range as wide as it will go and look at the results. Each row is a sign-in that used device code flow. Note the users, apps and devices.
  5. If a sign-in is from a known meeting room device or a known admin tool, write it down so you can plan an exclusion. Anything you don't recognise is worth investigating.
If your organisation uses device code flow to register devices, Microsoft says to exclude the Device Registration Service from the policy. You can check by adding the Resource ID filter with the client ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 alongside the Device code filter.

Step 2: Create the policy in report-only mode

  1. Browse to Entra ID > Conditional Access > Policies.
  2. Select New policy and give it a clear name, such as CA - Block device code flow.
  3. Under Assignments, select Users or workload identities. Under Include, select All users.
  4. Under Exclude, select Users and groups and pick your break-glass accounts, plus any users you noted in Step 1 who genuinely need device code flow.
  5. Under Target resources > Resources (formerly cloud apps) > Include, select All resources (formerly 'All cloud apps').
  6. If you need it, under Exclude select Select excluded cloud apps and add Device Registration Service.
  7. Under Conditions > Authentication Flows, set Configure to Yes, tick Device code flow, then select Done.
  8. Under Access controls > Grant, select Block access, then Select.
  9. Set Enable policy to Report-only, then select Create.

Step 3: Review the report-only results

  1. Leave the policy in report-only for at least a week so you catch weekly tasks.
  2. In Sign-in logs, filter on Authentication Protocol = Device code again and open each sign-in. Look at the report-only result for your policy. If it shows a failure, that sign-in would have been blocked.
  3. For each would-be block, decide: is this a legitimate use that needs an exclusion, or something that should be stopped?

Step 4: Switch the policy on

Careful: once the policy is on, device code sign-ins are blocked straight away. Microsoft also notes that sessions which used device code flow are tracked, so a user may be blocked from other apps in the same session or signed out of a device completely. Make sure your break-glass accounts are excluded and tell anyone affected before you switch it on.
  1. Go back to Entra ID > Conditional Access > Policies and open your policy.
  2. Change Enable policy from Report-only to On, then select Save.

Check it worked

  1. On a test PC, open PowerShell and start a device code sign-in with a test account that is not excluded, for example with the Microsoft Graph module:
    Connect-MgGraph -UseDeviceCode
  2. Follow the prompt to enter the code at the sign-in page. The sign-in should be blocked with a Conditional Access message.
  3. In Sign-in logs, find that sign-in. The Conditional Access tab should show your policy with the result Failure.
  4. Check that a normal sign-in in a browser for the same user still works.
Policies scoped to users don't block service principals. If you have scripts running as apps, protect them separately with Conditional Access for workload identities, or move them to managed identities where you can.

Sources

← All tutorials