There is an uncomfortable truth in security that is best accepted early: patching everything instantly is impossible. Every year tens of thousands of new vulnerabilities are published —the pace comfortably exceeds 25,000 CVEs a year— and no organization has enough maintenance windows, staff or tolerance for operational risk to apply every update the same day it appears. The right question, therefore, is not how do I patch faster, but what do I patch first.
Patch and CVE management is the organizational process that answers that question systematically. It is not about clicking "update" when an advisory appears, but about maintaining a reliable asset inventory, scanning regularly, prioritizing according to real risk and not just theoretical severity, remediating within defined deadlines and verifying that the patch actually closed the hole. Done well, this cycle turns an unmanageable mountain of vulnerabilities into a prioritized, workable queue.
In this article we explain what a CVE is and how its severity is scored with CVSS, why that score is not enough to prioritize, how EPSS and CISA's KEV catalog completely change the order of work, what the vulnerability management cycle looks like from end to end, the difference between zero-days and n-days, and how to set patching SLAs consistent with compliance demands such as NIS2.
What a CVE is and how CVSS measures its severity
A CVE (Common Vulnerabilities and Exposures) is a unique, public identifier for a specific vulnerability in a software or hardware product. It follows the CVE-YEAR-NUMBER format —for example CVE-2021-44228, the famous Log4Shell— and acts as a common reference so that vendors, researchers, security scanners and operations teams talk about exactly the same weakness without ambiguity. When a vendor or researcher discovers a flaw, it is assigned a CVE that centralizes all the associated information.
Each CVE is usually assigned a CVSS (Common Vulnerability Scoring System) score, a scale from 0 to 10 that measures technical severity. The base score is calculated from metrics such as the attack vector (is it exploitable over the network or does it require local access?), complexity, whether it needs privileges or user interaction, and the impact on confidentiality, integrity and availability. That produces the usual categories: critical (9.0–10), high (7.0–8.9), medium (4.0–6.9) and low (0.1–3.9).
CVSS is useful as a first approximation and as a common language, but it has a fundamental limitation: it describes how bad exploitation would be in the worst theoretical case, not the probability that exploitation will actually happen against your systems. And that is where many patching programs go wrong from top to bottom.
Why CVSS is not enough: EPSS and the KEV catalog
Prioritizing solely by CVSS leads to a classic mistake: treating every "critical 9.8" as equally urgent and pushing to the background lower-scored vulnerabilities that are, nevertheless, being actively exploited right now. A CVSS 9.8 with no known exploitation and no public exploit can be less urgent than a CVSS 7.5 that attackers are already using at scale. Severity is not the same as risk.
To correct this, modern prioritization adds two extra signals. The first is EPSS (Exploit Prediction Scoring System), a model that estimates the probability that a CVE will be exploited in the next 30 days, expressed as a percentage. A CVE with a 90% EPSS deserves immediate attention even if its CVSS is medium; one with an EPSS below 1% can wait for the next window even if its CVSS is high.
The second —and the most decisive— is the KEV catalog (Known Exploited Vulnerabilities) maintained by the US agency CISA. The KEV is a curated list of vulnerabilities for which there is confirmed evidence of real exploitation in the wild. If a CVE is on the KEV, it stops being a probability: someone is already using it against real organizations. The practical rule is simple and non-negotiable.
The golden rule of prioritization:
Patch first everything in CISA's KEV catalog, regardless of its CVSS. Then order the rest by combining EPSS (probability of exploitation), CVSS (impact) and each asset's exposure context: an internet-facing server is not the same as one isolated on an internal network with no outbound access.
Context is the third essential leg. The same vulnerability on an internet-facing web server does not carry the same risk as on a segmented system with no external connectivity. A good prioritization program crosses CVSS, EPSS and KEV with the asset's real exposure, its business criticality and the mitigations already in place (a WAF, network segmentation, access controls). You can consult the official list in CISA's KEV catalog, updated on a continuous basis.
The vulnerability management cycle
Vulnerability management is not a one-off task but a continuous cycle with five phases that repeat indefinitely. Skipping any of them breaks the entire chain:
- check_circle 1. Discover (asset inventory): you cannot patch what you do not know you have. The starting point is a reliable, up-to-date inventory of servers, services, versions, dependencies and libraries. "Forgotten" assets —an exposed test server, a VM nobody shut down— are attackers' favorite entry point.
- check_circle 2. Scan: tools such as Nessus, OpenVAS or Qualys compare installed software against CVE databases and detect which vulnerabilities affect each asset. Scanning should be regular (continuous or weekly for exposed assets) and also run after every change or deployment.
- check_circle 3. Prioritize: this is where CVSS, EPSS, KEV and exposure context are combined to turn hundreds of findings into an ordered queue. It is the phase where you decide what gets touched today and what can wait.
- check_circle 4. Remediate: this does not always mean patching. There are three valid responses: patch (apply the update), mitigate (apply a compensating control —a firewall rule, a WAF, disabling the vulnerable feature— when there is no patch or it cannot be applied yet) or accept the risk in a documented way when the impact is tolerable.
- check_circle 5. Verify: a patch does not count as applied until a new scan confirms the vulnerability is gone. Verification closes the cycle and prevents the false sense of security of believing something is fixed when it is not.
This cycle rests on a permanent balance between availability and security. Each patch usually implies a reboot or a maintenance window, and applying updates without control can break a production service. That is why organizations define planned maintenance windows and classify patches: critical and exploited ones justify an emergency window; the rest are grouped into regular cycles. Hardening the system beforehand reduces the surface you have to patch —see our Linux server hardening checklist to minimize the baseline risk.
Zero-day vs n-day: the enemy is usually old
There is a media fixation with zero-days: vulnerabilities exploited before a patch is available. They are dangerous, hard to anticipate and grab headlines. But they are the exception, not the norm. The vast majority of real breaches do not use zero-days, but n-days: vulnerabilities that have had a published patch for weeks, months or even years and that the victim simply had not applied.
Famous cases confirm it. The Equifax breach in 2017, which exposed the data of nearly 150 million people, exploited CVE-2017-5638 in Apache Struts: a flaw with a patch available two months before the attack. Log4Shell (CVE-2021-44228) was patched within days, but it kept being exploited for years in systems that were never updated. The MOVEit (CVE-2023-34362) wave hit hundreds of organizations as soon as the exploit went public. In every case the pattern is the same: the patch existed and had not been applied in time.
The lesson is liberating: you cannot control zero-days, but n-days —which are the majority— depend entirely on the discipline of your patching process. A solid vulnerability management program neutralizes the most common attack vector with no need for magic technology, only consistency.
Automation: scaling without breaking production
With dozens or hundreds of systems, manual patching does not scale. Automation is essential: patch management tools such as WSUS in Windows environments, package managers with centralized deployment, or automation platforms such as Ansible allow updates to be applied in a coordinated, repeatable and auditable way across entire server fleets.
That said, automating does not mean applying blindly. The rule is to test in staging first: deploy the patch to a test environment that mirrors production, verify that it breaks nothing, and only then promote it to production in controlled waves —first a pilot group, then the rest— with rollback capability if something fails. A patch that takes down a critical service can cause more operational damage than the vulnerability it fixes.
It is worth remembering that application software and the operating system are not the only vulnerable layer. Firmware —the part nobody updates— (BIOS/UEFI, BMC, controllers, network cards) also accumulates CVEs and must enter the same management cycle, even if its update cadence is different and more delicate.
Patching SLAs by severity
A mature program does not patch "when it can", but against target deadlines defined by severity and exploitation. Setting remediation SLAs turns good intentions into a measurable, auditable commitment. A common reference table, adjustable to each organization's risk appetite:
| Severity / condition | Target deadline | Example |
|---|---|---|
| In KEV catalog / actively exploited | 24–48 hours | Log4Shell, MOVEit |
| Critical (CVSS 9.0–10) | 7 days | Unauthenticated RCE on an exposed service |
| High (CVSS 7.0–8.9) | 15–30 days | Local privilege escalation |
| Medium (CVSS 4.0–6.9) | 30–90 days | Limited information disclosure |
| Low (CVSS 0.1–3.9) | Next window / 90+ days | Minor denial of service |
What matters about this table is not the exact figures but the principle it represents: presence in the KEV overrides CVSS. A vulnerability that is "only high" in severity but actively exploited enters the 24–48 hour emergency window, while a critical one with no known exploit can follow the normal cycle. Measuring SLA compliance —percentage of vulnerabilities remediated within deadline, mean time to remediate— is what lets you prove the process works.
Compliance (NIS2) and patch management with EasyDataHost
Vulnerability management has stopped being an optional best practice and become a regulatory requirement. The European NIS2 directive, which vastly expands the number of obligated entities, explicitly requires risk management measures that include vulnerability handling and disclosure, timely patch application and demonstrable security policies. Frameworks such as Spain's ENS or ISO 27001 point in the same direction: without a documented patch management process, there is no compliance that survives an audit.
The problem is that running this cycle well —inventory, continuous scanning, prioritization with KEV and EPSS, staging tests, maintenance windows and verification— demands staff, tools and discipline that many organizations cannot dedicate full time. That is why at EasyDataHost we include patch management within our managed services: we take care of scanning, prioritization based on real exploitation, patch application in coordinated windows and subsequent verification, on infrastructure in our own datacenter in Spain with ISO 27001 certification and ENS compliance.
Patch management is also one piece of a broader security strategy that combines hardening, segmentation, offsite backup and monitoring. No isolated control is enough; it is the coordinated sum that reduces real risk. If you want to delegate this process or audit the one you already have, talk to our team.
Frequently Asked Questions
Should I always patch the vulnerabilities with the highest CVSS score first?
Not necessarily. CVSS measures theoretical severity, not real urgency. You should prioritize first the vulnerabilities in CISA's KEV catalog (actively exploited) and those with a high EPSS, even if their CVSS is lower. A CVSS 7.5 that is being actively exploited is more urgent than a CVSS 9.8 with no known exploitation.
What is the difference between a zero-day and an n-day?
A zero-day is exploited before a patch is available. An n-day already has a published patch but the organization has not applied it yet. The vast majority of real breaches exploit n-days —known and unpatched CVEs—, not zero-days.
How often should you scan for vulnerabilities?
For internet-facing assets, continuous or at least weekly scanning, and always after any change or deployment. Scanning must rely on an up-to-date asset inventory: you cannot patch what you do not know you have.
Conclusion
Faced with tens of thousands of CVEs a year, the goal is not to patch everything —that is impossible— but to patch the right thing first, in a systematic and verifiable way:
- arrow_right CVSS measures theoretical severity, not urgency. Prioritize with EPSS (probability) and, above all, with CISA's KEV catalog: what is actively exploited goes first, no matter what.
- arrow_right The management cycle —discover, scan, prioritize, remediate and verify— is continuous. It all starts with a reliable inventory: you cannot patch what you do not know you have.
- arrow_right Most breaches use n-days, not zero-days: old CVEs with a patch available and unapplied. Process discipline neutralizes the most common attack vector.
- arrow_right Automate (WSUS, Ansible, patch management) but test in staging first, set SLAs by severity and meet demands such as NIS2. At EasyDataHost we include it in our managed services.