Intune Compliance Policies and Conditional Access (2026 Guide)

Compliance policies and Conditional Access are two separate features in Microsoft Intune and Entra ID that get talked about as one thing because they’re almost always used together. Compliance policies check what state a device is in; Conditional Access decides what that device is allowed to do based on that state. Understanding where one ends and the other begins is the difference between a baseline that actually protects the tenant and one that just looks like it does.

What Compliance Policies Actually Check

A compliance policy is a set of rules assigned to a device group, evaluated on a schedule (roughly every 8 hours for Windows, faster on mobile). Typical checks include disk encryption (BitLocker on Windows, FileVault on macOS), minimum and maximum OS version, password/PIN complexity, jailbreak or root detection on mobile, and whether Microsoft Defender or another required security app is running and healthy. A device that fails any required check is marked noncompliant in Intune — but on its own, that status doesn’t block anything. Compliance policies report state; they don’t enforce access.

How Conditional Access Uses Compliance as a Signal

Conditional Access is where enforcement actually happens. A Conditional Access policy defines conditions (which users, which apps, which locations, which device platforms) and grant controls (require MFA, require a compliant device, require an approved app or app protection policy, or simply block access outright). “Require device to be marked as compliant” is the control that ties the two systems together: Entra ID checks the compliance status Intune already calculated and grants or denies access based on it. Without a Conditional Access policy referencing compliance, a noncompliant device can still sign in and access everything — Intune will just keep flagging it as noncompliant in reports.

The June 2026 “Require Approved Client App” Deprecation

Worth flagging specifically: Conditional Access policies using “Require approved client app” as their only grant control stop being enforced from 30 June 2026. That control worked from a static, Microsoft-maintained list of “approved” apps (Outlook, Teams, and so on) — it said nothing about what those apps could actually do with company data once opened. The replacement, “Require app protection policy,” is Intune-driven: you define the app protection policy yourself, controlling things like whether a user can copy data out of a managed app into a personal one, save attachments to local storage, or use the app at all on a jailbroken device. Any tenant still relying on the old control needs to build and assign app protection policies before that date, or BYOD access to corporate data via mobile apps will simply stop being gated at all.

Building a Baseline Conditional Access Policy Set

Most 2026 tenants converge on a similar core set: enforce MFA for all users (phased in gradually to avoid lockouts), block legacy authentication protocols entirely, require a compliant or Entra-joined device (or an app protection policy for BYOD) for access to corporate data, restrict sign-in by location where the business genuinely operates from fixed regions, limit session lifetime for higher-risk apps, and block the device code flow authentication method except for specific, justified exceptions (it’s a common phishing and token-theft vector). MFA itself is shifting too — phishing-resistant methods like passkeys and FIDO2 security keys are now the recommended baseline, with SMS and push-notification MFA treated as legacy methods to migrate away from, not the default to configure.

Grace Periods and Remediation

Compliance policies support a grace period — a configurable number of days after a device first goes noncompliant before Conditional Access actually starts blocking it. This exists so a user isn’t locked out the instant a policy tightens or a device briefly drifts (a Windows update pending a restart, for instance). During the grace period the user typically sees a notification in Company Portal explaining what’s wrong and how to fix it. Setting the grace period too long defeats the point of the policy; setting it to zero can lock out an entire device fleet the moment a compliance rule changes, so it’s worth testing policy changes in report-only mode before rolling them out live.

Common Mistakes

• No break-glass accounts excluded. Every Conditional Access policy should exclude at least one or two emergency access accounts, stored securely outside normal MFA methods, so a policy misconfiguration can’t lock every admin out simultaneously.
• Deploying straight to “On” instead of report-only. Report-only mode logs what a policy would have done without actually enforcing it — the only safe way to validate a new policy against real sign-in traffic before it can lock someone out.
• Overlapping or conflicting policies. Multiple Conditional Access policies can apply to the same sign-in simultaneously; Entra ID requires all applicable grant controls to be satisfied, so two policies with contradictory requirements can create sign-ins that are impossible to satisfy.
• Treating compliance and Conditional Access as one setting. Marking a device compliant in Intune does nothing on its own — it only matters if a Conditional Access policy actually checks for it.

Compliance and Conditional Access round out the security side of the wider Intune picture — for licensing, Autopilot, and co-management context, start with the Microsoft Intune complete guide. If you’re deploying line-of-business software as part of the same rollout, see how Win32 app deployment works, and if you’re migrating device management over from ConfigMgr, the SCCM to Intune co-management guide covers running both side-by-side.

For the wider endpoint security picture — Defender for Endpoint updates, Defender for Cloud, and the current Windows/Intune security baselines — see our Microsoft Defender & Security Baselines guide.