Compliance policies, grace periods and the Conditional Access link

A compliance policy evaluates a device against rules — encryption enabled, minimum operating system version, antivirus running — and records a state. On its own that state is a report, and nothing acts on it.

The state becomes an access control when a Conditional Access policy requires a compliant device. That connection is one control in one policy, and it is simultaneously the most useful device security control available in Microsoft 365 and the fastest route to a self-inflicted outage.

Requirements

Devices must be enrolled and evaluated. A device Intune does not manage has no compliance state from Intune.

Intune licensing, and Entra ID P1 or above for Conditional Access.

A decision about devices with no policy assigned. This is the setting people miss and it is the single most consequential one in the whole subject. It is a tenant-wide compliance policy setting, and it determines whether a device with no compliance policy assigned is treated as compliant or not compliant.

The secure value is not compliant. The value that will not lock anyone out unexpectedly is compliant. Whichever you choose, choose it deliberately and know which one is set before you enable any Conditional Access policy requiring compliance — because a tenant set to “not compliant” with policies assigned to only some devices will block everything else the moment you turn enforcement on.

Design: the policy itself

Keep compliance policies focused on things that genuinely describe device health and that you are prepared to block access over.

Reasonable starting rules for Windows:

• BitLocker enabled and Secure Boot required.
• A minimum operating system version, expressed as a floor you actually maintain.
• Antivirus and real-time protection running.
• Firewall enabled.
• Defender for Endpoint machine risk score at or below a threshold, where you have it — this is the rule that makes compliance dynamic rather than static, because a device’s state changes when it is actually attacked.

Be cautious about rules that are strict but weakly related to security. A minimum operating system version set aggressively will mark devices non-compliant during every update cycle, which trains people to treat non-compliance as noise.

Actions for non-compliance, and the grace period

This is the mechanism that makes enforcement survivable.

By default, marking a device non-compliant happens immediately. You can instead configure actions for non-compliance with a schedule, so that the device is given a number of days before it is marked non-compliant, and you can add actions in the interim:

• Send an email to the user, after a set number of days, telling them what is wrong.
• Send a push notification.
• Remotely lock, or retire, for the extreme cases.
• Mark the device non-compliant after a grace period.

A grace period of a few days, with a notification on day one, converts “you are locked out this morning” into “your device needs attention by Friday”. The difference in service desk load and in user experience is substantial, and it costs nothing in security posture for the vast majority of rules.

Use a grace period for every rule where a device can plausibly become non-compliant through normal operation — operating system version, antivirus definition state. Use immediate marking only where the condition genuinely warrants immediate loss of access.

Deployment: connecting it to Conditional Access, safely

1. Confirm the tenant-wide setting for devices with no compliance policy assigned. Know which way it is set.
2. Create and assign the compliance policies, to all the device populations you intend to cover. Every platform you support needs its own policy — a Windows-only policy in a tenant with Macs and phones leaves those devices covered by the tenant-wide default.
3. Configure grace periods and notification actions.
4. Wait and read the compliance reports. Not a day; a full cycle. Look at how many devices are non-compliant and for what reason. Every one of them is a user who would be blocked.
5. Fix the systemic causes of non-compliance before enforcing. If forty per cent of devices fail a rule, the rule or the estate is wrong, and enforcing will not fix either.
6. Create the Conditional Access policy in report-only mode, requiring a compliant device, with emergency access accounts excluded. The full discipline is in Conditional Access baselines, and it applies without modification here.
7. Read the report-only results, specifically the sign-ins that would have been blocked.
8. Enable for a pilot group, then widen in stages.

Step 4 is the step that prevents the outage, and step 5 is the one people skip because it is the one that takes actual work.

The circular dependency to check for

A device that is not yet enrolled cannot be compliant. If a Conditional Access policy requires a compliant device for the applications needed to enrol a device, new devices cannot be provisioned at all.

This breaks Autopilot, as described in Windows Autopilot enrolment failures, and it breaks any new starter’s first sign-in. Check your policy’s application scope for it explicitly, because the failure appears well after the policy was enabled — on the day someone next sets up a device.

Validation

• A compliant device reaches the protected resources.
• A deliberately non-compliant test device is blocked — confirm the negative case, because a policy scoped to an empty group blocks nothing and looks identical to one that is working.
• The grace period behaves as configured: the device is marked non-compliant after the interval, not immediately, and the notification arrives.
• A newly provisioned device can complete enrolment and become compliant without being blocked en route.
• Emergency access accounts still work.
• Devices on each platform you support are evaluated by a policy, not falling through to the tenant default.

Operations

Watch the non-compliance reasons, not the percentage. The percentage is a number for a slide. The reasons tell you what to fix.

Give the service desk a runbook for the common reasons, so a blocked user is a five-minute call rather than an escalation.

Review the rules periodically. A minimum operating system version set two years ago is either irrelevant now or blocking everyone, depending on which direction you forgot to move it.

Re-check after adding a platform or a device population. A new group of devices without an assigned compliance policy falls to the tenant-wide default, which may block them instantly.

Rollback

Set the Conditional Access policy to report-only or off. That removes the enforcement immediately, and it is why the emergency access accounts must exist and must be tested — you need an administrator who can sign in to make that change.

Compliance policies themselves can be unassigned, which returns devices to the tenant-wide default — note that this may make them less compliant rather than more, if the default is “not compliant”. Removing a compliance policy is not a neutral act.

Verification and limits

Compliance policy evaluation, the tenant-wide setting for devices with no policy assigned, actions for non-compliance including scheduled notifications and grace periods, and the Conditional Access requirement for a compliant device were checked against current Microsoft documentation on 20 September 2026. The deployment sequence and the rule selection advice are my own practice.

No policies were configured for this article. Connecting compliance to Conditional Access can block access for every user in scope the moment it is enabled — confirm the tenant-wide default first, run report-only through a full cycle, fix systemic non-compliance before enforcing, and keep tested emergency access accounts excluded. Settings and platform support change between releases; confirm current behaviour in your own tenant.

References

• Device compliance policies in Microsoft Intune
• Actions for noncompliance
• Require a compliant device with Conditional Access
• Monitor device compliance