Blocking device code phishing in Microsoft 365, the CA policy that closes the flow

The primary control: CA "Block device code flow"

Entra ID Conditional Access has an authentication flows condition that lets you block the device authorization grant entirely. When this policy is in place, any attempt to complete a device code authorization against your tenant returns a policy enforcement failure. The attacker's polling loop sees a conditional_access_policy error. The token is never issued.

Policy configuration:

• Name — Block device code flow (or your naming convention)
• Users — All users (scope to your target population)
• Cloud apps — All cloud apps
• Conditions → Authentication flows — Device code flow: Yes
• Grant — Block access
• Session — None required
• Enable policy — On

That is the entire configuration. No filter conditions, no location scoping, no MFA requirement — it is a block. Any user who hits a device code flow against any app in your tenant gets blocked before a token is issued.

What to allowlist

Before enabling the block, identify every legitimate device code use case in your environment. Common ones:

• Azure CLI — az login --use-device-code on headless servers or WSL where browser redirect is not available. Allowlist: exclude the Azure CLI app (04b07795-8ddb-461a-bbee-02f9e1bf7b46) from the policy, or scope the exclusion to a security group containing your infrastructure accounts.
• Azure PowerShell — Connect-AzAccount -UseDeviceAuthentication. Same pattern.
• VSCode with Azure extensions — Some extension auth paths fall back to device code. Usually resolvable by switching to Interactive auth in VSCode settings, but if not, exclude the extension's AppId.
• Legacy IoT or LOB devices — Anything physically unable to open a browser. These should be service principals with app credentials, not user-delegated device code flows. If they are using device code today, migrate them before enabling the block.

The allowlist goes into a named location exclusion or an app filter in the CA policy, depending on your Entra ID license tier. The goal is: block all users from all apps except the specific AppIds or device groups you have verified.

Deploy order

Step 1. Enable the block policy in Report-only mode. Let it run for 7-14 days. Review the CA What-If and sign-in logs to identify what would have been blocked.

Step 2. Tune the allowlist based on what you see. Add any legitimate device code apps that appeared.

Step 3. Switch the policy from Report-only to On. Monitor SigninLogs for ResultType != 0 with AuthenticationProtocol == "deviceCode" — those are your enforcement events.

Step 4. Enable the detection rules from the detection post. After the CA block is active, any successful device code sign-in (ResultType == 0) that your detection fires on is either a CA policy gap or a legitimate allowlisted flow.

What phishing-resistant MFA covers and does not cover

FIDO2 hardware keys, Windows Hello for Business, and certificate-based authentication are strong controls. They prevent credential theft and AiTM session cookie capture. They do not prevent device code phishing.

The victim using a FIDO2 key satisfies the FIDO2 assertion on the real Microsoft sign-in page. The key works exactly as designed. FIDO2 authenticates the user to Microsoft. It does not evaluate whether the code the user just pasted was generated by them or by an attacker. There is no FIDO2 signal in the device code authorization step.

This means FIDO2-enrolled tenants are vulnerable to device code phishing by default. The CA block policy is the control that closes this gap, not MFA method upgrades.

Defense in depth: admin consent settings

Device code phishing that uses a first-party Microsoft app (Office, Azure CLI, Azure PowerShell) does not require any admin consent because those apps are pre-consented in every tenant. For attackers using third-party apps — less common but possible — the admin consent workflow adds a layer.

In Entra ID under Enterprise Applications → Consent and permissions:

• User consent for applications — Set to "Do not allow user consent" or "Allow user consent for apps from verified publishers only." This forces third-party app authorization through the admin consent queue, giving you visibility before tokens are issued.
• Admin consent requests — Enable the workflow so users can request consent for apps they legitimately need rather than being silently blocked.

This setting does not stop attacks using first-party Microsoft app IDs, which is the most common attacker choice precisely because no consent prompt appears. It is a useful layer for the third-party variant.

Summary of control priority

• Deploy the CA block policy. This is the primary control. It prevents token issuance entirely.
• Deploy the Sentinel detection rules. Even with the CA block active, you want the canary rule (Rule 02 from the detection post) watching for policy gaps.
• Restrict user consent. Defense in depth against third-party app variants.
• FIDO2 / phishing-resistant MFA. Closes AiTM and credential theft. Does not close device code. Still worth deploying for the AiTM coverage.