Patch management

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

Windows Update is the part of patching everyone can see. It has a schedule, a dashboard and a reboot prompt. The software that actually gets exploited, browsers, PDF readers, conferencing tools, updates on its own terms, in the background, one machine at a time. Covering that at scale is where most MSP 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 an MSP is 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 a client estate, 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. For an MSP trying to run it unattended across hundreds of machines, 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 a user 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.