Intune compliance policy: why the status still lags after a sync

An Intune compliance policy does not report in real time, and the gap between a device becoming compliant and the console agreeing is wider than most administrators expect. Microsoft Learn puts the ceiling at up to 24 hours for a device that is online. A manual sync does not reliably close that gap, because what you are waiting for is a reporting round trip rather than a policy download. This post covers the documented timings, what the new client driven evaluation preview changes, and the places where it still leaves you waiting.

The reflex when a device shows the wrong state is to sync it. That is worth doing, and forcing an Intune sync comes with its own set of problems that look like failures and are not. A sync pulls policy down to the device. Compliance status travels in the other direction, and it is that return leg the dashboard is waiting on. Every fact below was re-verified against Microsoft Learn on 10 November 2026.

How long an Intune compliance policy takes to report

The number worth writing down sits in the monitoring documentation rather than anywhere near the compliance blade. Microsoft’s Monitor results of your device compliance policies article states that before a device appears in the compliance chart it must check in with Intune to receive the policy, process it, and successfully report its status, and that this process can take up to 24 hours when the device is online.

Twenty four hours. Not the eight hour figure everybody quotes, and not the few minutes people assume after clicking Sync. The eight hours is real, but it is one leg of the journey rather than the whole of it.

The check in cadence itself is documented separately, in the policy and profile refresh cycle times:

Microsoft revised the macOS row after this post first went out: it now matches the Windows and Android pattern for the first two hours and then reads around every hour, as published on 10 November 2026. Two statements in that article matter more than the table. The general check in schedule for all platforms is still given as about every 8 hours. And independent of the client schedule, devices are allowed only one maintenance sync every 6.5 hours. That floor is worth remembering when somebody suggests syncing the estate again because the first attempt changed nothing. The limit applies to the maintenance sync rather than to an administrator or user initiated sync action, so the button still does something, but the background cadence underneath it will not be hurried.

How long do Intune policies take to apply

For an online device, usually well inside the eight hour cycle, because that cycle is the fallback rather than the trigger. The same refresh cycle article describes change-based syncs: assigning, unassigning, updating or deleting a policy, profile or app, or a Microsoft Entra group membership change, makes Intune notify online devices to sync. Microsoft gives the notification time as anywhere from immediately up to a few hours, and says it varies between platforms.

Three things push a device back onto the slow path. An offline or powered off device might not receive the notification, so it waits for its next scheduled check in. Some changes, such as adding an app as available, do not send an immediate notification at all. And on Android, Microsoft calls out Google Mobile Services separately as something that can affect refresh intervals.

So the honest answer to how long Intune policies take to apply has three parts: immediately to a few hours for an online device after a change, around the scheduled check in if the notification is missed, and for an Intune compliance policy specifically, up to 24 hours before the result is reported. Those are three different clocks. Most forum threads on the subject quote one of them as if it were another.

What client driven compliance evaluation changes

Intune now supports client driven compliance evaluation for Windows, and it is the first real change to this behaviour in years. Microsoft describes it as a capability where a device can detect certain local state changes and proactively request a compliance re-evaluation rather than waiting for the next scheduled check in cycle. The mechanism is documented in the Windows compliance settings reference, under how compliance calculation is triggered on Windows devices.

Two things have changed since this post first went out, and one qualification has been added.

The first change is status. When this post was written in September 2026 the section carried a preview label. The Create device compliance policies article, updated on 22 September 2026, no longer labels it as preview, and the Windows compliance settings reference does not mention preview anywhere. I would still treat it as new behaviour rather than settled behaviour until it has been through a few months of real estates.

The second change is scope. The reference documentation now names the signals itself and splits the mechanism in two. Real-time compliance monitoring covers firewall, antivirus, BitLocker, Microsoft Defender status, operating system build version, real-time protection and Secure Boot: when one of those changes, Intune proactively requests a device check in. Scheduled compliance monitoring is the Intune Management Extension periodically comparing compliance-related settings on the device against its last known baseline, and starting a check in when something has moved.

The added qualification is throttling. Microsoft notes that Intune throttles compliance-triggered re-evaluations, so if several changes land in a short period, some are processed in a later evaluation cycle. Real time does not mean instant, and it does not mean every change at once.

Read the real-time list for what is not in it. Every entry is a built in Windows security signal. Custom compliance is absent. If your policy turns on a custom compliance script, the thing that decides your device’s state is a script executed on a schedule by the Intune Management Extension, and the documentation does not put it on the real-time path. At best it rides on scheduled monitoring and the ordinary check in.

That is the honest summary. The feature makes the fast signals faster and leaves the slow ones on the scheduled path. If your compliance posture rests on BitLocker and Microsoft Defender state, this is a meaningful improvement. If it rests on a script that reads a registry key, expect little change.

What Not evaluated actually means

