Endpoint management
Compliance policy
Microsoft Intune compliance policy
An Intune compliance policy defines the minimum security and configuration standard a device must meet to be considered "compliant," evaluating conditions such as minimum OS version, BitLocker or disk encryption status, whether the device is jailbroken or rooted, password or PIN complexity, whether real-time antivirus protection is active, and Secure Boot or TPM presence.
Why Compliance policy matters in a Microsoft estate
Compliance policy matters for endpoint teams because device, app, compliance, update, and troubleshooting signals often sit across several Microsoft admin areas. Linking these terms back to Intune and device-reporting routes helps readers move from definition to action.
How Compliance policy shows up in practice
It then reports a pass or fail state per device back into Intune and Entra ID. Compliance policies are not, by themselves, an enforcement mechanism; a device that fails a compliance check is simply marked non-compliant, and nothing stops that device from continuing to operate unless a separate Conditional Access policy is configured to require compliance as a condition of accessing corporate resources like Exchange Online, SharePoint, or Teams. This is the connection that trips up a lot of first-time Intune deployments. It is entirely possible to build a thorough set of compliance policies that have no actual effect on anything because the Conditional Access side was never wired up.
Policies are assigned per platform, since the settings available and how they're evaluated differ meaningfully between Windows, iOS/iPadOS, Android, and macOS, and per Entra ID group. A device can be in scope for more than one compliance policy simultaneously, in which case Intune applies the strictest evaluated result across all applicable policies rather than the most recently assigned one. This is a behaviour that surprises admins who expect the newest or most specific policy to simply override an older, broader one.
Grace periods, the window a newly non-compliant device is given before it's actually marked non-compliant in reporting and Conditional Access enforcement, are a common source of a device appearing compliant in the console while genuinely failing a check. The grace period exists specifically to avoid immediately locking out a user for a transient issue like a delayed policy sync. But it also means compliance dashboards can lag real device state by hours or days depending on configuration. Compliance policies also support "compliance actions for noncompliance," configurable notifications and, after a further grace period, automatic remote actions.
This is the mechanism organisations use to nudge users toward self-remediation, sending an email or push notification when a device first goes non-compliant, before Conditional Access starts actively blocking access, rather than the block being the user's first indication anything was wrong. Because compliance status feeds directly into access decisions, compliance policy is one of the highest-leverage places in an Intune estate for both security and cost review. A large population of devices sitting permanently non-compliant, whether from genuine security gaps, stale policy assignments no longer matching the actual device fleet, or devices that have effectively left the estate without being retired, represents both an unmanaged risk and, often, licensed seats no longer delivering the governance they're being paid for.