Third-party application patching covers everything on your endpoints and servers that the operating system's own update service doesn't touch: browsers, document readers, runtimes, collaboration and video-conferencing clients, compression tools and developer tools. It's the gap in most patch programs because OS patching tools only update the OS, and users install many of these applications themselves. You close it by knowing what's installed, removing what you don't need, letting safe applications update themselves, deploying the rest centrally and scanning for outdated versions.
The rest of this post walks through each of those steps.
What counts as a third-party application?
For patching purposes, a third-party application is any software that isn't updated by your operating system's built-in update mechanism. That's most of what people actually use during the day.
The categories that matter most are the ones that open content from outside your organization or run code:
| Category | Why it's exposed | Typical update behavior |
|---|---|---|
| Web browsers and extensions | Process untrusted web content all day | Frequent releases, usually self-updating |
| Document and PDF readers | Open files from email, downloads and shares | Mix of self-updating and manual |
| Runtimes and frameworks | Run code for other applications; old versions often linger | Often manual; side-by-side versions common |
| Collaboration and video-conferencing clients | Connect to external parties and handle links, files and meeting invites | Frequent releases, often per-user installs |
| Compression and archive tools | Parse files from unknown sources | Rarely self-updating |
| Developer tools | Editors, source control clients, package managers, local databases | Updated by users, if at all |
The list isn't exhaustive. Media players, remote support tools, printer utilities and browser plug-ins all belong in the same bucket.
Why do third-party applications get missed?
Most organizations patch the operating system well. The monthly OS cycle is predictable, the tooling is mature and compliance reports look healthy. Third-party software falls outside that routine for several reasons.
OS patching tools only cover the OS
The update service built into an operating system patches the OS and, sometimes, the vendor's own applications. It won't update a browser, reader or runtime from another publisher. If your patch reporting comes from that service, it can show near-complete compliance while dozens of applications on the same machines are months behind.
Users install software themselves
When users have local administrator rights, they install what they need to get work done. That often means a second browser, a free archive tool or a meeting client downloaded to join a customer's call. None of it goes through IT, so none of it is on IT's patch list.
The shift to remote work this year has made this more common. Many people installed new collaboration and conferencing tools quickly, and often on their own.
Self-updating isn't the same as updated
Many applications include their own updater, but updaters fail quietly. Some need administrator rights the user doesn't have. Some are disabled by an old policy or a system image. Others only check for updates when the application is launched, so software that's rarely opened stays old.
Old versions stay behind
Runtimes and frameworks often install new versions alongside old ones instead of replacing them. Per-user and per-machine installs of the same application can also coexist. Scanners find the old copy, even though the version everyone uses is current.
Nobody owns them
OS patching usually has a clear owner. Third-party applications often don't. The desktop team assumes the application owner handles it, and the application owner assumes IT does.
Start with a software inventory
You can't patch what you don't know about. The first step is an automated inventory of installed software across your endpoints and servers, including versions.
Capture at least:
- Application name and publisher
- Installed version, on each device
- Install type (per-machine or per-user) and location
- Number of devices it's installed on
- A business owner or reason it's needed
Make sure your inventory tool can see per-user installs in user profile directories. Many collaboration clients install there, and a tool that only reads the machine-wide list of installed programs will miss them.
The CIS Controls, version 7.1, draw the line between OS and third-party patching explicitly. Control 2 covers inventory and control of software assets. Within Control 3, sub-control 3.4 covers automated patch management for the operating system, and sub-control 3.5 covers the same for third-party software. If you've only implemented the first, you've found your gap.
Remove unused and duplicate applications
Every application you remove is one you never have to patch again. This step usually shrinks the problem more than anything else.
Work through the inventory looking for:
- Duplicates. Three PDF readers, two archive tools and four browsers on the same fleet. Pick one standard per category.
- Old runtimes. Previous versions left behind by upgrades. Confirm nothing depends on them, then remove them.
- Unused software. Applications installed on many machines but used on few. Trial software and one-off installs are common here.
- Unsupported software. Anything the publisher no longer updates. It can't be patched, so remove it or isolate it and document why it stays.
Expect some pushback, and ask the business owner to justify anything you plan to keep.
Enable automatic updates where it's safe
For some applications, the fastest and cheapest patching method is to let the application update itself. Browsers and conferencing clients release often, and centrally packaging every release can be more work than it's worth.
Auto-update is usually safe when:
- The application is standalone, and nothing else depends on its version.
- The publisher has a track record of stable releases.
- Users can't easily turn the updater off, or you enforce the setting through policy.
Auto-update is usually a poor fit when:
- A business application depends on a specific version, as is common with runtimes.
- Developers need fixed tool versions so builds are repeatable.
- The updater needs rights users don't have, so it would fail silently anyway.
Where you do allow auto-update, verify it. Your inventory or scanner should show the version on each device, so you can catch updaters that stopped working.
Package and deploy centrally for everything else
Applications that can't safely update themselves should go through your software distribution or endpoint management tool, the same way OS updates do.
A workable process looks like this:
- Watch for new releases of every application on your standard list.
- Package the update and test it on a small group of machines.
- Deploy in rings, starting with a pilot group before the whole fleet.
- Align the cadence with your monthly OS cycle for routine updates, with a faster path for critical security fixes.
- Confirm installation from inventory or scan data rather than deployment status alone.
Check that your deployment method reaches machines that rarely connect to the office network. If laptops only get updates on the internal network, remote staff can fall weeks behind.
Offer a standard software catalog
A catalog of approved applications gives people a legitimate way to get what they need. When users can install an approved PDF reader or meeting client from a self-service portal, they have less reason to download their own.
It also gives you control over versions. Everything in the catalog is packaged by IT, so it's already on your patch list. Pair the catalog with a simple request process for software that isn't on it, and aim to answer requests within a few days.
Restrict local administrator rights
Removing local admin rights from standard user accounts stops most machine-wide installs. That reduces sprawl, and it makes your inventory far more predictable.
It isn't complete protection. Some applications install per-user without admin rights, so combine this step with inventory monitoring and, over time, application control that limits what can run. You'll also need a process for people who legitimately need elevated rights, such as developers. Give them a separate administrative account rather than elevating their everyday one.
Scan for outdated versions
Your vulnerability scanner is the check on everything above. Authenticated scans can read installed application versions and flag the ones with known vulnerabilities, including copies your inventory might have missed.
A few practices make the results useful:
- Report third-party findings separately from OS findings, so a strong OS number doesn't hide a weak application number.
- Track the version spread of your most common applications. The share of devices on the current release is an easy metric to follow.
- Investigate repeat findings. If the same application keeps showing up out of date, the updater or the deployment is broken.
- Feed new discoveries back into the inventory. Anything the scanner finds that isn't on the list is either removed or brought under management.
Frequently asked questions
Should we just let every application update itself?
No. Auto-update is a good choice for standalone applications that release often, such as browsers. It's risky for runtimes and anything a business application depends on. Decide application by application, and verify the result either way.
How quickly should third-party applications be patched?
Use the same targets you set for the operating system, based on severity and exposure. Browsers, readers and conferencing clients handle untrusted content daily, so critical fixes for them deserve your fastest timeline.
How do we handle developers who install their own tools?
Agree on a standard set of developer tools and keep it packaged and patched. Give developers separate administrative accounts for installs, and include their machines in inventory and authenticated scanning. Tools they add should still show up in your reports.
Our OS patch compliance is high. Why do scans still show so many findings?
Most likely, the remaining findings are third-party applications and old runtime versions. Break your scan results down by publisher or application to confirm, then start with the handful of applications that account for the most findings.
Next steps
- Run an inventory that includes per-user installs and versions.
- Pick one standard application per category and remove the duplicates.
- Remove or isolate anything the publisher no longer supports.
- Enable and enforce auto-update for standalone, frequently released applications.
- Package and deploy everything else through your central tool, on the same cadence as the OS.
- Remove local admin rights from standard accounts and offer a self-service catalog.
- Report third-party findings from authenticated scans separately each month.