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 verified against Microsoft Learn on 21 September 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:
| Platform | Refresh cycle after enrolment |
|---|---|
| Windows | Every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then around every 8 hours |
| Android, AOSP | Every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then around every 8 hours |
| iOS/iPadOS | Every 15 minutes for 1 hour, then around every 8 hours |
| macOS | Every 15 minutes for 1 hour, then around every 8 hours |
Two statements in that article matter more than the table. The steady state for every platform is 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.
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. The Create device compliance policies article 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.
Two qualifications sit on that sentence and both are easy to miss.
The first is that it is in public preview. The documentation heading carries the preview label. Nothing in preview belongs underneath a Conditional Access policy that controls access to production data.
The second is scope. The article describes the trigger as changes to device configuration, security posture, and other settings that affect a device’s compliance state, which is vague enough to read as everything. The what’s new entry published for the week of 14 September 2026 is considerably more specific, and names the signals as firewall, antivirus, BitLocker, Microsoft Defender status, operating system build, real time protection, and Secure Boot. That the announcement is more precise than the reference documentation is itself worth noting, because the reference page is where most people will look in six months.
Read that list for what is not in it. Every entry is a built in Windows security signal that the client can observe locally. 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, not a signal the compliance client is watching. The preview does not accelerate it.
That is the honest summary. The feature makes the fast signals faster and leaves the slow ones alone. 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, nothing has changed.
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:
| Status | What Microsoft Learn states |
|---|---|
| Compliant | The device successfully applied one or more device compliance policy settings |
| Not compliant | The device failed to apply one or more settings, or the user did not comply with the policies |
| In-grace period | Targeted but not yet compliant with all settings. These devices are noncompliant, sitting inside the grace period the administrator defined |
| Not evaluated | An initial state for newly enrolled devices, with several other causes |
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 the preview covers your policy. It covers a named set of Windows security signals. A compliance policy built on a custom script, or one targeting any non Windows platform, is on the original cadence and will stay there.
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.
Enable the client driven preview in a test ring and leave it there for now. It is genuinely useful and it is genuinely in preview. Those two facts sit together comfortably as long as nothing load bearing is resting on it.
Last verified: 21 September 2026.
