Overview
Conditional Access Policies can be used to prevent the Device code authentication flow. Device code flow should be permitted only for users who regularly perform duties that explicitly require using Device Code to authenticate, such as utilizing Azure with PowerShell.
Rationale
Attackers use Device code flow in phishing attacks, which, if successful, results in the attacker gaining access tokens and refreshing tokens scoped to user_impersonation and can perform any action the user has permission to perform.
Impact
Microsoft Entra ID P1 or P2 is required.
This policy should be tested using the Report-only mode before implementation. Without a full and careful understanding of the accounts and personnel who require Device code authentication flow, implementing this policy can block authentication for users and devices who rely on Device code flow. More secure alternatives should be implemented wherever possible for users and devices that rely on device code flow authentication.
Default Value
No policies are configured by default.
Additional Information
These policies should be tested by using the What If tool in the References. Setting these can and will create issues with logging in for users until they use an MFA device linked to their accounts. Further testing can be done via the insights and reporting resource in References, which monitors Azure sign-ins.
Remediation guidance
From Azure Portal
Part 1 of 2 - Create the policy and enable it in Report-only mode.
- Open Conditional Access | Overview
- Click the
+ New policybutton, then: - Provide a name for the policy.
- Under
Assignments, selectUsersthen:- Under
Include, selectAll users - Under
Exclude, checkUsers and groupsand only select emergency access accounts
- Under
- Under
Target resources, selectCloud appsthen:- Under
Include, selectAll cloud apps - Leave
Excludeblank unless you have a well-defined exception.
- Under
- Under
Conditions, selectAuthentication Flowsthen:- Select
Device code flow - Select
Done
- Select
- Under
Access Controls, selectGrantand Confirm thatBlock Accessis selected. - Set
Enable policytoReport-only. - Click
Create.
NOTE: The policy is not yet 'live' since Report-only is being used to audit its effect.
Part 2 of 2 - Confirm that the policy is not blocking access that should be granted, then toggle to On.
- With your policy now in report-only mode, return to the Microsoft Entra blade and click on
Sign-in logs. - Review the recent sign-in events - click an event, then review the event details (specifically the
Report-onlytab) to ensure:- The sign-in event you're reviewing occurred after turning on the policy in report-only mode.
- The policy name from step 5 above is listed in the
Policy Namecolumn. - The
Resultcolumn for the new policy shows that the policy wasNot applied(indicating the device code authentication flow was not blocked).
- If the above conditions are present, navigate back to the policy name in Conditional Access and open it.
- Toggle the policy from
Report-onlytoOn. - Click
Save.
Multiple Remediation Paths
SERVICE-WIDE (RECOMMENDED when many resources are affected): Apply organization/tenant-level guardrails and baseline policies for the entire platform.
ASSET-LEVEL: Fix only the affected resources identified by this control.
PREVENTIVE: Add preventive policy checks to CI/CD and periodic posture scans.
References for Service-Wide Patterns
- Platform policy/governance and preventive control patterns should be applied tenant-wide where supported.
Query logic
These are the stored checks tied to this control.
Entra Connectors Without Device Code Flow Exclusion Policy
Connectors
Covered asset types
Expected check: eq []
{
connectors(
where: {
conditionalAccessPolicies_NONE: {
conditions: {
includeUsers: ["All"]
includeApplications: ["All"]
clientAppTypes: ["all"]
authenticationFlowsTransferMethods_INCLUDES: "deviceCodeFlow"
}
grantControls: { builtInControls: ["block"] }
}
}
) {
...AssetFragment
}
}