Third Party Application Patching Guide: Closing the Coverage Gap Beyond the Operating System

Operating system patch compliance can read 98% while the PDF reader, archive tool and runtimes on the same laptops are months out of date. Third-party applications ship on their own schedules, install in ways that bypass machine-level tools, and often carry an updater of their own that may be turned off, broken or (as recent incidents show) abused. This guide covers how to inventory third-party software, choose between catalogue-driven patching and vendor self-updaters, configure common updaters, handle per-user installs and runtimes, and measure coverage. It goes deeper on the third-party layer than the Patch Management Guide, which sets the overall process and SLAs. It is written for endpoint engineers and vulnerability managers on Windows and macOS fleets. Vendors and tools named here are listed alphabetically within each table, and the order is not a ranking.

Key takeaways

• Coverage is the real metric. Report the share of installed third-party titles that your patching process can actually update, not just the compliance of the titles it already manages.
• Pick one owner per title. Each application should be updated either by a catalogue tool or by its own updater under policy, never by both, because duplicate mechanisms race and produce false compliance.
• Self-updaters need policy, not trust. Set update mode, channel and check interval centrally (for example Acrobat Mode, Zoom AU2_ keys) and verify the running version, because users and installers can switch updaters off.
• Per-user installs are the blind spot. Applications installed in the user profile escape machine-context deployment and many inventory scans; find them, then either bring them under management or block them.
• The updater is part of the attack surface. Update channels that lack signature checks have been hijacked, so require signed, HTTPS-delivered content and watch updater processes like any other software deployment tool.

Why third-party patching fails differently

NIST SP 800-40 Rev. 4 treats patching as preventive maintenance across all software, but most tooling grew up around the operating system vendor's update channel. Third-party software breaks that model in four ways.

• Many release calendars: each vendor publishes on its own cadence, from scheduled quarterly releases to out-of-band security fixes.
• Install context: applications installed per user live in the user profile, outside the system context that most deployment agents run in, and are invisible to tools that read only machine-wide uninstall records.
• Embedded and bundled components: runtimes, browser engines in Electron desktop apps, and libraries shipped inside other products are patched only when the parent product ships a new build. See the Electron and Desktop App Security Guide.
• Exploited often: client applications that open untrusted files are a standard route to initial access through drive-by compromise (ATT&CK T1189) and exploitation for client execution (T1203).

The CISA Known Exploited Vulnerabilities (KEV) catalogue shows the scale. In the catalogue version of 21 October 2026, Chromium products account for 65 entries, Adobe Acrobat and Reader for 15 and Oracle Java SE for nine. Small utilities appear too: 7-Zip (CVE-2025-0411, a Mark of the Web bypass added on 6 February 2025), WinRAR (CVE-2025-8088, added on 12 August 2025 and flagged for known ransomware use) and Notepad++ (CVE-2025-15556, a download of code without integrity check, added on 12 February 2026). None of these is fixed by an operating system update.

Inventory first: finding what is really installed

NIST CSF 2.0 ID.AM-02 asks for maintained inventories of software, and SP 800-53 CM-8 (system component inventory) and CM-11 (user-installed software) make the same point at control level. For third-party patching the inventory needs four fields beyond name and version: install context (machine or user), install source (MSI, EXE, package manager, store, portable copy), the mechanism that updates it, and a business owner.

Combine at least two sources and reconcile them weekly. The D3-SWI Software Inventory and Asset Inventory and CMDB Security Guide pages cover the inventory discipline itself. The output that matters here is a list of titles ranked by install count and exposure, each with a named update mechanism, and a shorter list of titles with no mechanism at all. The second list drives removal decisions: Cyber Essentials requires in-scope software to be licensed and supported and unsupported software to be removed, so an unowned title with no update path is a candidate for uninstall, not an exception.

Choosing the update mechanism for each title

There are three ways to keep a third-party title current. Most estates use all three, but each title should have exactly one.

Decision guidance

• Choose the self-updater when the vendor releases security fixes faster than your catalogue can ingest them, and the updater can be configured centrally. Browsers are the clearest case: see the Browser Update Management Guide for channel and relaunch policy.
• Choose the catalogue when users do not have admin rights and the self-updater would need elevation, when you need approval gates for regulated systems, or when the vendor has no reliable updater.
• Choose custom packaging only for titles nothing else covers, and give each one a named packager and a release-watch duty, because nobody else will notice a new version.
• Small organisations (no dedicated packaging team) get most value from leaving well-behaved self-updaters on, enforcing them by policy and removing everything else that is not needed. Large organisations usually standardise on a catalogue for the long tail and reserve self-updaters for fast-moving titles.

Catalogue tools: what the documentation says to configure

Three examples show the design points every catalogue tool shares: how the package is trusted, how fast it arrives and whether you can stage it. Each is described from vendor documentation as of November 2026.

