Intune compliance policies cheat sheet
Intune compliance policies are rules and conditions that evaluate the configuration of managed devices — minimum OS version, encryption, passcode rules, jailbreak/root detection, health attestation. The results are a device compliance status, and that status is what Microsoft Entra Conditional Access reads when a policy is set to Require device to be marked as compliant. Compliance is a separate duty from configuration: a compliance policy can also override the same setting set by a configuration profile.
Two layers make up compliance. Device compliance policies are the platform-specific rule sets you deploy to groups; each platform needs its own policy, and Android Enterprise even splits by management mode. Compliance policy settings are tenant-wide: how Intune treats devices with no policy assigned (default: compliant), and the validation period (default 30 days, 1-120). Both are worth a glance for any 'device should not be here' report.
Only devices that are enrolled in Intune can receive compliance policies, and evaluation happens at check-ins. You can extend the built-in rules with custom compliance settings on Windows, macOS (and Linux) — a discovery script plus a JSON rule file with a 2,048-character output ceiling. The statuses below are the exact strings the admin center uses.
Platform conditions
| Condition | Platforms | Non-compliance handling |
|---|---|---|
| PIN or password configuration | Windows, macOS, iOS/iPadOS, Android 4.0+, Samsung Knox, Android Enterprise | Remediated on iOS/iPadOS, macOS and Windows — the OS forces the user to set the PIN/passcode. Quarantined on Android and Android Enterprise — the OS does not force it; access is blocked by Conditional Access and Company Portal notifies the user. |
| Minimum OS version / Maximum OS version | Windows, iOS/iPadOS, macOS, Android, Android Enterprise; Linux via allowed distros; Samsung Knox | Quarantined: the device is marked noncompliant, not forcibly upgraded. Allows you to block old OSes long before vendor support ends. |
| Device encryption (BitLocker on Windows, FileVault on macOS) | Windows, iOS/iPadOS, macOS / Android 4.0+, Samsung Knox, Android Enterprise, Linux | Quarantined on all except iOS/iPadOS where it is remediated by setting a PIN. Settings catalog is where you engineer the BitLocker settings; the compliance condition is documented as device encryption. |
| Jailbroken or rooted device | Android, Android Enterprise, iOS/iPadOS | Quarantined — this is a detection, not an enforced setting. macOS, Windows and Linux: not applicable. |
| Windows health attestation | Windows | Quarantined on non-attesting devices (attestation, secure boot, BitLocker integrity signals). |
| Email profile | iOS/iPadOS, macOS | Quarantined when the managed email profile is missing. Not applicable on Windows, Linux, Android. |
| Allowed distros (Linux) | Linux — Ubuntu Desktop 24.04 LTS or 26.04 LTS, RHEL 9 or 10 | Quarantined: only the allow-listed distros are compliant. Linux policies are device-group only (no user assignments). |
Actions for noncompliance
| Action | Platform support | Notes |
|---|---|---|
| Mark device non-compliant (built-in) | All platforms | Included in every policy, scheduled at 0 days by default. Changing the schedule creates a grace period before the device is marked noncompliant. |
| Send email to end user | All platforms | Uses a notification message template (locale, subject up to 78 chars, body up to 2,000 chars, variables like {{UserName}}, {{DeviceName}}, {{DeviceId}}, {{OSAndVersion}}). Sent from microsoft-noreply@microsoft.com; expected within 6 hours. Additional recipients via Microsoft Entra groups. |
| Send push notification to end user | Android device administrator, Android Enterprise (all work-profile modes), iOS/iPadOS | Two Lines: pushes through the Company Portal app or Intune app; may take hours to arrive and are not guaranteed. Each instance sends once — add another instance with a later schedule to re-remind. |
| Remotely lock the noncompliant device | Android (DA, AOSP), Android Enterprise (fully managed, dedicated, COPE, personally owned work profile), iOS/iPadOS, macOS | Locks the device; the user needs a PIN or password to unlock. Not supported on Windows. |
| Add device to retire list | Android (DA, AOSP), Android Enterprise (all modes), iOS/iPadOS, macOS, Windows | Adds the device to Devices > Compliance > Retire noncompliant devices. An admin must explicitly retire it; retiring removes company data and Intune management. Not supported for devices managed by a third-party device compliance partner. |
Compliance statuses: the lifecycle in exact strings
Device dashboard states, policy statuses and tenant settings (monitor + overview docs)
- Compliant
- The device successfully applied one or more compliance policy settings.
- In-grace period
- Targeted by policies but not yet compliant to all of them — often waiting on user action like meeting passcode complexity. Noncompliant, but inside an admin-defined grace period.
- Not evaluated
- Initial state for newly enrolled devices. Other reasons: no policy assigned and no trigger to check; no check-in since the policy was last updated; no associated user (ADE devices without user affinity, Android Enterprise dedicated devices, DEM-enrolled devices).
- Not compliant
- The device failed to apply one or more compliance policy settings, or the user did not comply with the policies.
- Policy-level statuses
- Per-policy: Unknown, NotApplicable, Compliant, InGracePeriod, NonCompliant, Error. Severities 1-6 in that order; with multiple policies, the highest severity wins.
- Error-timeout behavior
- A setting that reports Error keeps the device's current status for up to 7 days so the calculation can complete. If it is still in Error after 7 days, the device flips to Not compliant — or In grace period when the policy has a grace period set.
- Tenant-wide settings
- Mark devices with no compliance policy assigned as: Compliant (default) or Not compliant (recommended with Conditional Access). Compliance status validity period (days): default 30, range 1-120; a device that fails to report within the period is treated as noncompliant.
- Device contact default
- The default grace period is 30 days for a device to stay in contact (on and online); the default compliance policy also checks that the enrolled user exists with a valid Intune license.
- Reporting model
- Statuses refresh when devices check in — reports show the last known state, and a device may appear pending. The dashboard bar can take up to 24 hours for a device to appear; compliance state shown is for the last user who checked in on the device.
What triggers a compliance evaluation
- New enrollment: evaluated frequently so users see blocking reasons quickly.
- Periodic evaluation: keeps the contact requirement enforced (device offline for a few days).
- New compliance information: device properties changed, found during a sync.
- Policy assignment changes: on the next device sync; removing an assignment also recalculates.
- User status checks: the user opens Company Portal or the Company Portal website and checks compliance.
- Client-driven compliance evaluation (preview): supported Windows devices can proactively ask for re-evaluation on local state changes.
Conditional Access: the integration gotchas
Why the compliance state shows green but access is still blocked
- Per-policy status is not overall status. 'Policy compliance status' identifies whether the device is compliant to that policy; Intune can still consider a device noncompliant against a different policy. The drill-in view of a per-setting report shows exactly this case.
- Access control is a separate layer. Conditional Access policies must have 'Require device to be marked as compliant' set; a device can be compliant yet fail another access control (MFA, sign-in risk, location).
- Reports lag check-ins. Compliance evaluation runs continuously, but reporting updates at check-in, so the admin center can show a state that is already stale. The devices without policy setting also defaults to 'Compliant' — a device with no assigned policy can look harmless in reports while its lack of policy is itself the problem (set 'Mark devices with no compliance policy assigned as' to Not compliant).
- Userless and special devices sit in Not evaluated or Not applicable: ADE devices without user affinity, Android Enterprise dedicated, AOSP userless, and DEM-enrolled devices. If your storefront blocks, check the device's evaluation path before blaming the policy.
- Android enrollment uses a Chrome tab for the user sign-in. If you have a Conditional Access policy that applies to All cloud apps, Android and Browsers, exclude the Microsoft Intune cloud app or the setup flow fails.
- Third-party compliance partners: devices managed by a device compliance management partner cannot receive actions for noncompliance (email, lock, retire, push) — rely on the partner's own workflow and the per-device compliance view.
- Not a licensing problem: Intune compliance does not require Microsoft Entra ID. Conditional Access does require Entra ID P1 or P2.
FAQ
Why is my device compliant but Conditional Access still blocks me?
Four common causes. First, a device may be compliant to one policy and noncompliant to another — the per-policy status shown in a policy report only covers that policy. Second, the Conditional Access policy may require more than compliance (MFA, risk, location), or require the device to be marked as compliant while the status Intune last reported to Entra is stale from the previous check-in. Third, the device may be in Not evaluated (newly enrolled, no check-in, or userless like an ADE device without user affinity), which blocks a 'require compliant' grant. Fourth, the tenant setting Mark devices with no compliance policy assigned as may mark it compliant by default while a separate condition is failing. Check the specific policy's device status report first, then the Conditional Access conditions.
What does 'In grace period' mean, exactly?
The device is targeted by a policy but not yet compliant to all of it, within the grace period you defined by delaying the built-in Mark device noncompliant action. Effective status: a device with an actual NonCompliant status is InGracePeriod when its assigned grace period value is still in the future, and NonCompliant when the grace period has expired or none was assigned. Whitelisting a grace period does not change the action schedule — checking the Actions for noncompliance tab shows the grace period settings.
What happens when a compliance setting reports Error?
The device's existing compliance status is retained for up to seven days while Intune lets the calculation complete. If the setting returns Compliant or Not compliant within those days, the device follows that result. If the setting is still in Error after seven days, the device becomes Not compliant — or In grace period if the policy has a grace period configured. A setting in Error therefore silently protects a device until the calculation settles or the timeout expires.
Can I use compliance without Enterprise version licensing?
Yes — Intune compliance does not require Microsoft Entra ID, so compliance policies and their status views work on any Intune subscription. Conditional Access, which is what actually enforces 'device must be marked as compliant', requires Microsoft Entra ID P1 or P2. Windows Autopilot and co-management carry the same Entra ID P1/P2 requirement.
Related tools
- IPv4 subnet calculator — break any CIDR block into network, range, broadcast and usable hosts.
- IP range to CIDR — turn an arbitrary address range into its minimal covering CIDR blocks.
- VLSM calculator — split a block into right-sized subnets by host requirements.