What Is Patch Management? Process, Tools & Best Practices

Patch management is the structured process of finding, prioritizing, testing, and deploying software updates so that known vulnerabilities are closed before attackers can exploit them. It sounds simple, keep software up to date, but at enterprise scale it is one of the hardest and highest-value problems in security, because vulnerabilities now appear faster than most teams can patch them and attackers weaponize them within days. This guide explains what patch management is, how the process works end to end, how to prioritize with modern frameworks (CVSS, EPSS, KEV, SSVC), where to automate, and the 2026 best practices that keep it effective.

Updated: November 2026. Reflects the 2025 CVE record, the Verizon 2026 DBIR exploitation and remediation data, the CISA KEV catalog as of November 4, 2026, CISA's BOD 26-04 risk-based patch deadlines, EPSS v4, and the NVD's ongoing enrichment and prioritization changes. Adds a patch management statistics section.

The quick answer

The one line to remember: patching is not about installing every update; it is about closing the flaws attackers are actually exploiting, fast, and proving the path is really shut.

DeepStrike's continuous penetration testing can retest fixed findings and new changes to check that a patch actually closed the exploit path, instead of relying only on a deployment report that says it installed.

What is patch management?

Patch management is the coordinated process of identifying, prioritizing, acquiring, testing, and installing software patches across an organization's systems, operating systems, applications, and firmware. Its purpose is preventive: close known security holes before they are exploited, while keeping systems stable and compliant. CISA puts it plainly: the best defense against attackers exploiting patched vulnerabilities is to keep your software up to date, which in practice means enabling automatic updates where safe and rapidly applying critical fixes when vendors ship them.

It sits inside the broader discipline of vulnerability management: vulnerability management finds and assesses all weaknesses (including ones with no patch, like misconfigurations), while patch management is the specific act of deploying the updates that fix them. Patching is the most common remediation, but not the only one.

Types of patches

Patch management is broader than security fixes alone. Common patch categories include:

• Security patches: close known vulnerabilities and reduce exploit exposure.
• Bug fixes: correct defects that affect stability, reliability, or functionality.
• Feature and performance updates: add capabilities or improve how software behaves.
• Firmware and driver updates: fix security, compatibility, or stability issues in hardware-facing software.

In a cybersecurity program, security patches usually receive the highest urgency because delay directly increases the time an exploitable weakness remains open. In 2017, WannaCry hit organizations that had not applied a Microsoft patch released two months earlier.

Why patch management matters more in 2026

The gap between "a vulnerability is published" and "it is being exploited" has collapsed, and the volume has exploded.

• Record vulnerability volume. A record 48,185 CVEs were published in 2025, up 20.6% year over year, roughly 132 per day, according to Jerry Gamblin's 2025 CVE data review. The NVD continues to prioritize enrichment as it works through a substantial backlog, so teams should not wait for complete NVD enrichment before making urgent remediation decisions.
• Exploitation is now the number-one way in. The Verizon 2026 DBIR found that vulnerability exploitation accounted for 31% of breaches' initial access, up from 20% the previous year. For the first time in the report's history it overtook credential abuse (13%) to become the leading initial-access vector.
• The edge is where it happens. In Verizon's 2025 DBIR, edge devices and VPNs were the target in 22% of vulnerability-exploitation breaches, up from 3% a year earlier, a sevenfold jump. These internet-facing appliances are simultaneously the most targeted and often the hardest to patch quickly, which is exactly why they deserve their own fast lane.
• Remediation is getting slower, not faster. Verizon's 2026 DBIR found that only 26% of CISA KEV vulnerabilities were fully remediated in 2025, down from 38% the year before, and the median time to remediate a known-exploited flaw rose from 32 to 43 days. That is the gap this whole discipline exists to close.
• The catalog of what's actually exploited keeps growing. CISA's Known Exploited Vulnerabilities (KEV) catalog held 1,768 entries as of November 4, 2026, each one a flaw confirmed to be used in real attacks and, for federal agencies, carrying a mandatory patch deadline.

The consequences are concrete. In a 2025 CISA advisory, a US federal agency was breached because attackers walked through a known GeoServer flaw (CVE-2024-36401) that was exploited 11 days after disclosure while still unpatched; multiple servers were compromised and the intruders roamed the network for weeks. CISA's verdict was blunt: patches came too slowly, response plans were untested, and alerts were missed. Even a few days' delay on a critical, exploited flaw can turn a routine update into a full breach, which is also why unpatched, internet-facing systems are the first thing an attack surface management program hunts for.

