Patch Management

# Patch Management

Definition

Patch management is the operational process of identifying, testing, deploying, and verifying software updates (patches) that fix security vulnerabilities, correct bugs, and improve functionality across an organization's technology environment. It is the highest-volume remediation activity in cybersecurity operations: a mid-market organization deploys hundreds to thousands of patches per month across operating systems, applications, firmware, and cloud infrastructure.

Patching is not glamorous. It does not appear in conference keynotes or vendor marketing. It is the cybersecurity equivalent of brushing your teeth: boring, repetitive, unglamorous, and the single most effective preventive measure available. The majority of exploited vulnerabilities have patches available at the time of exploitation. CISA's Known Exploited Vulnerabilities (KEV) catalog documents over 1,000 vulnerabilities that are actively exploited in the wild, and every one of them had a vendor-supplied patch available when the exploitation was observed.

The gap between patch availability and patch deployment is where breaches live. Attackers do not need zero-days when organizations take 60 to 90 days to deploy patches for critical vulnerabilities. The median time to exploit a vulnerability after public disclosure has compressed from weeks to days. The exploitation window is shrinking. Patch deployment timelines must shrink faster.

How It Works

The Patch Management Cycle

Patch management operates as a continuous cycle with five phases:

Identification. Monitor vendor release channels, security advisories, CISA alerts, and vulnerability databases (NVD, CVE) for new patches relevant to the organization's technology stack. Identification includes classifying each patch by severity (critical, high, medium, low), affected systems, and whether the patch addresses a vulnerability with known active exploitation.

Identification must be comprehensive. The organization patches Windows servers through WSUS or SCCM. It patches Linux servers through package managers. It patches network devices through vendor-specific management platforms. It patches cloud infrastructure through provider APIs. It patches SaaS applications through vendor-managed updates (which the organization may not control). It patches firmware on IoT devices, printers, and embedded systems through manual processes. Each platform requires its own identification channel. Missing one channel means missing patches for that platform entirely.

Testing. Before deploying a patch to production, test it in a representative non-production environment to verify that it does not break functionality, cause application failures, or create compatibility issues. Testing is the quality gate that prevents the cure from being worse than the disease.

The operational tension: thorough testing takes time. Time is what the attacker uses. A critical patch tested for two weeks in a lab while the vulnerability is actively exploited in the wild is a risk management decision, not a best practice. CDA's recommended approach: critical patches with known active exploitation (CISA KEV entries) receive abbreviated testing (4 to 8 hours in a staging environment) before emergency deployment. High-severity patches receive standard testing (24 to 48 hours). Medium and low patches follow the normal change management cycle.

Deployment. Deploy the tested patch to production systems. Deployment methods vary by platform:

Automated deployment tools (SCCM/MECM, Intune, Jamf, Ansible, Chef, Puppet) push patches to managed endpoints and servers on a defined schedule. Automation is essential for scale. An organization with 5,000 endpoints cannot deploy patches manually.

Cloud-native patching (AWS Systems Manager Patch Manager, Azure Update Management, GCP OS Patch Management) automates patching for cloud workloads within the provider's management framework.

Network device patching requires vendor-specific tools or manual processes. Firmware updates for firewalls, switches, routers, and wireless access points are often the slowest to deploy because they require maintenance windows and may involve service disruption.

