Why your Intune and Configuration Manager compliance numbers lie

Ask an IT director how many of their devices are compliant and you will usually get a number from a dashboard. Ask how that number is calculated and the room goes quiet. It is worth knowing, because both Intune and Configuration Manager will report a device as healthy and compliant in circumstances where it is doing nothing of the sort - and in Intune's case, the out-of-the-box default actively works against you.

None of what follows is a criticism of either product. Every behaviour here is documented by Microsoft. The problem is that the defaults are permissive, the thresholds are loose, and almost nobody reads the small print before putting the number in a board pack.

The Intune setting that quietly inflates every green number

In the Intune admin centre there is a tenant-wide setting called "Mark devices with no compliance policy assigned as". It has two values, and Microsoft's own documentation is admirably blunt about them:

Read that again with your own tenant in mind. In a default configuration, a device that has never been evaluated against a single compliance rule is reported as compliant - and it satisfies the "Require device to be marked as compliant" grant in Conditional Access. Every green figure in a default tenant includes those devices, and there is nothing on the dashboard to distinguish them from devices that genuinely passed a policy.

This is the first thing to check in any estate you inherit. It is one toggle, and it changes what the number means.

How long a device can lie to you after it goes dark

The second setting worth knowing is Compliance status validity period, which defaults to 30 days and can be set anywhere from 1 to 120. Microsoft's wording: "If a device fails to report its compliance status for a policy before the validity period expires, the device is treated as noncompliant."

So a laptop that is switched off, stolen, or simply broken keeps its last-known compliant state for a full month - and that stale state is what Conditional Access consumes throughout. Thirty days is a long time for a device to be granted access on the strength of a check it passed before it disappeared.

Two related behaviours compound it:

• A device in the Error state keeps its previous compliance state for up to seven days while Intune waits for a correct evaluation. If that previous state was compliant, it stays compliant.
• Devices inside an administrator-configured grace period are technically non-compliant but are not blocked by Conditional Access. A generous grace period is functionally a period of unenforced policy. The built-in default is zero days, but grace can be set anywhere up to 365.

There is also a status most people misread. "Not evaluated" is not a synonym for "fine, just new". Microsoft lists several causes, including devices with no compliance policy assigned and no trigger to check, devices that have not checked in since the policy was last updated, devices with no user affinity, and devices enrolled through a device enrolment manager account. Some of those are permanent conditions, not transient ones.

How fresh can an Intune number possibly be?

Not very. Microsoft publishes the refresh cycle: after enrolment a Windows device checks in every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then approximately every 8 hours thereafter. That is the steady state for every platform.

The detail that matters more, and gets almost no coverage: "Devices are only allowed one maintenance sync every 6.5 hours, independent of the client schedule." A user hammering the Sync button in Company Portal cannot beat that floor. So a Windows device's compliance state in the console can legitimately be up to eight hours out of date, and Microsoft separately notes that a newly targeted device can take up to 24 hours to appear correctly in a compliance chart.

Microsoft now documents the caveats. Quote them.

Two additions to the compliance monitoring documentation in 2026 are unusually candid, and they are useful precisely because they are first-party. In April 2026 Microsoft published a "Known reporting behaviors" section covering, among others:

• Check-in dependent reporting. "If a device doesn't check in, the report might not immediately reflect recent policy assignments or targeting changes."
• Last-user semantics. "Compliance reports display the compliance state associated with the last user who checked in on the device. On shared or multi-user devices, this behavior can cause reports to reflect a previous user's compliance state." Device-targeted policies with nobody signed in report the user as "System account".
• Asynchronous report updates. "Summary report views and detailed device lists don't always update at the same time" - so the summary and the detail can legitimately disagree, and neither is wrong.
• Multiple device entries are expected, with separate records for user and system context.

Then in May 2026, a genuinely striking addition about the values devices report back:

That is Microsoft documenting a prompt-injection-style risk inside the compliance console: the device explains why it is non-compliant, and the device could be lying in order to manipulate whoever reads it. Worth knowing before you act on a non-compliance reason at face value.

One structural change from June 2025 sits underneath all of this - the Policy Reporting Service moved to V3, and reports now update only when devices check in. Policies removed but not yet processed by an offline device continue to show their last-known status.

Configuration Manager: what "Active" actually means

ConfigMgr's client status is even looser than most people assume. Microsoft's definition:

Every threshold in Client Status Settings defaults to seven days - policy requests, heartbeat discovery, hardware inventory, software inventory, status messages. So "Active" is an OR across five loose signals over a seven-day window. A device needs to do exactly one of those things, once a week, to be green.