Patch management supports technical-vulnerability and security-maintenance requirements across ISO/IEC 27001, HIPAA, PCI DSS, and CIS Controls, with PCI DSS and CIS Control 7 providing particularly explicit remediation expectations.

Patch Management Statistics for 2026

These numbers come from primary sources, and each measures something different: breach investigations, scanner telemetry, a federal catalog, or one vendor's customer base. Read every figure against its own population and period before comparing it with another. For wider vulnerability data, see our vulnerability statistics roundup; for how quickly new flaws are weaponized, see zero-day exploit statistics.

Sources for the table: the Verizon 2026 Data Breach Investigations Report, Microsoft Security's analysis of exploited vulnerabilities, CISA's Known Exploited Vulnerabilities catalog and BOD 26-04, and the two vendor studies described below.

Time to patch: what the 2026 DBIR found

Verizon's 2026 DBIR covers incidents from November 1, 2024, to October 31, 2025. Vulnerability exploitation was the initial access vector in 31% of breaches, up from 20% a year earlier, and it overtook credential abuse (13%) for the first time. Remediation moved the wrong way: only 26% of CISA KEV vulnerabilities were fully remediated in 2025, down from 38%, and the median time to full remediation rose from 32 to 43 days. In the median case, organizations also had 50% more critical vulnerabilities to patch than the year before.

The 2025 edition adds context for edge devices. Verizon tracked a sample of edge-device and VPN vulnerabilities from the KEV list: about 54% were fully remediated during the year, at a median of 32 days, compared with 38% for the KEV catalog as a whole and just 9% for all vulnerabilities found in scans. Each edition calculates its medians on its own dataset, so compare years within one report rather than across reports.

Asset type matters as much as the average. Microsoft's November 2026 analysis of its Security Exposure Management data found that the median vulnerability is patched in about two weeks on Windows workstations, in more than a month on Windows Server, in more than 10 weeks on Linux servers and macOS applications, and in more than a year on network appliances. Citing CISA data, the same analysis reports that the mean time from CVE publication to a KEV listing fell from 89 days in 2024 to 57 days in 2025, and to 20 days in 2026 through September, with a median of three days.

The CISA KEV catalog in numbers

CISA adds a vulnerability to the Known Exploited Vulnerabilities catalog when it has a CVE ID, reliable evidence of exploitation in the wild, and a clear remediation action. On November 4, 2026 (catalog version 2026.11.04), the catalog held 1,768 entries. It ended 2025 with 1,484 after 245 additions that year, and 284 entries have been added in 2026 so far, already more than in all of 2025. CISA marks 361 entries as known to be used in ransomware campaigns.

Exploitation is concentrated and fast. When CISA launched the catalog in 2021, it noted that fewer than 4% of all CVEs had been publicly exploited, and that of those, 42% were used on the day of disclosure, 50% within two days, and 75% within 28 days. Microsoft's 2026 analysis puts the exploited share at about 2,000 of roughly 383,000 CVEs disclosed since 1999, or about 0.5%. That is why patching the KEV list first beats patching by severity score alone.

Federal patch deadlines: from BOD 22-01 to BOD 26-04

BOD 22-01, issued November 3, 2021, created the KEV catalog and gave federal civilian agencies default deadlines: six months for vulnerabilities with CVE IDs assigned before 2021, and two weeks for all others, with shorter timelines possible in cases of grave risk. In practice, due dates for new entries clustered at 21 days. In our analysis of the KEV feed, 401 of the 431 entries added in 2024 and 2025 (93%) carried a 21-day due date.

On June 10, 2026, CISA issued BOD 26-04, which revoked BOD 22-01 and BOD 19-02. Instead of one deadline per catalog entry, it sets the deadline from four questions: is the asset publicly exposed, is the CVE in KEV, can an adversary automate exploitation, and does exploitation give partial or total control? Deadlines are calendar days. The clock starts when CISA adds the CVE to KEV or when the agency finds it on an asset, whichever comes first. The most severe combinations also require a forensic triage to check whether the system was already compromised. Agencies have 180 days from issuance to meet the new timelines.

The table restates BOD 26-04 Appendix A, Table 1, which CISA publishes as an image; the CERT/CC SSVC encoding of the BOD 26-04 decision table gives the same values as text. CISA's implementation guidance explains that each KEV entry's due date is calculated from this table, so a publicly exposed, automatable flaw that gives total control shows a 3-day deadline.

