How to Set Up Intune Conditional Access Policies (2026)

Conditional access is technically an Entra ID feature, not an Intune feature, but it’s where device compliance signals from Intune actually get enforced. This is the piece that turns a compliance policy from a status report into a real access control. Getting the rollout sequence wrong is the single biggest risk here, since a misconfigured policy can lock out your entire organisation from email simultaneously.

Always start in report-only mode

Every new conditional access policy supports a report-only enforcement mode that logs what WOULD have happened without actually blocking anyone. Use this for at least several days on any new or modified policy before switching to “On”. The sign-in logs during report-only will show you exactly who would have been blocked and why, letting you fix policy gaps before they become support tickets.

Step 1: Define the policy scope precisely

Scope by specific user/group and specific cloud apps rather than “All users” and “All cloud apps” for your first policies. A pilot group of IT staff testing a policy against a single app is far safer than an org-wide policy against everything on day one.

Step 2: Set the grant control

“Require device to be marked as compliant” is the setting that ties back to Intune compliance policies. Combine it with “Require multi-factor authentication” for a genuinely strong baseline. Either factor alone is meaningfully weaker than requiring both.

Always maintain a break-glass account

Keep at least one emergency access account explicitly excluded from all conditional access policies, with a strong unique password stored securely offline. This is your recovery path if a policy misconfiguration locks out your normal admin accounts. Skipping this step is the single most common cause of a genuine “we’ve locked ourselves out of our own tenant” incident.

For official guidance, see Microsoft’s Intune documentation.