Four layers, one job
Where the gaps hide
- A group registered with Autopatch whose members were never actually enrolled: policy says covered, devices say otherwise
- A deployment that is paused, faulted, or whose audience nets to zero after exclusions
- An actively exploited CVE whose fixing KB is absent from every deployment: the coverage gap that matters most
- Devices outside Defender coverage entirely, so nothing is verifying them
- Servers assessed by nothing, because they are not in Intune and Azure Update Manager was never pointed at them
Every one of these is invisible if you only look at one layer. They only show up when policy, execution, and verification are read together.
Where third-party patch vendors fit
Two different roles, often confused. Publishers like PatchMyPC, Scappman, and Robopack feed third-party application updates into Intune as Win32 packages, and Intune deploys them like anything else. Endpoint managers like Automox, NinjaOne, Ivanti, ManageEngine, and Tanium act on devices directly, alongside or instead of Intune. Defender verifies the result either way.
We track all of this in public, daily
Senserva publishes the underlying data free, refreshed every day, with a page for every Microsoft update and every tracked CVE.
Every KB has a page with the CVEs it fixes and the Microsoft Update Catalog download, like KB5087539. Every exploited CVE has one too, with EPSS, the CISA due date, and the fix, like CVE-2024-3400. All of it is in the JSON and RSS feeds, no login required.
Microsoft patching questions, answered
Intune holds the policy: update rings and feature, quality, and driver update profiles. Windows Autopatch executes: it runs the deployments that push updates to enrolled devices. Defender for Endpoint verifies: it reports which updates are actually missing on each device and which CVEs that exposes. They are three different jobs, and a gap in any one leaves devices unpatched.
Azure Update Manager assesses and patches Azure virtual machines and Azure Arc-enabled servers: pending updates by classification, pending reboots, and per-patch KB and CVE identifiers. It covers the server estate that Intune and Autopatch do not.
Vendors like PatchMyPC, Scappman, and Robopack publish third-party application updates into Intune as Win32 packages, which Intune then deploys like any other app. Endpoint managers like Automox, NinjaOne, Ivanti, ManageEngine, and Tanium act on devices directly. Defender still verifies the result either way.
Defender for Endpoint is the primary answer: Microsoft's sensor on each device reports that machine's missing updates directly, so installed simply means not reported missing. Windows' cumulative model makes the OS build number decisive too: being on the current build means having everything up to it, which is how Senserva's fallback works for tenants without Defender licensing. Azure VMs carry an explicit per-patch state (installed, not installed, excluded, or failed) from Azure Update Manager, and third-party apps are determined by the Intune detection rules published with each package.
Senserva reads every layer read-only: Intune policy, Autopatch deployment health, Defender per-device truth, Azure Update Manager assessments, and vendor-published Intune apps. It joins them into one view ranked by real-world exploitation (CISA KEV first, then EPSS), audits the gaps between the layers, and names the exact KB to deploy.
Senserva works with all of it
Everything on this page is what Senserva reads on every scan, read-only: Intune policy, Autopatch deployment health, Defender per-device truth, Azure Update Manager assessments, and vendor-published Intune apps, joined with CISA KEV, EPSS, MSRC, and the NVD into one exploit-ranked view. The gaps between the layers become named findings with the exact KB to deploy, and the admin approves every change.