The change is visible in the catalog. Of the 151 entries added from June 10 to November 4, 2026, 120 (79%) carried a 3-day due date, and the other 31 carried 14 days. None carried 21 days.

BOD 26-04 binds only federal civilian executive branch agencies, and it does not apply to contractors unless their contracts say so. It is still the most useful public benchmark for anyone writing patch SLAs. If an internal policy or contract still sets one flat 14-day or 21-day window for every KEV flaw, it reflects the revoked directive. A simple update is to ask the same four questions and give exposed, automatable, total-control flaws a 3-day lane.

Vendor research: Edgescan and Ponemon for ServiceNow

Two widely quoted sources are vendor research, so read them with that in mind. The Edgescan 2026 Vulnerability Statistics Report draws on Edgescan's own assessments and penetration tests of hundreds of organizations during 2025. It reports an average time to remediate high and critical vulnerabilities of 54.8 days for applications and APIs and 39 days for devices and networks, and it found that larger enterprises (1,000 or more employees) left 37% of the vulnerabilities discovered in a 12-month period unremediated. These figures describe Edgescan's customer base, not a representative sample.

The often-repeated line that "60% of breaches involve an unpatched vulnerability" traces to the 2019 Ponemon Institute study sponsored by ServiceNow, a survey of almost 3,000 IT security professionals in eight countries. The actual finding is narrower: 48% of respondents said their organization had a breach in the previous two years, and 60% of those said a breach could have occurred because a patch was available but not applied. Of that group, 62% were unaware or unsure that they were vulnerable before the breach. The data is self-reported, sponsored and seven years old, so treat it as historical context rather than a current breach rate.

What the numbers mean for your program

• Benchmark against both clocks. Compare your median time to fully remediate KEV flaws with the DBIR's 43 days, and your exposed, high-impact KEV flaws with BOD 26-04's 3-day and 14-day tiers.
• Split the numbers by asset class. A single average hides servers and network appliances, which Microsoft's data shows are patched far more slowly than workstations. Report them separately, starting with what is internet-facing; our attack surface management guide covers how to find those assets.
• Count full remediation, not deployment. The DBIR measures vulnerabilities that were fully remediated, and a partial rollout leaves the path open on the remaining assets. Validate closure with targeted retesting. DeepStrike's continuous penetration testing services test application changes as they ship, which helps confirm that a fix actually closed the exploit path.
• Recheck the sources every year. Verizon and Edgescan publish annually, the KEV catalog changes most weeks, and CISA has committed to reassess the BOD 26-04 timelines once per fiscal year.

How patch management works: the process

Patch management is a continuous cycle, not a one-time project.

1. Inventory and discover. Maintain an accurate, live asset inventory, servers, endpoints, mobile, cloud, containers, firmware, and the software versions on each. You cannot patch what you do not know you have, and unknown assets are where breaches start.
2. Assess and prioritize. For each missing patch, judge real risk: is it in CISA KEV (actively exploited)? What is its EPSS exploitation probability? How critical and exposed is the asset? This is where most programs succeed or drown, more on frameworks below.
3. Test. Apply updates to a staging environment or a pilot ring first, to catch compatibility and stability problems before they hit production.
4. Deploy. Roll approved patches to production in stages (ring deployment) during maintenance windows, using automation to reach every endpoint, including remote and previously offline devices.
5. Verify. Confirm patches actually installed and the systems are stable, and, critically, validate that the vulnerability is truly closed. Installation is not the same as remediation; a patch reported "installed" can still leave an exploitable path if a service was not restarted or a workaround was missed.
6. Record and monitor. Capture deployment status, failures, exceptions, pending restarts, rollbacks, and audit evidence. Continue monitoring for systems that missed, reverted, or could not receive the patch.
7. Repeat. New CVEs land daily. The cycle runs continuously, weekly or faster for critical fixes.

How to prioritize: CVSS, EPSS, KEV, and SSVC

You cannot patch 48,000 CVEs a year, and you should not try. The single biggest upgrade most programs can make is prioritizing by exploitation risk, not raw severity. Here is how the modern signals differ and combine.

The practical recipe: patch everything in KEV first, then use EPSS to rank the rest against asset criticality and exposure, and use SSVC (or a similar decision model) to make the call auditable. Severity alone, treating every CVSS 9 as equally urgent, wastes the scarce patching window on flaws no one is exploiting while a quietly-exploited CVSS 7 sits open.

What if a patch is not available?

Not every vulnerability has an immediate vendor fix. In those cases, the goal is to reduce exploitability until a permanent remediation exists.

