What is Patch Management?
Patch management deploys software updates that fix security vulnerabilities. Learn how it works, why it fails, and what a 15-day attacker timeline means for your patching cadence.
What Patch Management Involves
Patch management encompasses the full lifecycle of software updates from identification through deployment and verification. Vulnerability scanners and vendor advisory subscriptions identify when new patches are available and what vulnerabilities they address. Risk assessment determines prioritization — which patches must be applied immediately, which can follow a regular schedule, and which require testing before deployment due to compatibility risk. Patch deployment pushes updates to systems, either through automated deployment tools or manual processes. Verification confirms that patches were applied successfully and that the patched systems are functioning correctly.
The Complexity Problem
Enterprise environments contain heterogeneous software estates: Windows operating systems across multiple versions, third-party applications, web browsers, browser plugins, network equipment firmware, cloud platform configurations, and increasingly containerized and serverless workloads that have their own update cycles. Each software component has its own vendor, its own update cadence, its own testing requirements, and its own deployment mechanism. A mid-market organization might manage patches across hundreds of distinct software components. The operational complexity of tracking, prioritizing, and deploying this volume of updates is significant even with patch management tooling.
Why Patch Management Fails
The technical mechanics of patching are well-understood. The operational execution is consistently poor — for predictable reasons.
Patch testing delays are the most common cause of patch management failure at enterprise scale. IT teams reasonably concern themselves with the risk that a patch will break production systems — a documented occurrence with some Microsoft and enterprise software patches. The response is testing patches in non-production environments before production deployment. This is correct practice; the problem is when the testing cycle extends the deployment window to weeks or months, particularly for critical security patches where days of exposure represent significant risk.
Coverage gaps — systems that are not managed by the central patch management platform, that are not regularly online, or that are not in the asset inventory — are persistent failure points. Systems patched 95% of the time are protected 95% of the time. The remaining 5% of unpatched systems represent 100% of the attack surface for patches that were not applied. Attackers specifically scan for unpatched systems in otherwise well-managed environments.
Patch Management in the Enterprise Context
Effective enterprise patch management requires tool, process, and policy components. Patch management tools — Microsoft SCCM/Intune, Jamf, Ivanti, or equivalent — provide automated patch distribution, deployment status tracking, and compliance reporting. Process components include defined patch classification tiers with associated maximum deployment windows, testing procedures for critical systems, exception handling for systems that cannot be patched without service disruption, and regular compliance reporting to security leadership. Policy components establish the accountability and escalation procedures that ensure patch windows are enforced rather than treated as targets.
For cloud environments, patch management extends to the OS and application layer of cloud instances, container base images, cloud-native service configurations, and serverless function dependencies. Many organizations apply rigorous on-premises patch management while maintaining cloud infrastructure with outdated operating systems and unpatched container images — creating the attack surface exposure that cloud migration was supposed to reduce.
Real-World Example: ProxyLogon and the 30,000 Organizations That Didn't Patch Fast Enough
In March 2021, Microsoft disclosed the ProxyLogon vulnerabilities — a chain of Exchange Server flaws that enabled unauthenticated remote code execution on on-premises Exchange servers. Microsoft released patches simultaneously with disclosure. Within 24 hours of the patch release, multiple threat actors — including at least one nation-state group — began mass exploitation of unpatched Exchange servers globally. Within 3 days, an estimated 30,000 US organizations had been compromised. The window between patch availability and attacker exploitation was measured in hours. Organizations that applied the patch within 24 hours of release were protected; those that followed standard 30-day enterprise patch cycles had compromised Exchange servers before they patched.
Average time it takes attackers to weaponize a newly disclosed critical vulnerability after patch release — versus an average of 60+ days for organizations to complete enterprise-wide patch deployment. The attacker's timeline moves faster than most patch cycles.
.png)