Jamf Pro App Installers (macOS)

• Source and trust: Jamf sources App Installer packages from software vendors and, when needed, repackages and code-signs them. The titles list is published in the Jamf App Catalog.
• Delivery: titles can install automatically or be offered in Self Service; Jamf Pro sends the InstallEnterpriseApplication MDM command through Apple Push Notification service to compatible computers in a smart computer group.
• Updates: after installation, users receive Notification Center prompts when an update is available, configurable in the App Installers settings.

Microsoft Configuration Manager third-party software updates (Windows)

• Catalogues: subscribe to partner catalogues or add a custom catalogue under Third-Party Software Update Catalogs. Custom catalogue URLs must use HTTPS and updates must be digitally signed.
• Trust: you review and approve the catalogue signing certificate. Updates are signed with a WSUS signing certificate (managed by Configuration Manager or manually, for example from an enterprise PKI), and the client setting Enable third-party software updates installs that certificate to the Trusted Publishers store. Unsigned content is rejected, and if a vendor changes its signing certificate, synchronisation fails until you approve the new one.
• Content: updates arrive as metadata only by default, which is enough for compliance scanning; publishing content downloads binaries to the top-level software update point. Logs: SMS_ISVUPDATES_SYNCAGENT.log, wsyncmgr.log and, on clients, updatesdeployment.log.

Microsoft Intune Enterprise App Management (Windows)

• Catalogue: the Enterprise App Catalog holds Microsoft and non-Microsoft Win32 apps prepared and hosted by Microsoft, with prefilled install commands, detection rules and install context.
• Updates: auto-update applies to apps with a Required assignment on Windows 10 and 11; guided update supersedence lets you review a new version first. For self-updating apps, Intune sets a minimum version and leaves later updates to the vendor's updater.
• Staging: the documentation states that auto-update has no rollout rings and updates all targeted devices at once, and has no automatic rollback; build rings with separate assignments if you need them. If a malicious version is found, Microsoft removes it and notifies customers, but you identify and remediate affected devices.
• Availability: requires a subscription in addition to Intune Plan 1 or Plan 2, bought standalone or as part of the Intune Suite. The service-level objective is 80 to 90% of updates available within 24 hours of ingestion, described as a guideline, not a guarantee.

For tools that pull from public package managers, see the Windows Package Managers Security Guide. In evaluation, ask who signs the package, how a bad version is withdrawn and how soon after vendor release it appears. The Patch Management Buyer's Guide turns these into criteria.

Configuring vendor self-updaters

Self-updaters are only a control if their settings are enforced and reported. The table gives examples from vendor documentation; apply the same pattern (mode, channel, timing, user override) to every self-updating title you rely on.

• Installer type changes defaults: Zoom documents that its MSI and PKG installers ship with auto-update off while EXE and DMG installers ship with it on. Packaging a title for deployment can therefore silently turn its updater off. Check the default for every title you repackage.
• Legacy settings: Zoom notes that setting any AU2_ key disables legacy parameters such as ZoomAutoUpdate. When vendors replace an update policy, old keys left in place may stop working without an error.
• Runtimes: Java and other runtimes are often installed by line-of-business software at a version that application pins. Patch the runtime through its distribution and track support dates in the Java End of Life Versions and End-of-Life Language Runtimes pages.

Updater integrity and supply chain risk

An updater is a privileged software deployment path that runs on every endpoint. If its delivery channel is subverted, the organisation's own patching discipline installs the attacker's code. ATT&CK tracks this as T1195.002 Compromise Software Supply Chain, and abuse of central deployment tools as T1072 Software Deployment Tools.

• Hijacked update channel: the Notepad++ project reports that from June 2025 to as late as 2 December 2025, attackers who had compromised its former hosting provider redirected update traffic for selected users to malicious update manifests. The project's response was to make its WinGUp updater verify the certificate and signature of downloaded installers from v8.8.9 and to sign the update XML. CISA added the related CVE-2025-15556 to KEV.
• Trusted publisher, tampered build: in the Cursor marketplace extension compromise, tampered versions reached users as a routine auto-update under a trusted publisher's name and tried to plant an SSH key. Automatic updates from marketplaces need the same scrutiny as installers.
• Controls: accept only signed content over HTTPS (Configuration Manager enforces this for third-party catalogues); keep the catalogue and WSUS signing keys in a protected store with named custodians; alert on updater processes spawning shells or making unusual network connections; and keep a tested way to pull back a bad version quickly, since some catalogue auto-update features have no rollback.

The patching tool itself is a high-value target. See Securing the patch management tool itself and the If your patch management tool is compromised playbook.

Where identity fits