The key is to treat temporary workarounds as time-bounded exceptions. Every exception should have an owner, review date, and trigger for reassessment.

Manual vs automated patch management

At any real scale, manual patching cannot keep up. The question is not whether to automate but where to keep humans in the loop.

The right model is automation for the routine majority, with human review reserved for exceptions: fragile legacy systems, high-change-control assets, and patches that failed pilot testing. Automation frees the team to focus on the judgment calls instead of clicking through updates.

Patch management tools

Dedicated platforms scan endpoints, identify missing updates, and deploy across many operating systems and applications, with reporting for compliance. Common options include ManageEngine Patch Manager Plus (broad third-party app coverage), Ivanti Neurons for Patch Management (threat-intelligence-driven prioritization), Microsoft Intune with WSUS/Configuration Manager, Automox, Tanium, and SolarWinds Patch Manager. When evaluating tools, look for:

• Broad coverage across all your OSes and critical third-party software, plus firmware and, increasingly, containers and cloud workloads.
• Automation with pilot-ring testing and staged rollout, not just push-everything.
• Risk-based prioritization that ingests CISA KEV and EPSS, so the tool tells you what to patch first, not just what is missing.
• Reporting and compliance dashboards to evidence ISO 27001, PCI DSS, and HIPAA controls.
• Scalability to remote, mobile, and intermittently-connected endpoints.

For MSPs evaluating patch automation within a broader remote-management platform, the RMM platforms compared in Flamingo’s guide provide a starting point for comparing features and pricing. Validate operating-system coverage, third-party patch support, staged deployment, and reporting against your own requirements.

Scheduled vs emergency patching

Not every update belongs in the same change window.

• Scheduled patching handles routine operating-system, application, firmware, and third-party updates through normal maintenance cycles and pilot rings.
• Emergency or out-of-band patching is used when a vulnerability is actively exploited, appears in CISA KEV, affects a critical internet-facing system, or creates unacceptable business risk.

Emergency patching should move faster than the normal cycle, but it should not abandon testing, rollback planning, or approval entirely. The objective is to compress the process safely, not skip it.

Common patch management challenges

Most programs fail on the same few obstacles, not on a lack of tools:

• Unknown assets: shadow IT, forgotten cloud instances and unmanaged devices never get patched because no one knows they exist.
• Downtime windows: business-critical systems often have narrow or rare maintenance windows, so urgent patches wait.
• Third-party applications: browsers, runtimes and business apps from many vendors each ship updates on their own schedule, outside the operating system update channel.
• Remote and intermittently connected endpoints: laptops that rarely join the corporate network miss deployment waves unless patching works over the internet.
• Update supply-chain risk: the update mechanism itself can be abused, as in the 2021 Kaseya VSA attack, so verify the source and integrity of patches and the tools that deploy them.

Cadence adds pressure too: Microsoft releases most of its security updates on Patch Tuesday, the second Tuesday of each month, so many teams plan their monthly cycle around it while keeping an out-of-band lane for actively exploited flaws.

Best practices for 2026

• Formalize a patch policy. Define ownership, covered systems, and patching SLAs by severity, with executive buy-in and mapping to ISO 27001 A.8.8 and CIS Control 7.
• Set SLAs by risk, and honor the KEV deadlines. A practical model: actively-exploited (KEV) flaws in days, critical internet-facing in a week or two, others on the normal cycle. Match or beat CISA's federal KEV deadlines even if you are not a federal agency.
• Inventory everything, continuously. Unknown and unmanaged assets are the ones that get exploited.
• Prioritize by exploitation risk, using KEV + EPSS + asset context, not CVSS in isolation.
• Test, then deploy in rings. Pilot first; expand in waves so a bad patch never takes down the whole estate at once.
• Always have a rollback plan. Backups and a tested recovery procedure, so a failed patch is an inconvenience, not an outage.
• Prioritize the edge. VPNs, firewalls, and other internet-facing appliances are now top exploitation targets and often the slowest to patch, give them their own fast lane.
• Patch the cloud and containers too. Rebuild and redeploy images rather than patching running containers in place; treat base images as part of the inventory.
• Sunset unsupported systems. End-of-life software cannot be patched; isolate or decommission it.
• Verify remediation, do not assume it. Validate that the exploit path is closed. Deployment reports show installation, not remediation; targeted testing checks whether the path is actually closed. Citrix Bleed showed why: sessions stolen before a patch could persist after it, as our Comcast settlement guide explains.
• Coordinate IT and security. Security sets priorities from threat intelligence; IT operations executes, and both own the outcome.

