Patch management has improved a lot over the last few years, but one problem keeps showing up: organisations still do a better job patching operating systems than they do patching the apps people actually use every day. According to the excellent Adaptiva’s 2026 State of Patch Management report, 74% of IT and security professionals have experienced vulnerabilities in third-party applications, yet only 49% include them in their patching process. That gap matters because every app outside the patch workflow becomes part of the attack surface.[3][2]
The uncomfortable truth is that “patching” often means Windows updates, browser updates, and maybe a handful of high-profile enterprise products. Meanwhile, the long tail of collaboration tools, PDF readers, conferencing apps, drivers, runtimes, and specialist business software quietly accumulates risk. Attackers do not care whether a vulnerability lives in the operating system or in a product installed by finance, operations, or sales; if it is exploitable, it is useful.[4][2]
Why third-party apps slip through
Third-party application patching gets missed for a few predictable reasons. First, ownership is often unclear: IT may manage the endpoint, security may track vulnerabilities, and the business unit may depend on the software, but no one feels fully accountable for timely remediation. Second, inventory is messy, especially in hybrid and distributed environments where installed apps drift over time and shadow software appears without approval.[3][4]
The third issue is operational friction. Many teams rely on patch cycles that were designed for predictable vendor releases, but third-party vendors do not all move at the same pace, and some products update far more frequently than patch teams can easily absorb. That means patch managers spend a lot of time chasing one-off updates, exceptions, and user-impact concerns instead of running a clean, repeatable process.[5]
The real risk
The risk is not just that third-party software has vulnerabilities; it is that these vulnerabilities often sit in the most widely deployed, least scrutinised tools on the endpoint. Recent CVE reporting in early 2026 included multiple critical issues across Microsoft, Cisco, Ivanti, and other vendors, showing how quickly exploitable flaws can appear across the software stack. Even when vendors patch quickly, the exposure window stays open if the affected apps are not in the routine remediation workflow.[6]
There is also a growing visibility problem. Research published in January 2026 found that 64% of third-party apps on 4,700 leading websites accessed sensitive data without business justification, up from 51% in 2024, with tools like Google Tag Manager, Shopify, and Facebook Pixel showing up in the findings. That is a web-app example rather than endpoint patching, but it reinforces the same point: third-party software introduces risk that organisations often underestimate until it is already embedded in operations.[7]
What good looks like
A stronger patch program for third-party applications starts with visibility. Teams need an accurate software inventory, version tracking, and a way to distinguish business-critical apps from software that is merely present on endpoints. Once that exists, patch owners can build policies around app groups rather than treating every product as a special case.[4][3]
Good programs also define clear patch SLAs by application category. Browsers, communication tools, endpoint utilities, and internet-facing software should generally have tighter deadlines than low-risk internal tools, because their exposure and exploitability are different. The goal is not to patch everything the same way; it is to make patching predictable enough that third-party apps stop becoming a separate exception track.[5]
Practical next steps
If you want to reduce third-party blind spots, start with a simple checklist:
- Build an authoritative software inventory across endpoints (SBOM)
- Identify the top 20 third-party applications in use.
- Map each app to an owner, update cadence, and patch deadline.
- Separate business-critical tools from low-value or rarely used software.
- Include third-party patch coverage in compliance reporting.
That last point matters because visibility changes behaviour. If leadership can see that third-party apps are excluded from patch workflows, the issue becomes easier to prioritise and measure. The organisations that treat third-party patching as a formal control, not an afterthought, are much more likely to keep their attack surface under control.[2][8]
