How to block device code sign-in with Conditional Access

What this check looks at

Checks for a Conditional Access policy that blocks the device code sign-in flow for everyone.

The device code flow is a sign-in method for devices that cannot show a browser, such as smart TVs, meeting room consoles and command-line tools. The device shows a short code; the person goes to microsoft.com/devicelogin on another device, enters the code and signs in with MFA, and the original device receives the session. Microsoft Entra ID allows it for every user by default.

This check applies where the tenant has Conditional Access (Entra ID P1). It looks for a policy that targets all users, includes Device code flow under the authentication flows condition, and blocks access. It passes when such a policy is On and warns when it is only in report-only mode. The check fails when there is no such policy.

Device code phishing turns this into account takeover that MFA does not stop: the attacker starts a device code sign-in, sends the victim the code with a message such as “enter this code to join the Teams meeting”, and the victim signs in on the genuine Microsoft page and completes MFA themselves. The attacker’s device receives tokens for the victim’s account. Microsoft has reported state-sponsored and criminal campaigns using this technique against Microsoft 365.

Why it matters

Device code phishing sends a genuine Microsoft sign-in page with a code; the person signs in and approves MFA, and the attacker’s device receives the session. It bypasses MFA entirely and is used in active campaigns against Microsoft 365. Very few organisations need device code sign-in at all.

Staff at a 90-person consultancy receive a Teams message from a supposed conference organiser with a code to join a call. Two people enter it at microsoft.com/devicelogin and approve MFA. The attacker now holds their sessions, reading mail and downloading SharePoint files for days until someone notices and revokes them.

Very few organisations need device code sign-in, and those that do (some meeting room devices, certain admin tools) can be excluded by account and location. Blocking it removes a whole class of phishing at no cost to everyone else.

CIS Microsoft 365 Foundations Benchmark 5.2.2.12 asks for the device code sign-in flow to be blocked, and CISA SCuBA MS.AAD.3.9 asks for device code authentication to be blocked. CIS Controls v8 safeguards 6.3 and 4.8 (disable unnecessary services), ISO 27001 A.8.5, the NCSC CAF identity verification and authentication outcome and NIST CSF PR.AA-03 support it.

How to fix it

Where: Entra admin centre → Protection → Conditional Access

Before you start

• Filter the sign-in logs on Authentication protocol: Device code over the last 30 days to find anything that uses it (meeting room devices, Azure CLI, some PowerShell modules).
• Exclude only the accounts that genuinely need it, ideally by named location as well.
• Confirm two emergency access (break-glass) accounts exist and exclude them from the policy, so a mistake cannot lock every administrator out.
• Create the policy in report-only mode first and review its results in Entra ID sign-in logs (Conditional Access tab) for at least a week.

Step by step

1. 1Find any legitimate use. In the Microsoft Entra admin centre, go to Entra ID > Monitoring & health > Sign-in logs, set the range to the last 30 days and add a filter on Authentication protocol: Device code, checking both interactive and non-interactive user sign-ins. Note the accounts and apps involved, typically meeting room devices or the Azure CLI.
2. 2Create the policy in report-only mode. Go to Entra ID > Conditional Access > Policies > New policy and name it "Block device code flow". Under Users, include All users and exclude your emergency access accounts and any account from the first step that genuinely needs it (ideally through a group). Under Target resources choose All resources. Under Conditions > Authentication flows, set Configure to Yes and tick Device code flow. Under Grant choose Block access. Set Enable policy to Report-only and select Create.
3. 3Consider blocking authentication transfer too. The same Authentication flows condition offers Authentication transfer, which moves a signed-in session from a computer to a phone by QR code. Most organisations do not need it either; tick it as well if the sign-in logs show no use.
4. 4Review the report-only results. After a week, filter the sign-in logs on the device code protocol again and open each sign-in’s Report-only tab: only the accounts you expected should show Report-only: Failure. Add genuine exceptions to the excluded group, limited to their named location where you can.
5. 5Switch the policy on. Open the policy, set Enable policy to On and Save.
6. 6Confirm device code sign-in is refused. With a test account, start a device code sign-in (for example az login --use-device-code, or Connect-MgGraph -UseDeviceCode) and complete it: it should fail, and the sign-in log should name the blocking policy. The finding clears at the next assessment.

What users will notice

None for most people. Anyone signing in with a code shown on another device is refused.

How to confirm it worked

A device code sign-in attempt from a test account fails with the policy named in the sign-in log, and the policy state is On.

Frameworks and controls

This check maps to controls in 15 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.

The framework mappings were last checked against the published standards in October 2026.

Microsoft’s documentation

• Block authentication flows with Conditional Access (Microsoft Learn)

Related checks

• How to set up the sign-in risk policy in Conditional Access
• How to require MFA for every user with Conditional Access
• Security defaults vs Conditional Access: which to use?
• How to set up user risk and sign-in risk policies

The full Microsoft 365 security checklist, worst first