Application patching varies by application type. SaaS applications are patched by the vendor (the organization's control is limited to verifying the patch was applied). On-premises applications require vendor-provided patches deployed through the organization's change management process.

Verification. After deployment, verify that the patch was successfully applied. A patch that was pushed but failed to install (service not restarted, prerequisite not met, deployment error) is not remediation. It is the appearance of remediation. Verification methods: re-scan with the vulnerability scanner to confirm the CVE no longer appears, query the endpoint management platform for installation status, or run a targeted check against the specific software version.

Reporting. Track and report patch compliance metrics: percentage of systems patched within SLA by severity tier, mean time to patch, number of systems with outstanding critical patches, and trend over time. Reporting feeds the governance cycle (RGA) and the posture score (SDP).

Patch Prioritization

Not all patches are equally urgent. Prioritization prevents the organization from treating every patch as an emergency (which causes change fatigue and deployment errors) or treating every patch as routine (which leaves critical vulnerabilities exposed for weeks).

CDA's recommended prioritization framework:

| Priority | Criteria | Deployment SLA | |----------|----------|---------------| | Emergency | CISA KEV entry (actively exploited) + internet-facing | 48 hours | | Critical | CISA KEV entry or CVSS 9.0+ with public exploit | 7 days | | High | CVSS 7.0-8.9 or vendor-rated critical | 14 days | | Standard | CVSS 4.0-6.9 | 30 days | | Low | CVSS below 4.0, feature updates | 60 days or next maintenance window |

The 48-hour emergency SLA for actively exploited, internet-facing vulnerabilities is aggressive. It is also necessary. When CISA adds a vulnerability to the KEV catalog, it means the vulnerability is being exploited right now against real organizations. Every day the patch is not deployed is a day the organization is vulnerable to an attack that is confirmed to be happening.

Common Challenges

Legacy systems. Systems running end-of-life operating systems or applications that no longer receive vendor patches. Windows Server 2012, CentOS 6, unsupported versions of Oracle, SAP, and custom applications. These systems cannot be patched because patches do not exist. Compensating controls (network isolation, virtual patching through WAF/IPS rules, enhanced monitoring) are the only option until the system is decommissioned or migrated.

Patching disruption. Some patches require system restarts, application downtime, or service interruption. Production systems with strict availability requirements resist patching because the patch window conflicts with business operations. The result: critical patches are deferred until the next maintenance window, which may be weeks away. The solution: redundancy (cluster failover during patching), rolling deployments (patch one node while others serve traffic), and defined maintenance windows that are frequent enough to accommodate critical patches.

Scope blindness. The organization patches what it knows about (managed endpoints, servers in the CMDB) and misses what it does not know about (shadow IT, unmanaged devices, acquired company infrastructure, developer workstations excluded from the management platform). Asset inventory (SPH) and attack surface management (VSD) are prerequisites for complete patch coverage. You cannot patch what you have not inventoried.

Third-party application patching. Operating system patches are well-supported by automation tools. Third-party application patches (Adobe, Java, Chrome, Firefox, Zoom, Slack, and hundreds of other applications) are harder to automate and often require application-specific deployment procedures. Third-party patching tools (Patch My PC, Ninite, Chocolatey, vendor-specific update mechanisms) address this gap but add operational complexity.

Firmware patching. Firmware on network devices, IoT devices, printers, industrial control systems, and medical devices is the most neglected patch category. Firmware updates are often manual, require physical access or specialized tools, and may carry operational risk (a failed firmware update can brick the device). Firmware vulnerabilities are also the most likely to be targeted by sophisticated adversaries (Volt Typhoon specifically targets edge network devices with outdated firmware).

Why It Matters

The Exploitation Timeline Has Compressed

In the early 2000s, months could pass between vulnerability disclosure and widespread exploitation. Organizations had time to evaluate, test, and deploy patches through normal change management cycles. That window has closed.

Modern exploitation timelines for high-profile vulnerabilities are measured in hours to days. Log4Shell was exploited within hours of disclosure. The MOVEit vulnerability was exploited as a zero-day before the patch was available. Citrix Bleed (CVE-2023-4966) was exploited within days of disclosure. The organizations that survived these events were the ones that deployed patches within the first week. The ones that waited for the next maintenance window were compromised.

Patching Prevents the Majority of Breaches

The vast majority of successful cyberattacks exploit known, patched vulnerabilities. The attacker does not need a zero-day when the target has not patched a vulnerability disclosed six months ago. A disciplined patch management program that deploys critical patches within 7 days and maintains over 95% patch compliance eliminates the majority of the attacker's exploit options.

This is not a theoretical claim. Analysis of breach data consistently shows that the initial access vector was a known vulnerability with an available patch that the organization failed to deploy. Patching is not the only control needed. But without it, every other control is compensating for a gap that should not exist.

Compliance Requirements

Every major compliance framework mandates patch management. PCI DSS 4.0 Requirement 6.3 requires identification and remediation of vulnerabilities with critical patches applied within one month. NIST CSF 2.0 PR.PS (Platform Security) includes patching as a core protective control. ISO 27001 A.8.8 (Management of Technical Vulnerabilities) requires timely identification and remediation. CMMC 2.0 requires vulnerability scanning and timely patching. HIPAA's Security Rule requires organizations to address known technical vulnerabilities. Auditors evaluate not just whether patches are deployed but whether deployment meets defined SLAs and whether compliance is tracked.

Related Articles

• Vulnerability Management
• Security Posture and Hygiene (SPH): The Terrain
• Vulnerability and Surface Defense (VSD): The Oceans
• Ransomware
• Attack Surface Management
• NIST Cybersecurity Framework (CSF) 2.0

Sources

1. Cybersecurity and Infrastructure Security Agency (CISA). "Known Exploited Vulnerabilities (KEV) Catalog." CISA.gov, updated continuously.
2. Cybersecurity and Infrastructure Security Agency (CISA). "Binding Operational Directive 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities." CISA, November 2021.
3. PCI Security Standards Council. "PCI DSS v4.0: Requirement 6.3 (Vulnerabilities Are Identified and Addressed)." PCI SSC, March 2022.
4. National Institute of Standards and Technology (NIST). "Cybersecurity Framework (CSF) 2.0: PR.PS (Platform Security)." U.S. Department of Commerce, 2024.
5. Mandiant (Google Cloud). "M-Trends 2024: Special Report." Mandiant, April 2024.

Word count: 1,963