Blog
Intune compliance policies: how to configure and enforce them
Learn how to configure Intune compliance policies, enforce them with Conditional Access, and govern physical and cloud desktops.
Table of Contents
- What an Intune compliance policy does (and what it doesn't)
- Two tenant-wide settings decide what your policies mean
- How to create a Windows compliance policy step by step
- Enforcement runs through Conditional Access
- Windows 365 and Azure Virtual Desktop need separate compliance tracks
- Custom compliance covers settings the built-in templates miss
- Governing compliance policies at enterprise scale
- Where Nerdio Manager fits across Windows 365, Intune, and Azure Virtual Desktop
- Three settings to check this week
- Frequently asked questions about Intune compliance policies
Out of the box, Microsoft Intune marks devices with no compliance policy assigned as Compliant. That one default means an enrolled device with no policy at all passes a Conditional Access check that requires a compliant device.
Enforcement lives in the chain from device to Microsoft Entra ID to Conditional Access, and several links require deliberate configuration.
This guide is for enterprise Intune administrators and governance leads configuring device compliance across physical endpoints and Windows Cloud (Microsoft's umbrella term for Windows 365 and Azure Virtual Desktop).
What an Intune compliance policy does (and what it doesn't)
Microsoft defines compliance policies as "sets of rules and conditions that you use to evaluate the configuration of your managed devices." A compliance policy reads device state, compares it against your rules, and reports a compliant or noncompliant status. It never pushes a setting to the device.
Intune splits compliance into two parts:
- Compliance policy settings are tenant-wide configurations that "act like a built-in compliance policy that every device receives."
- Device compliance policies are platform-specific rule sets you assign to groups. Supported platforms include Windows 10 and later plus macOS. Intune also supports iOS/iPadOS, Android, and Linux.
That evaluate-and-report role separates compliance policies from the mechanisms they get confused with most. Configuration profiles push and enforce device settings, including Wi-Fi and VPN. They also cover certificates and BitLocker enforcement. Security baselines are groups of preconfigured Windows settings, which makes them a configuration mechanism, not a compliance one.
Both are part of broader unified endpoint management. When a compliance policy and a configuration profile evaluate the same setting, the compliance policy wins. Per Microsoft: "Compliance policy settings always have precedence over configuration profile settings."
|
Dimension |
Compliance policy |
Configuration profile |
Security baseline |
|
Pushes settings to the device |
No |
Yes |
Yes |
|
Reports compliance status to Entra ID |
Yes |
No |
No |
|
Conditional Access role |
Direct signal |
Indirect |
Indirect |
A policy that only reports is only as good as what consumes the report, and as what your tenant does with devices that have no report at all. Two tenant-wide settings decide that, which is why they belong at the front of the build.
Two tenant-wide settings decide what your policies mean
Two tenant-wide settings determine how Intune treats unassigned and stale devices. Both settings live under Endpoint security > Device compliance > Compliance policy settings in the Intune admin center.
"Mark devices with no compliance policy assigned as" defaults to Compliant. Microsoft's recommendation for organizations using Conditional Access is to change it to Not compliant, so only devices confirmed compliant reach corporate resources.
Operationally, that setting determines whether an enrolled device without a policy counts as compliant or must earn that status. That switch only lands safely once every production device already has a policy assigned. If admins flip it first, unassigned devices start failing Conditional Access checks the same afternoon.
"Compliance status validity period" defaults to 30 days and is configurable from 1 to 120. When a device fails to report compliance for a policy before the period expires, Intune treats it as noncompliant. Shorter windows catch stale devices faster, while longer windows tolerate laptops that live in drawers.
How to create a Windows compliance policy step by step
Intune evaluates targeted devices when they check in, and a new policy can take up to 24 hours to show reporting data for online devices. The build itself takes minutes:
- Navigate: Sign in to the Microsoft Intune admin center, go to Devices > Compliance, and select Create policy.
- Pick the platform: Select Windows 10 and later.
- Name it: Use a convention that encodes platform and purpose. Clear names tell an admin the scope and impact before they touch anything.
- Configure compliance settings: Device properties sets minimum and maximum OS version (Windows 11 builds take an 11.0 prefix); System security covers password requirements to unlock the device.
Device health and Defender integration carry the rest:
- Device health covers Require BitLocker and Require Secure Boot; Require code integrity is configured there as well. Intune measures BitLocker state at boot, so a device becomes compliant only after a reboot once encryption completes. Microsoft's Zero Trust guidance sets all three to Require.
- Microsoft Defender for Endpoint adds "Require the device to be at or under the machine risk score," with four values from Clear (most secure) through Low and Medium to High.
- Set actions for noncompliance: Every policy includes Mark device noncompliant at zero days. You can't remove it, but you can delay it (that delay is the grace period). Optional actions include emailing the user from a template. Company Portal can send a push notification, and admins can also remotely lock the device.
- Assign: Add Microsoft Entra groups, with include and exclude support. Target device groups rather than user groups for Surface Hubs and bulk-enrolled devices; device targeting also prevents an Enrollment Status Page timeout when Conditional Access requires compliance during Windows enrollment.
- Review and create.
After creation, admins can monitor from the policy's Monitor tab under Devices > Compliance, which offers a device status chart plus per-setting status reporting. Intune reporting retention caps how far back that view goes.
Native Intune reporting retains compliance data for 30 to 90 days, while Nerdio Manager for Enterprise extends that window to 180+ days, which matters when an auditor asks about last quarter.
The policy now produces a status. Turning that status into blocked access happens outside Intune entirely.
Enforcement runs through Conditional Access
A compliance policy only produces a status. Conditional Access is what turns that status into blocked access, and the way it handles grace periods and error states determines how long a failing device keeps reaching corporate resources.
Conditional Access reads compliance status from Entra ID
When a device enrolls in Intune, it registers in Microsoft Entra ID, and Intune reports its compliance status there. A Conditional Access policy with the grant control "Require device to be marked as compliant" uses that status to allow or block access. Device-based Conditional Access requires Microsoft Entra ID P1 or P2. Intune compliance on its own does not enforce access.
Microsoft warns about the build order: "Without a compliance policy created in Microsoft Intune, this Conditional Access policy won't function as intended." The safe sequence is compliance policy first, one confirmed compliant device, then the grant control.
Once the chain is wired up, the next thing to understand is what happens when a device doesn't pass.
Grace periods keep failing devices connected
Delaying the Mark device noncompliant action past zero days gives users time to remediate. The device reports InGracePeriod to Entra ID during that window, and Conditional Access does not treat InGracePeriod as noncompliant. The device keeps its access to protected resources the entire time it is failing your rules. A grace period is an access decision, and it deserves the same review rigor as the Conditional Access policy itself.
The Error state can extend access past a week
An Error state stretches the access window further. When a device carries multiple compliance policies, Intune assigns the highest-severity status of the set. The severity ladder runs from Unknown through NotApplicable, Compliant, InGracePeriod, and NonCompliant to Error at the top.
A setting that returns Error leaves the device's existing compliance state unchanged for up to seven days while the calculation retries (per Microsoft's guidance on monitoring device compliance). If the Error persists past seven days, Intune marks the device Not compliant, or In grace period when the policy includes one. Combining an Error state with a grace period means a failing device can retain access for well over a week without anyone deciding it should.
This enforcement chain assumes every device can evaluate the same settings. That assumption breaks down on cloud desktops, where reused policies can quietly misfire.
Windows 365 and Azure Virtual Desktop need separate compliance tracks
Many enterprises run both Windows 365 and Azure Virtual Desktop alongside physical endpoints, and Intune treats each differently for compliance.
Windows 365 Cloud PCs
Admins manage Cloud PCs through the Intune admin center like any other endpoint, and Microsoft recommends pairing compliance policies with Conditional Access for them. This makes Intune for Windows 365 central to Cloud PC management.
Microsoft also documents one exception: "Cloud PCs don't support BitLocker. We recommend excluding this setting from compliance policies targeting Cloud PCs." Reusing your physical-endpoint policy unmodified causes every Cloud PC in the estate to report noncompliant on a setting it can never satisfy.
Misconfiguration cuts the other way too. Conditional Access policies requiring a compliant device will sever connections when a virtual machine has recently lost its Intune compliance state.
Azure Virtual Desktop personal host pools
Intune treats personal Azure Virtual Desktop VMs "the same as Windows Enterprise physical desktops," with the full Windows compliance surface and Conditional Access support. Existing physical-endpoint policies largely carry over, and Intune management doesn't interfere with Azure Virtual Desktop management of the same VM.
Azure Virtual Desktop multi-session hosts
Multi-session hosts evaluate a restricted subset of compliance settings. Intune supports the following settings on multi-session hosts.
- OS version rules
- password policies
- Microsoft Defender antimalware status and version
- antivirus and antispyware status
- firewall and real-time protection
- Defender risk score
Everything else reports Not applicable. Compliance policies for multi-session must target device groups because Intune doesn't support user-targeted compliance configurations for these hosts. Conditional Access, by contrast, supports both user and device configurations.
Compliance reports also display the state of the last user who checked in, so a pooled host's report can reflect a previous user's session. These constraints are central when teams manage multi-session hosts. Intune also doesn't support enrolling cloned images of already-enrolled machines, which trips up golden image workflows that clone an enrolled VM.
A mixed estate therefore needs separate compliance policy tracks. One track covers physical and personal endpoints. Cloud PCs need a track with BitLocker excluded, while multi-session hosts need device-targeted policies. That multiplies the policy objects to keep aligned, and it still only covers settings Intune's built-in templates expose.
Custom compliance covers settings the built-in templates miss
Intune's built-in compliance templates only expose a fixed set of device properties. When you need to check something they don't cover, custom compliance fills the gap by running your own PowerShell script on the device and comparing the results against a JSON file that defines expected values and remediation messages.
Each custom compliance policy supports a single script, though that one script can check multiple settings. Intune runs discovery scripts every eight hours. A user selecting Check Compliance triggers the script but won't fetch a new or updated one, and push notifications can't force a run on demand.
Supported platforms are Windows, macOS, and Linux. Microsoft documents examples that check BIOS version and TPM chip presence, and a community example shows how PowerShell can check Microsoft 365 app installation through registry or file-system data.
The flexibility has an operational cost. Every custom policy is another script to author, version, and maintain alongside the JSON file that pairs with it, and it shares the same maintenance overhead as broader Intune script deployment workflows. Every custom script also becomes one more policy object in a tenant that has no hierarchy to organize them.
Governing compliance policies at enterprise scale
Intune has no policy hierarchy. Per Microsoft's planning guide, "policies are applied to users and groups you create. There isn't a hierarchy. If two policies update the same setting, then the setting shows as a conflict." Without a hierarchy to resolve overlaps, large tenants sprawl into competing policies, and the following conflict rules govern which setting wins:
- Compliance conflicts: When a compliance policy and a configuration policy address the same setting, the compliance policy's setting wins, "even if the settings in the configuration policy are more secure" (per the previously cited guidance on monitoring device compliance). When two compliance policies conflict, the most restrictive setting applies automatically.
- Configuration conflicts: When two configuration policies conflict, Intune flags the conflict and you resolve it manually.
Multi-admin approval has supported device compliance policies since Intune's February 2026 service release. Changes to compliance policies, including their creation or deletion, require a second administrator's approval before they take effect, appropriate for objects that drive Conditional Access decisions.
Scope tags also need to stay in their lane. Scope tags constrain which admins can see and manage objects. Assignment filters control which devices receive a policy. Confusing the two can leave a compliance policy looking correctly configured in the portal while never reaching its intended devices.
The Devices > Monitor > Noncompliant devices report supports filtering and per-device drill-down, but the documented conflict investigation workaround is a manual, per-device walk through setting names and profiles.
These are common Intune challenges for enterprises. For governance, risk, and compliance (GRC) leads, that reported compliance status is the audit artifact they're asked to produce. That manual workflow creates a case for automating Intune compliance policies rather than clicking through them one at a time.
Where Nerdio Manager fits across Windows 365, Intune, and Azure Virtual Desktop
Nerdio Manager lets admins create and assign Intune compliance policies from the Nerdio console, manage configuration policies and baselines in the same place, and back up or roll back any of them. The same console covers Windows 365 Cloud PCs, Intune, and Azure Virtual Desktop session hosts, with Intune management with Nerdio in one view.
- Policy versioning and backup
Nerdio Manager keeps version control with rollback to previous versions. It also supports policy backups, so admins can return a compliance policy feeding Conditional Access to a known-good state during an audit or after a bad edit. - One workflow across Windows Cloud
The same policy workflow covers Cloud PCs, including the BitLocker-excluded track, Azure Virtual Desktop session hosts alongside desktop orchestration, and the physical-endpoint policies that sit beside them. - Reporting that outlasts the native window
Extended retention feeds compliance status, configuration drift, app status, and patch status into a single dashboard. - RBAC
Role-based access control provides granular module permissions.
Sparta Services, a managed service provider (MSP), reported 70-80% efficiency gains using Nerdio.
For a GRC lead, the compliance status, its version history, and its retention window all sit in one place when the audit request arrives.
Three settings to check this week
- After confirming every production device has a policy, set "Mark devices with no compliance policy assigned as" to Not compliant.
- Audit every grace period, including policies prone to Error states that can extend the access window past seven days.
- Verify cloud desktop targeting: exclude BitLocker from Cloud PC policies and target multi-session policies to device groups.
If those checks mean bouncing between the Microsoft admin portals and per-host-pool views, that portal-hopping is the operational burden worth reducing next. You can get a demo to see how Nerdio Manager handles compliance policy work across your Windows 365 and Azure Virtual Desktop environment, or try it free in your Azure tenant.
Frequently asked questions about Intune compliance policies
Resources
Learn more about Nerdio Manager
