Third-party patching: why it is harder than Windows Update

Third-party patching is harder than Windows Update because there is no single channel: every vendor ships updates its own way and on its own schedule, many apps install per user rather than per machine, and few teams have a clean inventory of what is installed. Windows Update, by contrast, is one channel from one vendor on a predictable cadence. Yet the software that actually gets exploited, browsers, PDF readers, conferencing tools, sits on the harder side, and that is where most patch strategies quietly come apart.

The gap nobody reports on

Look at where real intrusions start and you keep landing on the same short list: a browser a few versions behind, an unpatched PDF reader, an old build of a remote-access or conferencing tool. None of those are Windows. All of them sit outside Windows Update, and none of them show up on the patch report you are most likely to be watching.

That is the uncomfortable part. A fleet can read as 98% patched on the Windows side and still be carrying the exact software a phishing payload is built to exploit. The number looks healthy because it is measuring the easy 20% of the problem.

Why third-party is structurally harder

Windows Update is one channel, run by one vendor, on a predictable cadence. Third-party software is the opposite of all three of those things:

• No single channel. Every vendor ships updates their own way, on their own schedule, some silently and some not at all until a human clicks.
• Per-user sprawl. A lot of apps install per user, not per machine. The same laptop can carry three copies of the same tool for three profiles, each a different version.
• Version drift. Nobody has a clean inventory of what is installed across the estate they look after, let alone what the current safe version of each thing is.

This is why "we patch monthly" almost always means "we patch Windows monthly." The third-party side needs a different mechanism, and for a while there was not a good one that worked without an agent per application.

winget helped, but it has sharp edges

The Windows Package Manager, winget, changed the picture. It can enumerate installed apps that have an update available and install them silently, from a curated source, without a per-app tool:

winget upgrade --source winget --accept-source-agreements
winget install --id Google.Chrome --exact --silent \
  --accept-package-agreements --accept-source-agreements

For a technician at a keyboard, that is close to magic. Run it unattended across hundreds of machines, whether that is an MSP covering a dozen client tenants or one internal team covering every laptop in the building, and it comes with edges worth knowing before you trust it:

• Execution context matters more than you think. Monitoring agents run as a background service under the LocalSystem account. The friendly winget on a user's PATH is a per-user alias that does not exist for LocalSystem, so a naive call simply fails to find it.
• Per-user installs can be invisible. Run winget as the system account and it sees machine-wide installs cleanly, but software your users installed just for themselves may not appear at all.
• It will wait for a human. If any step wants confirmation, an unattended install can sit and block until something times out and looks like a failure, when nothing was really wrong.
• Reboots and exit codes lie. An install that succeeds but needs a restart returns a non-zero code. Treat every non-zero result as a failure and you will bury real successes in false alarms.

What real coverage requires

Getting third-party patching right is less about the install command and more about everything around it. A dependable setup:

1. Runs in the right context, resolving the real tool path rather than assuming a user's environment.
2. Never trusts a silent empty result. "Found nothing" and "could not look" must be different outcomes, and the second one should be loud.
3. Handles reboots and benign exit codes as the successes they are, not failures.
4. Reports per package, so a batch where one app fails does not hide behind a green tick.
5. Keeps an inventory of what is installed against what is current, so the gap is visible before it is exploited, not after.

Do those five things and third-party patching stops being a box that is ticked and starts being a control you can actually stand behind in a security review.

Where this fits with Helios

We built third-party patching into the Helios agent for exactly the reasons above: the browsers and readers are the real attack surface, and covering them should not need a separate product per application. It runs from the same lightweight agent that already reports inventory, patches, antivirus state and backups, so the third-party view sits next to Windows Update rather than in a tool of its own. And yes, we learned the LocalSystem lesson the hard way, which is partly why this article exists.

Related: Third-party patch management software for MSPs: what to look for beyond Windows Update, Winget for patch management: automating third-party updates with Microsoft's package manager

Researched and written with Helio SEO, our AI writer for business blogs.