Third-party patch management software for MSPs: what to look for beyond Windows Update

Chrome ships a new version roughly every four weeks, and Windows Update will never install a single one of them. Neither will it touch Zoom, 7-Zip, Adobe Reader, Java, or the practice management application that one client's entire business runs on. If your patching story ends at Patch Tuesday, most of your attack surface is unmanaged. That much you already know. The harder question is which third party patch management software for MSPs actually deserves your money, because the tools differ far more in how they source and verify updates than their datasheets admit. This is a buying guide: the three approaches vendors take, what each costs, and a set of tests that will score any tool against your real estate in an afternoon.

Three approaches, three very different products

Every third-party patching tool answers the same underlying question: where does the catalogue of application updates come from, and who guarantees it is right? There are only three honest answers.

Proprietary catalogues: curated, tested, and finite

Some vendors employ people to package updates. They test silent install switches, write detection logic that checks the installed version properly, and publish an update only once it deploys cleanly. Ninite Pro and Patch My PC built their reputations this way, and several RMMs maintain in-house catalogues on the same model.

The strength is quality: when a curated catalogue says an update applied, it usually did, and the metadata around it, supersedence, reboot behaviour, and detection, is reliable. The weakness is the edge of the map. A curated catalogue covers a few hundred to a few thousand titles, chosen by the vendor's idea of a typical estate. Your dental client's imaging suite is not on the list and never will be. Coverage is fixed, visible, and checkable up front, which is at least an honest failure mode.

winget and community repositories: broad, free, and uneven

The second approach borrows a catalogue rather than building one. Microsoft's winget repository and the Chocolatey community feed cover tens of thousands of packages at zero catalogue cost, so a growing number of RMMs simply wrap them.

Breadth is real, but so are the seams. Manifests are largely publisher- or community-maintained, so a new version can lag days behind release, which matters most for exactly the browser and VPN client updates you patch for security reasons. Detection is the bigger problem: winget maps installed software to packages by heuristics, so per-user installs, portable apps and renamed installers slip through, and the tool can report an estate as current while a stack of unrecognised installs sits outside its view. A wrapper around winget is not doing the work; it is delegating it, and you inherit whatever the manifest author got wrong.

Add-on modules: someone else's catalogue at per-endpoint prices

The third approach is the RMM add-on: third-party patching sold as a module on top of the base licence, frequently reselling one of the catalogues above under the vendor's own branding. Pricing is almost always per endpoint per month, typically a sub-pound figure that looks trivial in isolation and compounds unpleasantly at scale, in exactly the way add-ons left off the pricing page tend to. Before comparing tools, establish which of the three models you are actually buying, because two products with identical feature lists can sit on entirely different foundations.

Scoring third party patch management software for MSPs: four tests

Feature matrices will not settle this. Your estate will. Each test below takes under an hour with data you already have, whether the machines belong to clients or to your own company.

The coverage test. Export installed software from your RMM across every endpoint, dedupe it, and rank by install count. Take the top fifty titles and check each against the candidate's catalogue, by exact product, not vendor name, because "Adobe" in a catalogue can mean Reader and nothing else. Then repeat for the bottom of the list, the niche vertical applications, and record which are absent. Skip this and you will discover the gaps six months in, one CVE at a time. A tool covering 45 of your top 50 beats a tool claiming ten thousand titles that misses eight of yours: catalogue size is a vanity metric, and overlap with your estate is the only number that matters.

The per-client schedule test. An accountancy firm in January and a bar that opens at noon do not share a maintenance window. Check whether the tool supports schedules, approval rings and exclusions per client, not merely per policy applied globally. The specific scenario to test: one client runs an application certified only against an old browser version. Can you exclude that single update, for that single client, without forking your entire patch policy? If the answer involves duplicating policies per client per exception, the tool will be unmanageable at thirty clients.

The failure visibility test. This is where most tools flatter themselves. A patch job has at least four outcomes: applied, failed, skipped because the application was running, and never attempted because the machine was offline or the software was never detected. Many dashboards report compliance as a percentage of attempts, which quietly excludes the last two categories, and a report that only counts the machines it tried is a mirror angled to flatter. Deploy the trial agent to ten machines, deliberately break one, an installer locked by a running process will do, leave one offline, and see what the report says. If both show as anything other than clearly not patched, walk away. This also decides whether the tool can evidence the 14-day update window that Cyber Essentials expects your tooling to prove, because an assessor will not accept a percentage of attempts either.

The running-application test. Browsers are open all day, which is inconvenient, because browsers are also the thing you most need patched. Check what the tool does with a locked application: silently skip, force-close, prompt the user, or defer and retry. Silent skipping is the worst answer wearing the best compliance numbers, since the machines that never close Chrome are precisely the ones that stay unpatched forever.

How each approach fails

Every model breaks somewhere; the useful question is where, and how loudly.

• Proprietary catalogues fail by omission. The application simply is not there. The failure is visible on day one if you run the coverage test, and invisible until an incident if you do not.
• Repository wrappers fail quietly. A stale manifest, a mismatched detection rule, a per-user install nobody mapped. The dashboard stays green while the estate drifts, which is the most expensive kind of failure because nothing prompts you to look.
• Add-on modules fail at the seam. When a patch breaks something, the RMM vendor blames the catalogue partner and the partner blames the deployment. You pay per endpoint for the privilege of holding the join.

Where this fits with Helios

Most of this evaluation is method, not tooling: any MSP can run the coverage test against any product this week. Helios includes third-party application patching in every plan, alongside monitoring, Windows patching and the service desk, with no per-endpoint add-on module, and its reports distinguish applied, failed, skipped and never-attempted rather than folding them into one compliance figure. Where a patch fails, Helio, the platform's AI agent, investigates and retries within the guardrails you set instead of leaving the failure in a queue. Flat monthly plans are published openly on the pricing page, so you can price the whole stack before you speak to anyone.

Helios is an AI-native RMM and PSA for MSPs and internal IT teams: 14-day trial, every feature on every plan, no card required. Start free.