Third-Party Application Patching
Where much of the real exposure sits, where platform coverage varies most, and what to do about the gap.
Patching · Analysis
Operating system patching is largely solved. Third-party applications are where the unpatched software in most estates actually is.
The control described in “Third-Party Application Patching” also consumes technician time before, during and after each maintenance window. A provider evaluating project time tracking can record that operational effort by client and work item, making verification and follow-up visible without confusing a timesheet with proof that a patch succeeded.
For an independent operational benchmark, compare the local practice with CISA guidance on patches and updates; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.
Why it matters
Browsers, document readers, runtimes, compression tools, media players and remote access clients are all routine targets.
They update themselves inconsistently, are installed by users without record, and are frequently several versions behind.
An estate at full operating system compliance can still be substantially exposed, and the compliance report will not show it.
Where platform coverage varies
Every RMM supports a catalogue of third-party applications.
The catalogues differ, and none covers everything.
Find out what yours covers and, more importantly, what it does not, because that list is your actual gap and nobody publishes it as such.
The applications nobody patches
Software installed by a department for one purpose.
Vendor-supplied applications that are part of a larger system.
Anything requiring a licence key to update.
Browser extensions, which almost no platform manages.
And runtimes embedded in other applications, which are invisible to inventory.
Building the picture
Software inventory from the agent, which lists what is installed.
Compare against your patching catalogue.
What is installed and not covered is the gap, per client.
That comparison takes an hour and produces a specific list rather than a general worry.
What to do about the gap
Remove what is not needed, which is usually a meaningful share and is the cheapest answer.
Patch manually on a schedule for the few that matter.
Replace with something that does update, where possible.
And document the remainder as accepted, with the reason, which puts it in front of the client rather than in your own quiet backlog.
Self-updating applications
Some update themselves, which is convenient and uncontrolled.
They will update during working hours, change behaviour without notice, and occasionally break.
Decide per application whether to allow it or to manage it, rather than leaving it as a default nobody examined.
Reporting it
A compliance report that covers only the operating system overstates the position.
Split it: operating system, covered third-party, uncovered third-party.
Clients who see the third line understand the estate better, and it is the honest presentation.
What to check
What does your platform's catalogue not cover, in your clients' estates?
Have you compared installed software against the catalogue?
Does your compliance report distinguish operating system from applications?
And who manages browser extensions?
The point
An estate at full operating system compliance can still be substantially exposed through third-party software the catalogue does not cover..
Underlying all of this
Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.
The recurring pattern
The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.