The patch compliance dashboard says 96%. Windows is current, macOS is current, the security team signs off and the report goes to the auditor. The trouble is that 96% is the OS picture. The endpoint sitting under that green tile is also running a Chrome build from late summer, an Adobe Reader version with three published CVEs against it, a Zoom client that predates the last security advisory and a Java runtime nobody on the team has thought about in eighteen months. None of that shows up in the score.
That’s the gap third-party patch management is supposed to close, and for most IT teams and MSPs, it’s the half of the patching program that’s quietly underfunded relative to its actual risk. Qualys’s 2026 enterprise benchmark put the mean time to remediation for complex third-party applications at five months and ten days. Attackers operate on a window measured in days, sometimes hours. The two timelines aren’t compatible.
Kaseya’s RMM solutions handle patch management across millions of endpoints for MSPs and internal IT teams worldwide, providing a clear operational picture of where third-party patching programs hold up under pressure and where they fall apart. This guide covers what third-party patch management is, why the mechanics are harder than OS patching, what to prioritize, how to build the program operationally and what automation has to deliver to keep up with the release cadence.
What is third-party patch management?
Third-party patch management is the discipline of identifying, evaluating, deploying and verifying updates for the software running on your endpoints that isn’t shipped by the operating system vendor. That’s a wide category. Browsers, PDF readers, conferencing clients, runtime environments like Java and .NET, productivity suites, developer tools, compression utilities and the long tail of business applications that accumulate in any environment over time.
It sits inside the same broader patch management discipline as OS patching but operates under different constraints. Microsoft, Apple and the major Linux distributions ship their updates through standardized, well-instrumented channels. Third-party vendors don’t. There’s no Patch Tuesday for Slack. No central catalog binds Adobe’s release schedule to Mozilla’s to Oracle’s to the niche line-of-business app the finance team installed in 2019. Every vendor releases on its own cadence, in its own format, through its own channel, and someone must keep track of all of them at once.
The label “third-party” is doing a lot of work here. It captures everything from a browser used by every user in the company to a single-purpose engineering tool installed on three machines. Both fall under the same operational umbrella, and both can be the entry point for a breach.
Why third-party patching is more important than ever
For years, the framing was that OS vulnerabilities were the main concern and applications were a secondary worry. That hasn’t been true for a while. The data has steadily caught up with what attackers already knew.
Adaptiva’s 2025 State of Patch Management survey, conducted with Demand Metric, found that 87% of organizations encountered third-party application vulnerabilities that required patching in the prior year. That’s not an edge case. It’s the default state of nearly every IT environment running modern software.
The CISA Known Exploited Vulnerabilities catalog tells the same story from the other direction. The KEV list catalogs vulnerabilities being actively used by attackers, not just theoretical CVSS-rated ones, and a steady share of new entries fall on third-party applications rather than core operating systems. Browsers, document readers, conferencing tools and runtime libraries appear month after month. They’re widely deployed, they ship security updates frequently, and the gap between vendor release and end-user installation is where attackers do their work.
The pace adds another wrinkle. Microsoft’s April 2026 Patch Tuesday addressed 163 CVEs across its own software stack alone. Stack Adobe, Oracle, Google, Mozilla, Cisco, Atlassian and a dozen others on top of that — and the monthly volume any patching program is supposed to keep pace with starts to look genuinely punishing. Manual review of a feed that size is not a strategy.
The 2025 Verizon Data Breach Investigations Report tracked vulnerability exploitation as the initial access vector in 20% of breaches — a 34% jump year over year. That growth isn’t coming from OS-level zero days alone. It reflects the steady weaponization of vulnerabilities in third-party software that organizations either didn’t know they were running or hadn’t gotten around to patching.
Challenges of third-party patch management
Once you know the risk is real, the natural question is why so many programs leave the gap open anyway. The answer is mechanical, not motivational. Third-party patching is structurally harder than OS patching for four interlocking reasons.
Vendor fragmentation
Microsoft’s update infrastructure handles Microsoft software. Apple’s handles macOS. There’s no equivalent unified channel for the rest. Each ISV maintains its own release portal, its own advisory format and its own delivery mechanism. Tracking releases manually across 50 or a 100 third-party applications means subscribing to dozens of separate feeds and translating each one into action. That’s a full-time role that most teams don’t have headcount for.
Cadence variability
Patch Tuesday gives you a known rhythm for Windows. Third-party releases don’t follow one. A critical browser fix can land mid-week. A runtime update can drop without an advisory. A conferencing tool can push a security build the same day a printer driver vendor publishes a CVE. The volume isn’t predictable and the timing isn’t either, which means a patching program built around a monthly cadence will routinely miss time-sensitive third-party updates by design.
Installer diversity
OS patches arrive through standardized mechanisms. Third-party applications use MSI, EXE, MSIX, App-V, vendor-specific updaters, web-based installers and the occasional bespoke deployment script. Each format has its own silent-install flags, its own reboot behavior, its own version detection logic and its own failure modes. Automating reliably across this variety requires either a tool with vendor-tested support for each application or custom scripting maintained by your team, indefinitely.
Discovery
You can’t patch what you don’t know is there. Users install applications outside IT-approved channels. Acquisitions inherit unmanaged software estates. Departments standardize on tools nobody told the endpoint team about. Without continuous, agent-driven discovery that surfaces every installed application and version on every managed device, the patching program is operating on an inventory that’s wrong before it starts.
These four constraints don’t go away with effort. They’re properties of the third-party software ecosystem itself. A working program is one that designs around them rather than fighting them.
What applications are worth prioritizing first?
Not every third-party application carries the same risk — and treating them as a flat list is how programs end up with the same exposure as no program at all. The right approach is to tier them by deployment footprint, exploitation history and proximity to the network edge, then concentrate cadence and SLA on the top tier.
Browsers belong at the top of nearly every list. Chrome, Edge, Firefox and Brave are installed on every endpoint, render untrusted content from across the internet by definition and receive security updates multiple times a month. They also commonly defer applied updates until restart, which means an available patch isn’t an applied patch until the user closes the window. A 24- to 48-hour SLA on critical browser updates, with enforcement, is a reasonable baseline.
PDF and document readers come next. Adobe Acrobat and Reader have a long catalogue of critical CVEs and a long history of being targeted by malicious documents delivered over email. A current version on every endpoint is the cheapest meaningful reduction in phishing-payload success rates available to most teams.
Runtime environments are the third group. Java, OpenJDK, the .NET runtimes and various JavaScript engines underpin business applications that may not be visible to security tooling as discrete dependencies. A vulnerability in a runtime affects every application built on top of it, and the blast radius can be large even when the runtime itself feels obscure.
Conferencing and collaboration clients sit in a fourth tier. Zoom, Teams (in its standalone install form), Slack and similar tools are installed everywhere, interact with untrusted external links and files, and update frequently. Their attack surface is similar to a browser’s even if their visibility in the asset inventory is different.
Compression utilities, archiving tools, developer dependencies and the long tail of business applications round out the rest. They each carry a meaningful share of the risk, and the right framework for ranking them is the same risk-based model that should govern OS patching: severity (CVSS), exploitation status (KEV listing, threat-intelligence feeds, public exploits), and business context (internet-facing, sensitive data, lateral movement potential). For more on building that framework into the wider program, see patch management best practices.
Best practices for third-party patching: How to build a program
A working third-party patching program follows the same general arc as the broader patch management process but the implementation at each stage has to absorb the extra complexity third-party software brings.
Discovery must be continuous, agent-driven and exhaustive. A weekly software audit on the asset register is not enough. The agent should surface every installed application, every version and every user-installed instance on every managed endpoint, refreshed in close to real time. Wherever that visibility breaks, the patching program is blind by exactly that much.
Monitoring extends the same principle. Once you know what’s installed, you need a feed that tells you when each vendor releases a security update, ideally classified by severity. Building that feed in-house across fifty vendors is a job. The realistic answer is a patching tool whose vendor adds new releases to a tested catalog inside hours of vendor publication, so the team consumes one feed instead of fifty.
Prioritization is where third-party patching most often diverges from OS patching in operational practice. The risk-tiering above feeds straight into your SLA structure, which should be encoded explicitly in your patch management policy. A policy that names third-party applications, assigns them to severity tiers with stated SLAs, and requires documented exceptions removes the implicit “OS first, third-party later” prioritization that creates the gap in the first place.
Testing is genuinely different. OS patches are validated by Microsoft, Apple or the relevant Linux maintainer before release. Third-party patches are validated by the ISV and, ideally, by your patching platform’s catalog QA. The remaining risk is application interaction: a browser update that changes rendering behavior and breaks an internal web app, a Java runtime update that surfaces compatibility issues with a line-of-business package, a Teams build that affects a custom integration. A small pilot ring of representative endpoints, with a 24- to 48-hour hold for routine updates and a compressed smoke test for actively exploited vulnerabilities, catches most of this before it hits production.
Deployment moves the tested update to the rest of the estate against your defined maintenance windows, with retry logic for endpoints that were offline at first attempt and rollback paths for failures. This is the part of the program that breaks most visibly when it’s run by hand, because the volume eats the available hours and exception handling crowds out routine work.
Verification closes the loop. The compliance signal you care about is installed version, not deployment status. A deployment report can show “sent” while a silent installer failure leaves the old version on the device. Per-application, per-device verification of the running version is what tells you whether the patch actually landed.
Reporting is a per-application story, not a per-device one. A device with Chrome current but Java three versions behind isn’t compliant in any sense an auditor will accept. Reporting should slice by application, by severity tier and by SLA breach, with the per-client breakdowns MSPs need for client-facing attestations.
Why automated third-party patch management is essential
The arithmetic doesn’t work without it. Fifty third-party applications, dozens of releases per month per major vendor, hundreds or thousands of endpoints, vendor cadences that don’t align and SLAs measured in hours for the highest-risk patches. No team is going to keep that running by hand — and the ones that try fall behind first on third-party software because that’s where the cost of falling behind is least visible day to day.
Automated patch management takes the routine work off the team’s plate: detecting that an application needs an update, pulling the tested package from the catalog, deploying via silent install during the agreed maintenance window, handling reboots, and retrying failures. Humans stay involved on exception handling, change-window approvals for sensitive systems, and the small percentage of applications that genuinely need manual touch.
Two things specific to third-party automation are worth flagging because they don’t get enough attention in the broader automation conversation.
The first is catalog quality. Automation is only as good as the application catalog feeding it. A platform that takes two weeks to package a critical browser update has, for the duration of that gap, the same security value as no platform at all. The questions worth asking when evaluating any third-party patching capability are: how many applications are supported out of the box, how quickly does the catalog reflect new vendor releases (especially for security updates), and what QA is applied to each package before it reaches production endpoints?
The second is dependency surface. A bad OS patch tends to break the OS. A bad third-party patch tends to break the application that depends on it, which can mean a line-of-business workflow, an integration or a productivity tool the entire company uses. The mitigation is the same as for any patching program — deployment rings, hold periods, automated rollback. However, the operational tolerance for failure is lower because users notice an Adobe Reader breakage faster than they notice a kernel update.
The compliance angle
Compliance frameworks have stopped pretending that third-party software is a separate concern. PCI DSS 4.0 Requirement 6.3.3 covers all system components, which includes applications, not just operating systems. ISO 27001:2022 Annex A 8.8 covers technical vulnerability management without carve-outs. HIPAA’s Security Rule has been interpreted in enforcement actions to cover application patching as part of “reasonable and appropriate” safeguards. NIS2, in force across EU member states, requires evidence of timely vulnerability handling that doesn’t distinguish OS from application. SOC 2 Trust Services Criteria CC7.1 covers monitoring and remediation for new vulnerabilities across the system.
The practical implication is the same in every case. An audit that examines your patching program and finds unmanaged browsers, unpatched PDF readers or end-of-life Java runtimes will produce findings, regardless of how clean your Windows compliance report looks. The defense against that finding is operational evidence: per-application compliance reporting, dated deployment records, documented exceptions and SLAs that are met in practice and not just on paper.
How Kaseya simplifies third-party patching
Third-party patching isn’t a knowledge problem. Every IT team and MSP knows applications need to be patched. It’s an operational problem, and the operational problem is structural: more vendors, more cadences, more installer formats, more discovery surface and a default workflow that favors OS patching because OS patching is easier to instrument.
The way to close it is to stop treating third-party as a parallel program and bring it onto the same framework as the work that’s already running. Same inventory. Same risk-tiering. Same SLAs in the policy. Same deployment rings. Same automation. Same per-application compliance reporting. The underlying tooling must support a tested third-party catalog at the cadence vendors actually release, but the program design isn’t a different program. It’s the same program, fully scoped.
That design principle is what Kaseya RMM solutions are built around: OS, third-party, and firmware patching running through one agent, one policy framework, one set of maintenance windows, one compliance view. Datto RMM‘s Advanced Software Management module is the named third-party capability, expanding patching coverage to 200+ out-of-the-box applications with a catalog tested across millions of devices before release and continuously growing.
The module also supports application install and uninstall through the same policy framework, which closes a gap most patching tools leave open: end-of-life applications that need to be removed, not just updated, before they’re exploited. For MSPs, that translates into per-client policy configuration and per-client compliance reporting from one console. For internal IT teams, it’s a unified view across OS and third-party patch state with the audit trail compliance frameworks expect, produced as a byproduct of the workflow rather than a quarterly evidence-gathering exercise.
The alternative is leaving a documented attack surface exposed while the OS patching dashboard stays green. That’s exactly the gap attackers rely on — and current exploitation data suggests they’re right to.
