By Yair Knijn · October 7, 2025
The endpoint manager who reported 100% Intune coverage, while a tenth of the fleet never got the filter
He opened the Intune blade, saw the deployment profile assigned to All Corporate Devices sitting at 100%, and copied that figure into the board deck next to "web-content filtering coverage." The slide was wrong, because an assignment is not an outcome. It records what Intune was told to target, not whether a running agent ever applied the config.
Six weeks later, the DNS query logs settled it. About one device in ten had never resolved a single request through the filter. Every one of them showed as assigned. In the only sense that decides whether a user can reach a malicious domain, none of them were protected.
Why Intune "assigned," "installed," and "enforcing" are three different states
Assigned means the policy points at a group. Installed means the payload landed and the installer returned a 0 exit code. Enforcing means the agent is alive right now, holds its config, and is intercepting traffic. Plenty of devices clear the first two and stall on the third: the service crashed after install, a competing product grabbed the same network hook, the config token expired, or someone disabled the adapter the agent binds to. None of those failures move the assignment count off green.
The devices your dashboard swears are covered
The machines that hurt you are almost never the obviously unenrolled ones. They are enrolled, assigned, and marked compliant, and they quietly dropped out of enforcement weeks ago. A few patterns turn up in every audit I have run:
- An agent that installed cleanly, then had its service stopped by a leftover Group Policy or a rival AV, and was never told to start again.
- A re-imaged or hardware-swapped laptop that kept its old Intune object but never re-ran the install, so the assignment now points at a device that no longer exists in that shape.
- A machine behind a captive portal or split-tunnel VPN that could not reach its config endpoint, so the agent fell back to default-allow and filtered nothing while reporting itself present.
Reconcile the deployment profile against live agent check-ins
The fix is unglamorous and it is the entire job. You hold two lists. One is everything Intune assigned. The other is everything the filtering agent reports as actively enforcing, joined on an identifier you trust on both sides, usually the device serial or the Entra device ID. Subtract the second from the first. That difference is your real exposure, and the only coverage number worth defending to a director. Run the subtraction on a schedule, because devices fall out of the enforcing set every day through reimages, crashes, and travel. Doing it once at rollout tells you nothing about Tuesday.
Treat enforcement as a heartbeat, not a milestone
Install success happens once. Enforcement has a pulse. The honest signal that an agent is working is recent, attributable traffic through it: a query log entry, a policy decision, a check-in inside your tolerance window. An agent that installed in March and went silent in April should age out of "covered" on its own, the way an expired certificate stops being trusted. If your coverage definition has no time decay, one good install counts forever, and that is how a tenth of a fleet disappears unnoticed.
A coverage number you can hand an auditor
An ISO 27001 or NIS2 assessor will not accept an Intune assignment screenshot, because it answers a different question than the one being asked. The artifact that holds up is the reconciliation itself: the assigned population, the set actively enforcing in the last N hours, the gap, and who owns closing it by when. With ClearScreen, enforcement is measured at the resolver, so a device counts as covered only when its own queries flow through its assigned policy. The gap stops being a guess and becomes a report you can put on the table. To see that number against your own fleet, start at /demo.