Intune reports four compliance states, and the one that generates the most tickets is the one that is not an error at all. From the monitoring article:

The other causes are the useful part. Microsoft Learn lists them as devices that are not assigned a compliance policy and have no trigger to check compliance, devices that have not checked in since the compliance policy was last updated, devices not associated with a specific user such as Apple Device Enrollment Program devices without user affinity or Android Enterprise dedicated devices, and devices enrolled with a device enrollment manager account.

The second of those is the one that catches people. Editing a compliance policy drops every targeted device back to Not evaluated until it next checks in. Change a setting at four in the afternoon, look at the dashboard at nine the next morning, and a healthy estate can appear to have collapsed overnight. It has not. It is inside the documented window, and the documented window is up to 24 hours.

Why the delay matters more than it used to

Compliance state stopped being a report the moment it became an input to Conditional Access. A device that is compliant but reported as Not evaluated is, for access purposes, indistinguishable from a device that is not compliant at all. The user cannot open their mail. Nothing is broken, the setting is correct, and the estate is inside the documented reporting window, but the person in front of the laptop is locked out and will quite reasonably raise a ticket about it.

That asymmetry is why the 24 hour figure belongs in your change process rather than in a footnote. A configuration change that is correct on every device and not yet reported is still a working outage. It also tends to produce the worst available response, which is an administrator loosening the Conditional Access policy to clear the queue and then not putting it back.

The mitigation is dull and it works. Stage compliance changes to a pilot ring, wait a full reporting cycle, confirm the chart has caught up, and only then widen the assignment. The same discipline applies to anything else in Intune that reports on its own schedule, including an Intune remediation script, where the run result and the console view are also separated by a reporting leg.

The failure modes

Editing an Intune compliance policy and then watching the chart. The edit resets the population. There is no state to read until devices report again. If you need to know whether a change worked, apply it to a small pilot group and wait a full day before drawing conclusions from the numbers.

Syncing twice. A second sync inside the same 6.5 hour window does not produce a second maintenance cycle, and syncing does not shorten the reporting leg, which is the part you are actually waiting on.

Reading In-grace period as a soft pass. It is not one. Microsoft Learn is explicit that devices in this state are noncompliant. The grace period changes when enforcement bites, not what the device is.

Devices with no user affinity that never evaluate. Shared iPads enrolled without user affinity, and Android Enterprise dedicated devices, sit in Not evaluated by design. Targeting them and waiting is a category error rather than a fault to be chased.

Assuming client driven evaluation covers your policy. Real-time detection covers a named set of Windows security signals. A compliance policy built on a custom script, or one targeting any non Windows platform, is not on that list and still depends on scheduled monitoring and the check in cadence.

Expecting BitLocker compliance the moment encryption finishes. The Windows compliance settings reference notes that the Require BitLocker state is measured at boot time through Device Health Attestation, so a device that has finished encrypting needs a reboot before it can report compliant. A sync is not a substitute for the restart.

A setting stuck in Error. When a compliance setting returns Error, Microsoft Learn says the device keeps its existing compliance state for up to seven days while the calculation completes. If the setting is still in Error after seven days, the device becomes Not compliant, or In grace period if the policy has one. A device that looks fine today can therefore flip a week after the fault began, which makes the change that caused it hard to find.

Layering compliance on top of a security baseline. A baseline can set the same underlying configuration a compliance policy is checking for, from a second profile you did not knowingly create. Where that second profile comes from is a longer story, but the symptom here is a device reporting noncompliant on a setting you can see is correct when you look at the device.

What I would do differently

An Intune compliance policy is a reporting system before it is an enforcement system, and the useful habits all follow from treating it that way. I run a lab tenant with no enrolled fleet, so I have not measured these intervals against a real population and will not pretend otherwise. What follows is judgement about how to plan around Microsoft’s own published numbers.

Plan against 24 hours, not 8. The eight hour cycle is the check in cadence. The 24 hour figure is what Microsoft commits to for the full round trip, and it is the only number that will not embarrass you in a change window. Anything downstream of compliance reporting, and Conditional Access is the obvious one, should be scheduled with a day of slack rather than an afternoon.

Separate the two questions when troubleshooting. Is the device wrong, or is the console stale? They have different evidence. The device is wrong if the setting genuinely is not applied locally. The console is stale if the device is correct and its last check in predates the policy edit. Confusing the two is how an afternoon disappears.

Keep compliance policies few and platform specific. Overlapping policies resolve to the most restrictive value, which is defensible behaviour and miserable to debug when three policies each contribute one setting to the answer.

Watch client driven evaluation in a test ring before you build anything on it. The preview label has gone from the documentation, which is welcome, but the throttling note means a burst of changes can still wait for a later cycle. Nothing load bearing should assume otherwise.

Last verified: 10 November 2026.