Third-party patching runs on machine identities. Configuration Manager's WSUS server connection account needs remote registry and administration rights on software update points; catalogue tools use service principals or API credentials to talk to cloud services; and updater services usually run as SYSTEM or root. Treat these as privileged non-human identities: scope them to the update function, rotate their credentials, and alert on use outside expected hosts and windows. Separately, removing local admin rights from users is what makes catalogue patching necessary in the first place, because many self-updaters cannot elevate on their own. See the Service Account Behavioural Baselining Guide.

How to implement: a phased rollout

1. Baseline coverage (weeks 1 to 2): build the reconciled inventory, list the top 50 third-party titles by install count, and record for each its install context, update mechanism and owner. Flag titles with no mechanism.
2. Remove before you patch (weeks 2 to 4): uninstall duplicate, unused and unsupported titles.
3. Assign one mechanism per title (weeks 3 to 6): enable the catalogue for the long tail, set self-updater policies for fast-moving titles, and turn off the vendor updater only where a catalogue owns the title. Document the choice in the inventory.
4. Deal with per-user installs (weeks 4 to 8): replace per-user copies with managed machine-wide installs where the vendor supports it, and use application control to stop new per-user installs of titles you manage centrally. See the Application Allowlisting Guide.
5. Ring the rollout: pilot ring (IT and application owners) first, then 5 to 10% of users across business units, then broad deployment. Define the halt trigger (crash rate, help desk volume, failed install rate) before you start.
6. Test and roll back: keep the previous package available in the tool, test the uninstall-and-reinstall path once per title, and note which titles cannot be downgraded cleanly. For KEV-listed flaws, follow the Emergency Out-of-Band Patching Playbook rather than the normal ring timings.
7. Close the loop: each month, give titles that keep failing a new owner, mechanism or removal date.

Detection and measurement

SP 800-53 SI-2(2) asks for automated mechanisms to determine whether components have applicable security updates installed. For third-party software that means measuring both coverage and speed.

• Coverage ratio: installed third-party titles with an assigned, working update mechanism, as a percentage of all installed titles (by install count). Target above 95% for the top 50 titles.
• Time to current: median days from vendor security release to 90% of devices running the fixed version, per title. Compare against your SLA tiers (Cyber Essentials sets 14 days for critical or high-risk updates).
• KEV exposure: count of devices with any third-party title carrying an unremediated KEV-listed CVE, tracked daily.
• Per-user install count: devices with managed titles also installed in the user profile; this should fall steadily after phase 4.
• Updater drift: devices where a self-updater's policy differs from the baseline (for example Acrobat bUpdater set to 0 on a title the catalogue does not own).
• Failed install rate: per title and per ring, to spot packages that fail silently and inflate compliance figures.

Watch the updaters too: log process creation for updater binaries and alert on child processes or network destinations that do not match the vendor's documented update endpoints.

Framework mapping

Common failure patterns

• Two mechanisms on one title: a catalogue deploys version N while the vendor updater installs N+1, and the tool reports failure or, worse, success against a stale detection rule.
• Repackaging that switches off the updater: an MSI build with auto-update off by default (as Zoom documents for its MSI) is deployed fleet-wide and the title then never updates on its own.
• Machine-only inventory: compliance is reported from uninstall records that do not include per-user installs, so the most exposed copies are never counted.
• Trusting the update channel without verification: unsigned or weakly verified updates turn the updater into a delivery route for malware, as the Notepad++ update hijack showed.
• Runtime pinned by an application: a vendor application bundles an old Java or .NET runtime, scanners flag it every month, and nobody owns the conversation with the vendor.
• No rollback path: a catalogue auto-update with no rollback breaks a line-of-business integration, and the response is to switch auto-update off everywhere rather than fix the ring design.

Practitioner checklist

• Build a reconciled third-party inventory from at least two sources, including install context and update mechanism.
• Remove duplicate, unused and unsupported titles before expanding patch coverage.
• Assign exactly one update mechanism and a named owner to each of the top 50 titles.
• Enforce self-updater settings by policy (mode, channel, interval, user override) and check installer-type defaults when repackaging.
• Find per-user installs of managed titles and replace or block them.
• Accept only signed update content over HTTPS and protect catalogue and WSUS signing keys.
• Run a pilot ring with defined halt triggers and test rollback once per title.
• Track coverage ratio, time to current and KEV exposure for third-party titles separately from operating system metrics.
• Scope, rotate and monitor the service accounts and credentials used by patching tools.

Standards and references

• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CISA: Known Exploited Vulnerabilities Catalog
• NCSC: Cyber Essentials Requirements for IT Infrastructure v3.2
• Microsoft Learn: Enable third-party updates in Configuration Manager
• Microsoft Learn: Enterprise App Management in Microsoft Intune
• Jamf: App Installers
• Adobe: Acrobat and Reader Updater preferences (Windows)
• Zoom: Automatic update explainer

Related NHI Mgmt Group resources: Patch Management Guide · Browser Update Management Guide · Windows Package Managers Security Guide · Securing the patch management tool itself