Intune Device Compliance Policies: Zero to Production · CloudEngineerHub
Endpoint Management10 min read4 views
Intune Device Compliance Policies: Zero to Production
Build production-grade Intune compliance policies: settings per platform, actions for noncompliance, grace periods, Conditional Access wiring, and rollout rings.
C
CloudEngineerHub Team
Published: September 7, 2026· Last Updated: September 28, 2026·10 min read
Intune Device Compliance Policies: Zero to Production
Device compliance policies are the backbone of conditional access in a Microsoft Intune estate: they turn "is this device healthy?" from a question into an enforced gate. Unlike configuration profiles, which change device behavior, compliance policies evaluate device state and feed a verdict — compliant or noncompliant — that Entra Conditional Access, conditional launch rules, and reporting can act on.
Visual Walkthrough
Grace periods decoded: when "non-compliant" actually cuts access.
Decision TreeCompliance → Conditional Access — The Handshake5/5
Decision gate
Device evaluates compliance
Compliance is a signal; Conditional Access is the consequence.
Compliant
1
All settings pass
Encryption, AV health, OS version, jailbreak checks green.
2
Device marked compliant
State published to Entra for CA to consume.
3
CA grants access
Mail/files open — the compliant experience is frictionless.
Non-compliant
1
Grace period runs
Actions: mark non-compliant after N days — a designed buffer.
Compliance → Conditional Access — The Handshake. Gate: Device evaluates compliance — Compliant: All settings pass — Compliant: Device marked compliant — Compliant: CA grants access — Non-compliant: Grace period runs — Non-compliant: User notified — Non-compliant: CA blocks after grace — Non-compliant: Remediation restores
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
This guide takes you from an empty tenant to a production compliance model: what to evaluate per platform, how actions for noncompliance and grace periods really behave, how to wire compliance into Conditional Access without locking out the fleet, and how to operate the whole system day to day.
Prerequisites
Microsoft Intune licenses for targeted users, with Intune configured as the MDM authority.
Enrolled devices per platform: Windows 10/11, iOS/iPadOS, Android Enterprise, or macOS — compliance policies are per-platform.
Microsoft Entra ID with Conditional Access available (Entra ID P1) if you intend to gate access on compliance.
A compliance baseline agreed with security: minimum OS versions, encryption, firewall, Defender requirements, and password rules.
Reporting access in intune.microsoft.com under Devices > Monitor for compliance state tracking.
How It Works
A compliance policy is evaluated on the device and reported back through the MDM channel. Intune computes a compliance state — compliant, noncompliant, in grace period, or not evaluated — and publishes it to Entra ID, where Conditional Access can consume it as a grant control ("Require device to be marked as compliant"). The evaluation model is deliberately simple: every setting in the policy must pass for the device to be compliant; there are no partial scores.
Two concepts confuse almost every implementation:
Compliance vs configuration: a configuration profile makes the device do something; a compliance policy checks whether something is true. If you require BitLocker via compliance policy on a device where encryption was never enabled, that device becomes noncompliant — the policy does not enable it.
Actions for noncompliance and grace periods: when a device falls out of compliance, the scheduled actions run in order. The built-in default action marks the device noncompliant, and its schedule defines the grace period. Email notifications and remote lock can warn the user before that deadline passes.
Step-by-Step Implementation
Step 1: Define the Baseline Per Platform
Work with security to write the minimum acceptable state per OS: encryption on, Secure Boot and code integrity for Windows, minimum OS version that receives security patches, screen lock requirements, and Defender health. Keep the first version small — five to eight settings beats a forty-line policy nobody can troubleshoot.
Step 2: Create the Windows Compliance Policy
In intune.microsoft.com go to Endpoint security > Device compliance > Create policy, choose Windows 10 and later. Add device properties: require BitLocker, require Secure Boot, require code integrity, set the minimum OS build, require a password or PIN with a minimum length, and require Microsoft Defender Antivirus at or above the current security intelligence version.
Step 3: Create Policies for iOS/iPadOS and Android Enterprise
Repeat per platform: minimum OS version, jailbroken/rooted devices marked noncompliant, maximum OS version only if your security team insists (it creates churn on update day), and passcode requirements. For personally owned Android Enterprise devices, target the work profile compliance surface.
Step 4: Configure Actions for Noncompliance
On each policy, open Actions for noncompliance. Keep the default Mark device noncompliant at 0 days if you want immediate enforcement for corporate devices, or set a grace period (for example, 3 days) for personal and field fleets. Add Send email to user ahead of the deadline and, where justified, remote lock.
Step 5: Assign and Pilot
Assign the policies to a pilot group with both corporate and personally owned devices. Check Devices > Monitor > Compliance for the state distribution and verify that noncompliant devices show the exact failing setting — the per-device compliance view names the rule.
Step 6: Wire Conditional Access and Go to Production
Create or update a Conditional Access policy that requires compliant devices for Exchange Online, SharePoint, and your sensitive apps. Exclude break-glass accounts, roll out in rings alongside your compliance policy assignments, and publish user guidance describing what happens on update day when old OS versions fall below the minimum.
Configuration Deep Dive
Grace period semantics: the grace period is the delay on the Mark device noncompliant action. During the window the device reports in grace period, not compliant — Conditional Access treats in-grace as compliant unless your CA policy additionally blocks that state. Communicate this clearly to security teams who expect hard enforcement at second zero.
Minimum OS strategy: pin the minimum OS version to the oldest release still receiving security updates, and automate raising it the week after each wave completes. Compliance policies are the cleanest mechanism to force OS currency over time.
Device health attestation: BitLocker, Secure Boot, and code integrity checks rely on Windows health reporting; ensure TPM-backed attestation is available on the fleet or these rules will read as unknown.
Personal vs corporate split: use device ownership and scope tags to run stricter rules on corporate devices and a pragmatic subset on BYOD, so personally owned devices are not retired by accident via remote actions.
Evaluation cadence: devices evaluate compliance on check-in and at intervals driven by the MDM schedule; a device that went offline reports stale state, which is why a "last check-in" column belongs in every compliance review.
Real-World Enterprise Scenario
A 6,500-seat financial services firm needed compliant-device Conditional Access for its M365 estate within one quarter. The endpoint team shipped Windows and iOS compliance policies with encryption, minimum OS, and Defender requirements; set a 3-day grace period with email warnings; and piloted on 250 devices. The pilot surfaced one surprise: 40 legacy Windows 10 devices without TPM attestation reported unknown health, which the team remediated by moving those devices to a hardware refresh wave instead of relaxing policy. After two rings, they enabled Require device to be marked as compliant for SharePoint and Exchange Online. Noncompliance peaked at 6 percent during the first update deadline and settled under 1 percent, with the email action eliminating nearly all user complaints.
PowerShell for Intune Device Compliance
Audit policies and the noncompliant population with Microsoft Graph:
PowerShell
1
2
3
4
5
6
Connect-MgGraph -Scopes'DeviceManagementConfiguration.Read.All'# List all device compliance policies with assignment state$policies = Invoke-MgGraphRequest -Method GET -Uri"https://graph.microsoft.com/beta/deviceManagement/deviceCompliancePolicies"$policies.value | Select-Object displayName, id | Format-Table
# Expected output: one row per policy, for example 'Windows 11 Compliance - Corporate' plus the policy id
PowerShell
1
2
3
4
5
6
Connect-MgGraph -Scopes'DeviceManagementManagedDevices.Read.All'# Report noncompliant devices and their grace period deadline$noncomp = Invoke-MgGraphRequest -Method GET -Uri"https://graph.microsoft.com/beta/deviceManagement/managedDevices?`$filter=complianceState eq 'noncompliant'&`$select=deviceName,userPrincipalName,osVersion,complianceGracePeriodExpirationDateTime"$noncomp.value | Format-Table deviceName, userPrincipalName, osVersion, complianceGracePeriodExpirationDateTime
# Expected output: one row per noncompliant device; devices inside their grace window show a future deadline
Troubleshooting
Symptom
Likely Cause
Fix
Device shows noncompliant with no clear reason
A hidden setting (often OS build or security intelligence version) fails
Open the per-device compliance report; it lists the exact failing rule and observed value
Devices report compliance state "not evaluated"
Policy not assigned, or device stopped checking in
Confirm assignment groups, check last check-in time, trigger a sync from the device
Users blocked by Conditional Access during grace period
CA policy also blocks the in-grace state, or deadline already passed
Review CA policy design and the noncompliance action schedule
BitLocker rule fails on capable hardware
Encryption was never enabled; compliance does not enable it
Deploy an encryption configuration profile first, then let compliance verify it
iOS devices flip noncompliant after OS update
Maximum OS version rule or stale minimum pinned too low
Remove maximum OS rules; update the minimum version as part of the release wave
Compliance email notifications not delivered
Mail flow or group scoping issue
Verify SMTP connectors (Exchange Online) and that targeted users hold valid licenses
Visual Walkthrough
Watch a policy travel from console to device and back as compliance telemetry.
Settings Catalog, template or ADMX ingestion — the console is the single source of intent.
targets
2
Assign with targeting
Device or user groups, filters include/exclude, optional scope tags for RBAC.
check-in
3
Device checks in
Push notification or the 8-hour scheduled cycle wakes the MDM channel.
4
CSP evaluation
Enterprise policy hits the Configuration Service Provider; unsupported settings are skipped, not fatal.
telemetry
5
State reports back
Per-setting success/error lands in Intune reports within minutes of check-in.
continuous
6
Drift re-mediated
Next cycle re-applies the intent — the loop keeps the fleet converged.
The Intune Policy Lifecycle — Console → Device → Telemetry. 1. Author the policy: Settings Catalog, template or ADMX ingestion — the console is the single source of intent. — 2. Assign with targeting: Device or user groups, filters include/exclude, optional scope tags for RBAC. — 3. Device checks in: Push notification or the 8-hour scheduled cycle wakes the MDM channel. — 4. CSP evaluation: Enterprise policy hits the Configuration Service Provider; unsupported settings are skipped, not fatal. — 5. State reports back: Per-setting success/error lands in Intune reports within minutes of check-in. — 6. Drift re-mediated: Next cycle re-applies the intent — the loop keeps the fleet converged.
Common Errors
"Device does not meet the minimum OS build": the fleet lagged behind the pinned minimum. Raise minimums on the wave schedule, not in an emergency change.
"Require encryption: failed" on Windows: BitLocker suspended or device upgraded without encryption. Redeploy the encryption profile and re-encrypt.
"Jailbroken/rooted device" on iOS/Android: expected hard failure. Remove the device from service or accept the block per policy.
Compliance "unknown": health attestation unavailable or MDM check-in stale; troubleshoot enrollment and connectivity before touching the policy.
Best Practices
Start with a small, defensible baseline and grow it; sprawling day-one policies generate noise, not security.
Give every policy a clear owner and naming convention (platform, scope, intent) so audits are easy.
Use email actions and grace periods deliberately: corporate fleets can enforce immediately; BYOD needs warning time.
Raise minimum OS versions on a calendar that follows your update rings, automating currency instead of negotiating it each quarter.
Review the noncompliant device report weekly during rollout and monthly in steady state; trends matter more than snapshots.
Keep break-glass accounts excluded from CA compliance requirements, tested and documented.
Security Considerations
Compliance states feed Conditional Access — protect the compliance policy surface with scoped RBAC roles like any privileged configuration.
Be careful with remote actions on personal devices: retire on a BYOD device removes org data, but misconfiguration can cause unexpected data loss and legal exposure.
Enforce Defender security intelligence currency as part of compliance to keep endpoint protection from silently aging out.
Monitor for devices stuck "in grace period" indefinitely — they are effectively exempt from policy and should be investigated or retired.
FAQ
Q: Do compliance policies apply to devices without users?
A: Compliance policies are user-targeted in their classic model; device-only scenarios (kiosks, shared devices) need careful assignment design, often via device groups and policies that do not depend on a primary user.
Q: Is a device compliant during its grace period?
A: It reports in grace period, which Conditional Access normally treats as compliant. Some CA designs add explicit controls; test the exact behavior with your policies.
Q: Can compliance policy enable BitLocker?
A: No. It only checks. Deploy encryption via a configuration profile (or endpoint security disk encryption policy) and let compliance verify the result.
Q: How often is compliance re-evaluated?
A: On every check-in and on the policy evaluation schedule; a device that has not checked in ages on stale data until it reconnects or is synced remotely.
Q: What is the difference between compliance state and Windows security updates?
A: Updates are content you deploy; compliance is the verdict. A device can be fully patched yet noncompliant for encryption, and vice versa.
Conclusion
Compliance policies are small artifacts with outsized consequences: they are the hinge between device health and Conditional Access. Build the baseline with security, keep the first policy set lean, use grace periods and email actions to convert enforcement into communication, and automate minimum OS currency. Do that, and "require compliant device" becomes a control you can actually enforce across the fleet without a support storm.
Comments
0No comments yet — be the first to share your thoughts.