Compliance policies are the bridge between Intune configuration and Conditional Access enforcement. Before you build individual policies, two tenant-wide settings need to be set correctly – and most environments have them wrong by default.
Tenant-wide compliance settings first
In Intune, go to Endpoint security → Device compliance → Compliance policy settings. Two settings here govern the baseline behavior of compliance across your entire tenant.
The first is “Mark devices with no compliance policy assigned as.” The default is Compliant. This means any device that doesn’t have a compliance policy targeting it is automatically considered compliant and passes compliance-based Conditional Access checks. That’s permissive to the point of being a gap – it means new enrollments, miscategorized devices, or devices that fall out of your group assignments silently appear compliant without being evaluated. Change this to Not Compliant. Any device that needs to be compliant should have a policy assigned to it. If it doesn’t, it should be questioned, not assumed fine.
The second is the compliance status validity period, which defaults to 30 days. This is the window a device has to check in and report its compliance state before Intune marks it as inactive and therefore non-compliant. 30 days is reasonable for most environments. Tightening it to 7 or 14 days increases security but risks blocking remote or intermittently connected devices. Whatever you choose, document it and align your Conditional Access grace periods accordingly.
Devices without a compliance policy should be non-compliant by default, not compliant. The default setting is wrong. Fix it before you build anything else.
What to put in a Windows compliance policy
A compliance policy is not the place to configure security settings – that’s what configuration profiles and endpoint security policies are for. Compliance policy evaluates whether those settings are in place and reports the result. The distinction matters because a compliance policy set to “Require BitLocker” doesn’t enable BitLocker – it checks whether BitLocker is already on and marks the device non-compliant if it isn’t. The encryption has to be configured separately through an endpoint security policy.
For a Windows compliance policy, a reasonable baseline set of checks covers: minimum OS version, BitLocker encryption required, Defender antivirus enabled and up to date, Secure Boot enabled, and TPM required. These are the conditions that represent a minimally trustworthy device state. If any of them aren’t true, the device shouldn’t be passing compliance-gated Conditional Access checks.
Minimum OS version is worth setting explicitly. Specify the minimum build you’re willing to accept in production – typically the most recent supported Windows 11 or Windows 10 release your OIB baseline targets. Devices below that version report non-compliant and users are prompted to update. This creates a natural enforcement mechanism for keeping your fleet current without requiring manual remediation campaigns.
The MDE machine risk score setting – Require the device to be at or below machine risk score – is available in compliance policy but treat it with caution in this context. The architecture article covered why: devices that haven’t checked in to MDE for seven or more days receive a spurious risk score that marks them non-compliant. Remote devices, devices that were offline over a long weekend, and devices running in environments with intermittent connectivity can all trigger this. If you enable it, set the threshold to Medium rather than Low, and monitor your compliance reports carefully in the first few weeks to understand the false positive rate in your environment.
Actions for noncompliance
Every compliance policy has an “Actions for noncompliance” section. By default, Intune marks a device non-compliant immediately – zero days – when it fails a compliance check. Once marked non-compliant, Conditional Access can block it. That immediate marking is appropriate for mature environments where devices are stable and the compliance settings are well-understood. For new deployments, it can cause disruption.
The grace period works by changing the “Mark device noncompliant” action from zero days to a number of days after the compliance failure is detected. During that window, the device shows as “In grace period” in compliance reports – it’s non-compliant, but Conditional Access treats it as compliant. Once the grace period expires, the device is marked non-compliant and Conditional Access enforcement kicks in.
A useful pattern for new deployments: set a short notification action – send an email to the user at day one – and set the non-compliant marking at day three or seven. This gives users time to remediate on their own before their access is blocked, reduces helpdesk volume on rollout day, and still closes the security gap within a week. Once the environment is stable and compliance rates are high, tighten the grace period.
One specific grace period consideration: BitLocker encryption takes time to complete after a device enrolls, particularly on large drives. A device that’s just enrolled will fail the BitLocker compliance check immediately because encryption hasn’t finished yet. A grace period of a few hours – configured via Graph API using decimal fractions like 0.25 for 6 hours – gives encryption time to complete without blocking the user’s access from day one. The admin center doesn’t support sub-day grace periods directly, but Graph does.
Assignment and monitoring
Assign compliance policies to device groups, not user groups, wherever possible. Device-targeted compliance is cleaner – it ties the compliance state to the device object, which is what Conditional Access evaluates. User-targeted compliance evaluates all of the user’s devices, which can produce confusing compliance states when a user has both managed and unmanaged devices.
After assigning a compliance policy, monitor it. The Device compliance dashboard in Intune shows compliant, non-compliant, in grace period, and not evaluated counts across your fleet. “Not evaluated” devices are the ones to investigate first – they typically represent devices that haven’t checked in recently, devices that don’t have the policy assigned correctly, or newly enrolled devices that haven’t had their first compliance evaluation yet.
Don’t enable Conditional Access enforcement on a compliance policy until you’ve verified that a representative sample of devices actually evaluates as compliant. Deploy the compliance policy, wait for a check-in cycle, review the compliance report, fix whatever’s driving non-compliance in your environment, and only then point Conditional Access at the compliance signal. Enabling enforcement before checking the baseline will block people on day one.
Intune Deployment Guide · Phase 6: Compliance
‹ Previous: [6.1] Compliance Policies: The Signal That Feeds Conditional Access
Next: [6.2] Designing Compliance Rules That Mean Something ›
