Windows Autopatch and third-party patching solve two different problems, and IT teams that treat them as one problem end up with a gap they cannot see. Autopatch keeps Microsoft’s software current across the fleet, and hotpatch has removed most of the restarts that made monthly updates disruptive. Neither changes who owns the browsers, PDF readers, runtimes, and line-of-business applications that Microsoft does not ship. That layer stays with the IT team, and it is where most of the unpatched software on a typical Windows estate sits.
What Windows Autopatch Updates
Windows Autopatch is a cloud service that automates updates across registered devices. According to Microsoft’s documentation, it covers four things: Windows quality and feature updates, Microsoft 365 Apps for enterprise, Microsoft Edge, and Microsoft Teams. It can also deliver Windows drivers and firmware that are published through Windows Update.
The service applies updates in phased deployment rings, so a small test group receives an update before the broad fleet does. When telemetry shows a problem, the rollout pauses automatically. For the software it covers, Autopatch removes most of the scheduling and monitoring work an IT team used to do by hand.
The scope is deliberate. Autopatch updates Microsoft’s own software estate. Everything else on the device belongs to a different process.
How Hotpatch Changes the Restart Cadence
Hotpatch is the more recent change, and it addresses a real operational problem: a device is not protected when an update downloads, but when it takes effect — and that used to mean waiting for a user to accept a restart.
Eligible devices now run on a quarterly cycle. Microsoft’s release notes set January, April, July, and October as baseline months: the device installs a cumulative security update and restarts. In the two months after each baseline, security updates apply without a restart and take effect immediately. Eight months out of twelve, nobody sees a restart prompt.
The eligibility conditions are specific. A device needs Windows 11 Enterprise version 24H2 or later on an x64 processor, virtualization-based security running, and the current baseline installed. Intune must manage it through a quality update policy with hotpatch turned on. Miss one condition and the device receives the standard cumulative update instead — still patched, but with the restart back.
For an IT team, the practical gain is a shorter distance between “update released” and “device actually protected.” That gain applies to the software Autopatch covers.
Where Third-Party Patching Sits
A typical Windows endpoint runs software from a dozen vendors. Chrome or Firefox alongside Edge. Acrobat Reader. Java or .NET runtimes. 7-Zip, Notepad++, PuTTY, VLC. Whatever line-of-business applications the organization depends on. None of it moves through Windows Update, so none of it moves through Autopatch.
Each of those applications ships its own updates on its own schedule. Some update themselves silently, some prompt the user, some do nothing until an administrator intervenes. The result across a fleet is uneven: an organization can hold a clean Autopatch compliance report and still run a hundred outdated Acrobat installations.
That unevenness is the part that resists reporting. Windows patch status is one number from one source. Third-party patch status is a question that has to be answered application by application, unless something automates both the updating and the record of it.
How CapaOne Covers the Third-Party Layer
CapaOne Application Manager automates third-party application patching across a governed catalog. It detects installed and outdated applications through an endpoint agent, applies updates in staged rollouts targeted at existing Entra ID groups, and writes an exportable audit trail for every deployment. Applications outside the catalog run through no-code packaging rather than hand-built scripts.
Security Monitor adds the visibility layer: which endpoints carry a known vulnerability, which ones drifted out of policy, and what the exposure looks like across the fleet rather than per device.
The two services divide cleanly. Autopatch owns Microsoft’s software; CapaOne owns everything else, with one console and one agent for both the updating and the evidence. Organizations running Intune can read the split in more detail on the Intune patch management page, and the Intune third-party patch gap covers why the boundary exists in the first place. Teams evaluating hotpatch specifically will want the hotpatch baseline eligibility requirements before they plan a rollout.
CapaOne runs standalone for organizations without Intune or Autopatch, managing the full application estate from the same console. CapaOne hosts all endpoint data in the EU, with no transfer of endpoint data to US jurisdiction.
What Changes for the IT Team
Splitting the two layers cleanly produces results that show up in ordinary operations.
- One report covers both layers. Windows currency from Autopatch, third-party currency from CapaOne, without assembling the second one manually.
- Third-party updates stop depending on the user. Staged rollouts run on policy, not on whether somebody clicked an update prompt.
- Audit evidence exists as a byproduct. Every deployment carries a record, which supports a NIS2-aligned posture without a separate documentation exercise.
- No packaging backlog. Catalog applications update themselves; the rest go through no-code packaging instead of maintained scripts.
Autopatch does what it was designed to do, and hotpatch made it noticeably less disruptive. The question worth asking is not whether Microsoft’s tooling is good enough — it is which layer it covers, and what covers the other one. Book a demo of the CapaOne Endpoint Management Platform to see third-party patching and vulnerability visibility working together, or start a free trial and check your own estate.