Patch management KPIs that show the program is working

Track outcomes, not just the number of patches deployed. For external benchmarks, the Verizon 2026 DBIR reported a median 43 days to remediate a known-exploited vulnerability and only 26% of KEV flaws fully remediated, so beating those numbers is a reasonable first target.

A healthy program should reduce both patch age and exception volume over time while keeping failed deployments and rollback rates under control.

Patch management vs vulnerability management

These terms are used interchangeably, but they are not the same, and the distinction matters for scoping a program.

Patching is the sharpest tool in the vulnerability-management toolbox, but some risks have no patch, which is why the two work together. Our vulnerability management guide covers the full cycle.

Conclusion

Patch management is not an optional chore; it is one of the highest-return controls in security, and in 2026 the margin for delay has narrowed to days. Inventory everything, prioritize by what is actually being exploited (KEV and EPSS, not CVSS alone), automate the routine majority, test and deploy in rings, keep a rollback plan, and verify that the flaw is truly closed. Do that consistently and you remove the easy, well-publicized doors attackers rely on.

The last step, proving the path is actually shut, is where testing comes in. DeepStrike's penetration testing and external penetration testing validate that your patches and configurations really closed the vulnerability an attacker would target, not just that an update installed. For US-based teams, see our penetration testing services.

About the Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

FAQ

What is patch management?

Patch management is the ongoing process of tracking, acquiring, testing, and installing software updates across an organization's operating systems, applications, and firmware. Its goal is to close known security vulnerabilities before attackers exploit them, while keeping systems stable and meeting compliance requirements.

Why is patch management important?

Unpatched, known vulnerabilities remain a major breach driver. Verizon's 2026 DBIR found that vulnerability exploitation accounted for 31% of breaches' initial access, overtaking credential abuse as the leading initial-access vector. Attackers can weaponize published flaws quickly, so timely patching removes some of the easiest attack paths. Patch management also supports technical-vulnerability and security-maintenance expectations across frameworks such as ISO 27001, PCI DSS, HIPAA, and CIS Controls.

What are the steps in the patch management process?

The cycle is: inventory and discover all assets and their software; assess and prioritize missing patches by exploitation risk; test updates on a pilot group; deploy approved patches in stages to production; verify installation and confirm the vulnerability is actually closed; and repeat continuously as new CVEs appear.

How should I prioritize which patches to apply first?

Do not rely on CVSS severity alone. Patch anything in CISA's Known Exploited Vulnerabilities (KEV) catalog first, since those are confirmed to be exploited. Then use EPSS (exploitation probability) combined with how critical and exposed each asset is, and a decision model like SSVC to make the call defensible.

What is the difference between patch management and vulnerability management?

Patch management is specifically about deploying software updates. Vulnerability management is broader: it finds, assesses, and remediates all security weaknesses, including ones with no patch, such as misconfigurations or exposed services, using configuration changes and compensating controls as well as patches. Patching is one step within it.

What is automated patch management?

Automated patch management uses software to scan systems and download, test, and deploy patches with minimal manual effort. It scales to thousands of endpoints, improves consistency, and reduces human error. Best practice is to automate the routine majority while keeping human review for fragile legacy systems and patches that fail pilot testing.

How fast should critical patches be applied?

As fast as your process safely allows. For actively exploited flaws (in CISA KEV), aim for days, matching or beating the federal deadlines CISA sets. Critical internet-facing systems, especially edge devices like VPNs and firewalls, deserve their own fast lane, since those are now among the most heavily exploited targets.

What are the most important patch management statistics for 2026?

Verizon's 2026 DBIR found that vulnerability exploitation started 31% of breaches, that only 26% of CISA KEV vulnerabilities were fully remediated in 2025, and that the median time to full remediation rose to 43 days. CISA's KEV catalog held 1,768 entries on November 4, 2026, and 79% of the entries added since BOD 26-04 took effect on June 10, 2026, carry a 3-day federal deadline.

How long do organizations take to patch known exploited vulnerabilities?

The median organization took 43 days to fully remediate a KEV vulnerability in 2025, up from 32 days, according to the Verizon 2026 DBIR. Speed varies by asset: Microsoft's 2026 data shows about two weeks for Windows workstations and more than a year for network appliances. For comparison, BOD 26-04 gives US federal agencies 3 or 14 days for every KEV flaw, depending on exposure, automation and impact.