Recommendations
- Review the average time between vulnerability discovery and remediation across your organization and compare it against your stated patching policy.
- Establish a quarterly metric review that tracks vulnerability volume, remediation time, and patch compliance trends across the organization.
- Generate a report of all third-party software deployed across employee endpoints and identify applications that fall outside your formal patch management program.
- Require business owners—not just IT—to participate in discussions involving exceptions for critical vulnerabilities and delayed remediation.
- Implement remediation service-level agreements based on risk categories rather than applying a single patching standard across all assets.
For years, patch management was treated as one of the least glamorous responsibilities in IT. It rarely appeared in board presentations or strategic roadmaps. Patches were simply something technology teams applied during maintenance windows before moving on to more pressing work.
That model worked when environments were smaller and more predictable. Organizations managed a limited number of servers, employees worked inside corporate networks, and software releases followed relatively stable schedules. A monthly patch cycle was often sufficient.
Those assumptions no longer hold.
Modern organizations operate across cloud platforms, remote endpoints, SaaS applications, containers, mobile devices, and third-party software ecosystems. At the same time, vulnerabilities are being discovered at a pace that would have been difficult to imagine even a decade ago. According to the National Vulnerability Database, tens of thousands of new vulnerabilities continue to be disclosed annually, creating a volume problem that most organizations are not equipped to handle.
The uncomfortable reality is that patching has evolved from a technical maintenance activity into an operational scalability problem. Verizon’s 2026 Data Breach Investigations Report found that vulnerability exploitation accounted for 31% of initial access vectors, surpassing many traditional attack methods.
Attackers have adapted to the speed of modern technology, while many patch management programs lag behind.
The Maintenance Window Was Built for a Different Era
If you asked an IT leader to describe their patching process, the answer would likely sound familiar.
Vulnerabilities are identified, tickets are created, patches are tested, approvals are obtained, and maintenance windows are scheduled. Assuming nothing breaks, updates are deployed and documentation is completed.
There is nothing inherently wrong with this process. In fact, it reflects decades of operational discipline. The problem is that it was designed for environments that no longer exist.
A typical enterprise now manages thousands of assets across multiple environments. Endpoints exist far beyond the corporate office, applications are delivered through the cloud, and employees routinely install software outside traditional procurement channels.
Meanwhile, threat actors are operating continuously.
The difference in tempo matters. Many organizations still operate on monthly patch cycles, while adversaries increasingly measure their timelines in days—or even hours. Recent research from the Cloud Security Alliance found that the mean time to exploit a disclosed vulnerability fell from approximately 32 days in 2022 to roughly five days in 2023, while 32.1% of newly tracked exploits in 2025 appeared on or before the vulnerability’s public disclosure date. In other words, organizations are often competing against threats that are already active before their patching processes have begun.
The question is no longer whether patches will be applied. It is whether they can be applied quickly enough to matter.
Recommendation: Review the average time between vulnerability discovery and remediation across your organization and compare it against your stated patching policy.
Vulnerabilities Are Growing Faster Than Teams Can Respond
Cybersecurity teams are facing a math problem.
Each month introduces new operating system updates, browser patches, application fixes, firmware releases, and third-party software vulnerabilities. Every additional asset adds another dependency to manage, another maintenance cycle to schedule, and another opportunity for something to be overlooked.
According to Verizon’s 2026 DBIR, vulnerability exploitation has become the leading initial access vector for breaches, accounting for nearly one-third of incidents investigated. At the same time, organizations continue to struggle with remediation timelines, often leaving critical vulnerabilities exposed for weeks or months. This should not be interpreted as negligence.
Most technology teams understand the importance of patching. They simply operate within competing constraints. Systems require uptime. Business units resist disruption. Legacy applications remain business critical despite their age. Every patch carries some degree of operational risk.
Research from Jason Nurse’s 2025 paper, To Patch or Not to Patch, found that patching failures are frequently the result of organizational and operational limitations rather than a lack of technical understanding.
In other words, organizations are not failing because they do not care. They are failing because humans are attempting to manage a problem that is growing faster than human processes can accommodate.
This builds on ideas explored in Reactive Organizations Cannot Scale Efficiently. Eventually, every reactive process reaches a point where volume exceeds capacity.
Recommendation: Establish a quarterly metric review that tracks vulnerability volume, remediation time, and patch compliance trends across the organization.
The Third-Party Software Problem
Most organizations have become reasonably proficient at patching operating systems.
Third-party software presents a different challenge entirely.
Consider the average employee laptop. It may include Chrome, Adobe Reader, Zoom, Slack, Teams, Java, VPN clients, password managers, and an expanding collection of AI applications. Each product maintains its own release schedule, security updates, and support lifecycle.
Adaptiva’s 2026 State of Patch Management Report found that 74% of organizations experienced vulnerabilities originating from third-party applications, yet many continue to prioritize operating system patching over broader software governance.
The problem becomes particularly visible during incident response efforts.
Imagine a hypothetical organization that maintains a 98% compliance rate for operating system patches. On paper, its patch management program appears highly effective. During a security assessment, however, the organization discovers outdated browser extensions, unsupported PDF readers, and unmanaged collaboration tools deployed across hundreds of endpoints.
Technically, the organization was compliant. Operationally, it remained exposed.
This is one of the reasons modern patching programs continue to struggle. The conversation often begins with Microsoft Patch Tuesday and ends before addressing the other hundreds of applications operating throughout the environment.
As discussed in Your SaaS Stack Is Out of Control, software portfolios have expanded significantly over the past decade. Every application introduced into the environment creates an ongoing maintenance obligation.
Technology decisions have a long memory.
Recommendation: Generate a report of all third-party software deployed across employee endpoints and identify applications that fall outside your formal patch management program.
When Patching Becomes a Business Decision
One of the most persistent myths in cybersecurity is that patching is purely a technical issue. In reality, patching decisions frequently involve business tradeoffs.
Consider a manufacturing organization running legacy production systems. Applying a patch may improve security, but it may also introduce downtime that affects revenue. Financial institutions face similar challenges when updates intersect with trading platforms or payment systems. Healthcare organizations must balance security requirements against the availability of clinical systems.
This tension explains why patching remains difficult despite decades of investment.
A useful example is the widespread exploitation of the MOVEit vulnerability in 2023. Organizations across multiple industries experienced downstream impacts because vulnerabilities within third-party software affected hundreds of customers simultaneously. In many cases, organizations had little direct control over remediation timelines.
Incidents like MOVEit highlight an important truth: patch management is no longer confined to internal systems. It now extends across vendors, suppliers, and software providers.
That reality changes the conversation.
Executives should not be asking whether patching is important. They should be asking:
- Which systems represent our greatest exposure?
- Which vulnerabilities are actively being exploited?
- Which vendors present the greatest operational risk?
- How quickly can we realistically remediate critical issues?
High-performing organizations recognize that perfect patch compliance is an unrealistic objective. Risk reduction is not.
Recommendation: Require business owners—not just IT—to participate in discussions involving exceptions for critical vulnerabilities and delayed remediation.
Risk-Based Patching Is Replacing “Patch Everything”
For many years, the prevailing philosophy was simple: patch everything as quickly as possible.
That advice made sense when vulnerability volumes were manageable. It becomes significantly less practical when organizations are evaluating thousands of findings across distributed environments.
Leading organizations are shifting toward risk-based patching models that prioritize remediation according to exploitability, business impact, and asset criticality.
Ivanti’s research on risk-based patch prioritization found that organizations continue to struggle with remediation prioritization and compliance, reinforcing the need for more strategic approaches to vulnerability management.
This shift reflects a broader change in cybersecurity philosophy.
Security teams are beginning to ask different questions:
- Is this vulnerability being actively exploited?
- Does it affect a critical business system?
- Is the affected asset internet-facing?
- What is the operational impact if remediation is delayed?
The goal is not to ignore low-risk vulnerabilities. The goal is to ensure limited resources are applied where they produce the greatest reduction in risk.
Organizations that continue treating every vulnerability equally often discover that they are simultaneously overwhelmed and ineffective.
Portfolio management principles apply here as well. Not every issue deserves the same level of urgency.
Recommendation: Implement remediation service-level agreements based on risk categories rather than applying a single patching standard across all assets.
AI Is Changing the Speed of Cybersecurity
The most significant change may not be the number of vulnerabilities. It may be the speed at which the ecosystem now operates.
Artificial intelligence is already influencing vulnerability discovery, exploit development, and threat analysis. Security researchers are using AI to identify weaknesses more efficiently, while adversaries are leveraging similar capabilities to accelerate exploitation efforts.
Organizations, however, continue to operate patching programs built around monthly cycles and manual approvals.
That mismatch should concern business leaders.
A vulnerability that remains unpatched for thirty days was once considered manageable in many environments. Today, thirty days can represent dozens of exploit attempts, multiple threat actor campaigns, and a substantial increase in exposure.
This trend reinforces a larger point: patching is becoming less about maintenance and more about resilience.
Organizations that thrive over the next decade will not necessarily possess the largest security teams or the most sophisticated tools. They will have built operating models capable of adapting to change faster than their peers.
That capability extends far beyond cybersecurity. It is ultimately a measure of organizational agility.
Recommendation: Evaluate opportunities to automate patch deployment for low-risk systems and reserve manual intervention for critical assets and business applications.
Conclusion
Patching has always been about reducing risk. What has changed is the speed at which that risk accumulates.
For years, organizations approached patch management as a routine IT function supported by maintenance windows and operational checklists. Today, vulnerabilities emerge faster, environments are more complex, and attackers are operating with unprecedented efficiency.
Organizations do not get breached because they lack patching policies. They get breached because their patching programs cannot operate at the speed of modern threats.
The companies that will succeed over the next decade will not necessarily patch everything first. They will understand what matters most, automate wherever possible, and continuously reduce the time between discovery and remediation.
Because every unpatched vulnerability is ultimately a decision.
And eventually, every decision comes due.