The tenant-wide compliance settings and per-platform policies behind Intune compliance, and how a device's overall status is worked out.
From Ultra Transcenders MD-102 by Tony Rough (coming December 2026)
Intune compliance has two layers: tenant-wide compliance policy settings that every device receives, and platform-specific device compliance policies that you assign to groups. Knowing which setting lives in which layer avoids a lot of confusion. Figure 5.1 follows a device from policy evaluation to the access decision.
Compliance policy settings are configured in the Microsoft Intune admin center under Endpoint security > Device compliance > Compliance policy settings. They behave like a built-in policy that applies to every enrolled device.
| Setting | Values | Default | Why it matters |
|---|---|---|---|
| Mark devices with no compliance policy assigned as | Compliant, Not compliant | Compliant | With Conditional Access, set Not compliant so that only devices confirmed by a real policy get access |
| Compliance status validity period (days) | 1 to 120 | 30 | A device that doesn’t report on all its policies within this period is treated as noncompliant; shown as the Is active setting in reports |
Common trap: Assuming an unassigned device is blocked by a “require compliant device” Conditional Access policy - the tenant default marks devices with no compliance policy as Compliant, so the setting must be changed to Not compliant to close that gap.
Common trap: Looking for a tenant-wide jailbreak or “enhanced jailbreak detection” switch - the tenant-wide settings are only the two in the table; jailbreak and root detection are per-policy Device Health settings.
A device compliance policy is created under Devices > Compliance > Create policy, and each policy targets one platform: Android Enterprise (with a profile type of either fully managed, dedicated and corporate-owned work profile, or personally owned work profile), Android (AOSP), iOS/iPadOS, Linux, macOS or Windows 10 and later. Key facts:
When several compliance policies apply to one device, Intune assigns the status with the highest severity:
| Status | Severity |
|---|---|
| Unknown | 1 |
| NotApplicable | 2 |
| Compliant | 3 |
| InGracePeriod | 4 |
| NonCompliant | 5 |
| Error | 6 |
InGracePeriod appears when a device is noncompliant but the grace period created by a delayed Mark device noncompliant action is still in the future; once the date passes, the effective status becomes NonCompliant.
Compliance is evaluated when devices check in. Newly enrolled devices check in more often, then settle to roughly every eight hours (and no more than one maintenance sync every 6.5 hours):
| Platform | Estimated refresh after enrollment |
|---|---|
| Windows, Android, AOSP | Every 3 minutes for 15 minutes, every 15 minutes for 2 hours, then about every 8 hours |
| iOS/iPadOS, macOS | Every 15 minutes for 1 hour, then about every 8 hours |
Users can force a check from the Company Portal (Check status or Sync), and administrators can run a device Sync. On Windows, Intune also supports client-driven compliance evaluation: the Intune Management Extension watches compliance-related settings and real-time detection covers Firewall, Antivirus, BitLocker, Microsoft Defender status, OS build, real-time protection and Secure Boot, so a change triggers a check-in instead of waiting for the next cycle.
Common trap: Targeting compliance policies at Windows 8.1 devices - Intune support for Windows 8.1 ended on 22 October 2022, and even Windows 10 is only an “allowed” version after its end of support on 14 October 2025.
This note is one section of Ultra Transcenders MD-102: Managing and Securing Microsoft 365 Endpoints by using Intune, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in December 2026, in Kindle and paperback editions.
About the book · MD-102 terms in the glossary · All MD-102 study notes
How Microsoft Entra registered, Entra joined and hybrid joined devices differ in ownership, sign-in, management and the scenarios each one suits.
Which devices can back up a local admin password to Entra ID or Active Directory, and how to build the Windows LAPS policy in Intune.
The six ways Intune manages Android devices, from personal work profiles to fully managed, dedicated and AOSP, and how to choose between them.
How user-driven, pre-provisioned and self-deploying Autopilot modes differ in join type, user interaction and TPM requirements.
What each Enrollment Status Page setting does, from blocking apps and time limits to quality updates during OOBE, and where to create profiles.
Which Intune remote action keeps personal data and which resets the device, with platform support, wipe options and daily limits.
How Intune update rings set quality and feature update deferrals, deadlines, grace periods and restart behaviour for groups of Windows devices.
How Intune app protection policies protect work data inside apps on enrolled and personal devices, and the three-level data protection framework.