It says nothing whatsoever about whether policy is being applied, whether content will download, whether updates install, or whether the client health evaluation passed. Note also that "online" is a completely different measurement - if the management point receives no message for five minutes, the client is considered offline. Active and online are not related.

And a detail that turns the Client Health dashboard into an actively misleading view: it defaults to showing only online clients that were active in the past three days. The worst devices in the estate are excluded from the default view unless you change the filter.

CcmEval runs at midnight. Your laptops are asleep.

Client health evaluation is the mechanism most people assume is watching. Two documented properties define how often it looks:

• CCMEVALINTERVAL - "By default, ccmeval runs once a day (1440 minutes)."
• CCMEVALHOUR - "By default, ccmeval runs at midnight."

And from the monitoring documentation: "Client check runs automatically during the Windows maintenance window." That is Windows Automatic Maintenance, which on a laptop that is asleep, shut down, or on battery at midnight may not run at all. The device will nonetheless still show Active in the console, because Active is computed from policy, heartbeat and inventory traffic - not from whether CcmEval ever fired.

Worth also checking whether anyone ever set NOTIFYONLY=TRUE at client install. Microsoft: "When you enable this property, the client reports status, but doesn't remediate problems that it finds." Estates that turned this on years ago for change-control reasons routinely forget.

What CcmEval checks - and what it does not

CcmEval covers a specific, fairly narrow list: client installation and prerequisites, more than 1% free disk space on C:, the SMS Agent Host service, whether CcmEval itself has run in the past three days, the client's local database, WMI health including repository integrity, the antimalware service, Windows Update service startup type, the Microsoft Policy Platform, and BITS.

Here is what it does not look at. Every one of these is a real failure mode with a documented mechanism, and none appears in the check list:

Not checked	Consequence	Where to look
Client stuck in provisioning mode	Client does not process policy at all - no deployments, no updates - while heartbeat and inventory may continue	CcmExec.log, registry ProvisioningEnabledTime
ccmcache bloat or orphaned content	Content downloads fail, so deployments silently never run	CAS.log, ContentTransferManager.log
Client certificate / PKI problems	Client cannot authenticate to the management point over HTTPS; policy stops	CertificateMaintenance.log
Wrong site assignment or failing MP lookup	Client is healthy locally and talking to nothing useful	LocationServices.log, ClientLocation.log
Stuck or stale policy	Policy body cached and never refreshed	PolicyAgent.log, PolicyEvaluator.log
Hardware inventory failing	Console data stale, collections wrong - device still shows Active	InventoryAgent.log
Duplicate or conflicting SMS GUID	Two records, neither accurate	ClientIDManagerStartup.log
Co-management enrolment failure	ConfigMgr-managed but never enrolled to Intune	CoManagementHandler.log

Provisioning mode deserves a note of its own, because it is the most complete form of silent failure. The default timeout is 48 hours, the client checks the duration every 60 minutes and exits automatically past the timeout - but while it is in provisioning mode it processes no policy from the site at all. Microsoft is explicit that you should exit it via WMI rather than editing the registry:

Invoke-WmiMethod -Namespace root\CCM -Class SMS_Client `
  -Name SetClientProvisioningMode -ArgumentList $false

One more practical trap when you go looking for evidence: CCMLOGMAXSIZE defaults to 250,000 bytes. On a busy client the log you need has usually rolled before anyone thinks to look.

Co-management: where neither side is in charge

Co-management is where "compliant" and "healthy" get genuinely ambiguous, and there are three documented traps.

Pilot Intune does not remove policy. Microsoft's own wording: "When Pilot Intune is selected for Endpoint Protection and Device Configuration Policies, Intune only deploys the policies and doesn't perform policy removal upon unassignment. For policy removal from the device when the policy is unassigned, the workload must be switched to Intune." Devices accumulate orphaned settings from an authority that no longer claims them, and neither console shows it.

A ConfigMgr compliance rule that does nothing on half your estate. The "Require device compliance from Configuration Manager" setting in an Intune compliance policy applies only to co-managed devices. Intune-only devices return a "not available" status. On a mixed estate the rule exists, looks enforced, and quietly has no effect on the devices that are not co-managed.

Ground truth is in WMI, not the dashboard. Query SMS_Client_ComanagementState and a device is only genuinely co-managed when MDMEnrolled = 1 and ComgmtPolicyPresent = 1. A device can hold the co-management policy, appear in the co-management funnel, and never have enrolled at all.

Then there is the harshest case, which is not co-management at all. When ConfigMgr detects a third-party MDM on a device it automatically deactivates resource access policies, application management, software updates, endpoint protection, compliance policy, device configuration and Office Click-to-Run management - continuing read-only for inventory, Asset Intelligence, software metering and power management. The console keeps reporting inventory and keeps showing devices Active, while ConfigMgr has silently stopped managing anything that matters. If you have layered another MDM onto a ConfigMgr estate, this is worth verifying today.

The October 2026 pile-up

Four deadlines land within a fortnight of each other, and they interact. If you manage UK estates on Configuration Manager, this is the planning point to take from this article:

Date	What happens
30 September 2026	Configuration Manager 2503 drops out of support. The current branch lifecycle is 18 months from general availability - roughly four months of security and critical updates, then fourteen months of security-only.
October 2026	An internal service required for device compliance checks is deprecated. Microsoft's hotfix documentation warns that afterwards, "compliance checks in Software Center may fail in co-managed environments where the Compliance workload is managed by Intune". You need 2603, or 2509 plus KB37864969, before then.
13 October 2026	Commercial Windows 10 ESU Year 1 expires and Year 2 doubles from $61 to $122 per device. Cumulative purchase is mandatory - Year 2 requires Year 1.
13 October 2026	Windows 11 24H2 reaches end of servicing for Home and Pro.

Sites still on 2503 face the first two in the same week. Two further constraints are worth checking while you are in there: Windows 10 22H2 client support was removed in Configuration Manager 2509, so an estate on 2509 or 2603 with Windows 10 endpoints has formally unsupported clients; and Windows 11 25H2 requires 2509 or later.

Looking slightly further out, Microsoft announced in November 2025 that from version 2609 (September 2026) Configuration Manager moves to a single annual release, aligned to the Windows H2 cadence, with hotfix rollups only "for urgent security or functionality issues". The 18-month support lifecycle is not being extended to match, which narrows the version overlap window to about six months. 2603 is the last release under the old semi-annual cadence.

To be clear, because the coverage of that announcement got overheated: there is no announced end-of-life for Configuration Manager. Microsoft's framing is that Intune is where new innovation happens and ConfigMgr continues to serve on-premises devices with a renewed focus on security and stability. When The Register asked directly whether the cadence change signalled eventual sunsetting, Microsoft declined to comment - which is worth exactly as much as you think it is, in either direction.

What the industry data actually says

Here is the honest position, and it is more useful than a borrowed statistic: nobody publishes a Configuration Manager client-health benchmark. Not Microsoft, not Gartner, not the tooling vendors. If you see a claim that "X% of management agents are broken", ask for the methodology, because we could not find a credible source for one.

What does exist, with caveats attached:

• Absolute Security's 2026 Resilience Risk Index (March 2026), based on device-level telemetry across tens of millions of enterprise endpoints, found endpoint security software fails to protect roughly one in five devices - a 21% failure rate - and that its "protected-state integrity" measure fell from 64% in 2025 to 55% in 2026. Caveat firmly: Absolute sells a product whose entire premise is agent resilience, the 2026 edition does not disclose a sample size, and the telemetry comes from its own installed base rather than a random sample.
• Sevco Security is the most useful source on stale agents specifically, because it distinguishes missing from installed-but-not-checking-in. Its analysis of over 500,000 IT assets found roughly 3% of assets had endpoint protection installed but stale, and a later study of 1.2 million assets found 28% missing at least one critical control. Its CEO put the problem well: "the agent is installed, but it's not checking in. That results in missing updates and probable malfunctioning agents." Same caveat - vendor research, own customer base.

What to actually do about it

None of this requires new tooling to start on. In order of return:

1. Change the Intune default for devices with no compliance policy from Compliant to Not compliant - after checking what it would reclassify, because on a large estate it will reclassify things.
2. Shorten the compliance status validity period from 30 days to something that reflects how quickly you would want to know. Then look at what falls out.
3. Stop treating "Active" in ConfigMgr as a health signal. Report on CcmEval outcomes and on policy request recency separately, and change the Client Health dashboard filter so it stops hiding the devices you most need to see.
4. Check for provisioning-mode stragglers and cache problems explicitly - neither is covered by client health evaluation.
5. Verify co-management state in WMI, not in the funnel graph, and confirm whether any third-party MDM has silently deactivated your ConfigMgr workloads.
6. Fix your grace periods. A long grace period is an unenforced policy that reports as enforced.
7. Get to 2603, or 2509 with the hotfix, before October.

The underlying principle is simple enough. A compliance number is only as good as the freshness of the data behind it and the strictness of the default underneath it. Both are configurable, and in most estates neither has been configured.