The average enterprise runs tens of thousands of open vulnerabilities at any given time. CVSS scoring assigns a numerical severity to each. A strict CVSS-first programme tells your team to patch several thousand critical- and high-severity items before moving to medium — a queue that, in practice, is never cleared, and does not correspond to the actual risk profile of your environment.
This is not a failure of CVSS. It is a failure of using a severity metric as a proxy for risk. In 2026, two additional data sources — EPSS and CISA’s KEV catalogue — have matured to the point where a combined prioritization approach is the expected standard for security programmes operating at scale. This briefing explains what each source tells you, what it does not, and how to build a prioritization framework from all three.
What CVSS Actually Measures
The Common Vulnerability Scoring System scores the intrinsic properties of a vulnerability in isolation: attack vector, complexity, privileges required, user interaction, and impact on confidentiality, integrity, and availability. The current version, CVSS 4.0, also introduces threat metrics that can incorporate exploitation evidence into the calculation.
CVSS was designed to allow consistent comparison of vulnerabilities at the moment of disclosure. It is a severity measure, not a risk measure. A CVSS 9.8 vulnerability on a system that is network-isolated, not exposed to untrusted input, and not targeted by any known threat actor carries lower practical risk than a CVSS 6.5 vulnerability on your external-facing login portal being actively exploited by ransomware affiliates.
The NVD publishes CVSSv3.1 and CVSSv4.0 base scores for the majority of published CVEs. In a given month, NIST publishes several thousand CVEs. Hundreds will have CVSS scores of 9.0 or higher. No patching programme can treat all of them as equal priority.
EPSS: Exploitation Likelihood as a Data Signal
The Exploit Prediction Scoring System (EPSS), maintained by FIRST (the Forum of Incident Response and Security Teams), takes a machine learning approach to the prioritization problem. It produces a probability score between 0 and 1 representing the likelihood that a CVE will be exploited in the wild within the next 30 days.
EPSS is trained on:
- Active exploitation reports from a broad set of threat intelligence sources
- Historical exploitation patterns
- CVE metadata: affected products, vulnerability type, patch availability, public exploit code availability
The practical output: EPSS identifies the 2–5% of vulnerabilities that are actually exploited in the wild and concentrates remediation effort there. Research from FIRST and independent validation consistently shows that patching the top 10% of CVEs by EPSS score addresses the overwhelming majority of observed exploitation events.
What EPSS does well: It surfaces vulnerabilities that are being actively targeted or are likely to be, independent of their CVSS score. A medium-severity CVE in widely-deployed commodity software that has a public exploit and is being integrated into attacker toolkits will score high on EPSS.
What EPSS does not do: It does not account for your environment. A high-EPSS vulnerability in software you do not run is irrelevant to your risk profile. EPSS is a global signal, not an asset-specific one. Contextualisation against your asset inventory is still required.
EPSS scores are updated daily and publicly available from the FIRST API: https://api.first.org/data/1.0/epss?cve=CVE-XXXX-XXXXX
CISA KEV: Confirmed Exploitation in the Wild
The CISA Known Exploited Vulnerabilities catalogue is the most actionable of the three signals. A CVE appears on the KEV catalogue only when CISA has confirmed that exploitation is occurring in the wild against real targets. This is not a probability estimate — it is an evidence-based statement.
CISA maintains the KEV catalogue under BOD 22-01 (Binding Operational Directive), which mandates that federal civilian agencies patch KEV vulnerabilities within defined timescales (typically 14 days for critical, 25 days for non-critical). CISA strongly recommends that private sector organisations treat KEV entries with equivalent urgency.
In 2025 and into 2026, the KEV catalogue has grown to include over 1,200 entries. New additions arrive frequently — CISA typically adds vulnerabilities within days to weeks of confirmed exploitation, though the timeline varies.
KEV characteristics: High precision, lower recall. A CVE on the KEV catalogue is definitely being exploited; a CVE not on the catalogue may be actively exploited but not yet confirmed by CISA. The catalogue skews toward vulnerabilities in internet-facing and commonly-deployed products (network devices, VPN appliances, enterprise software) because those are the systems where exploitation is most visible to threat intelligence.
Building a Combined Prioritization Framework
The three signals complement each other because they are answering different questions:
| Signal | Question Answered | Update Frequency |
|---|---|---|
| CVSS | How severe is this vulnerability in isolation? | Static (per CVE) |
| EPSS | How likely is this to be exploited in the next 30 days? | Daily |
| CISA KEV | Is this confirmed to be actively exploited right now? | As CISA confirms exploitation |
A practical prioritization tier structure:
Tier 1 — Patch within 24–72 hours:
- CVE appears on CISA KEV and affects an asset in your inventory
- Supplement with: your threat intelligence platform confirms active exploitation targeting your sector
Tier 2 — Patch within standard patch cycle but treat as first priority within that cycle:
- CVE is not on KEV but has EPSS ≥ 0.50 (high predicted exploitation likelihood) and affects an exposed or high-value asset
- CVE has CVSS ≥ 9.0 and EPSS ≥ 0.10 (high severity plus meaningful exploitation signal)
Tier 3 — Standard patch cycle:
- CVSS ≥ 9.0 but EPSS < 0.10 and not on KEV
- High-impact vulnerability but minimal exploitation signal
Tier 4 — Schedule based on asset risk and available resources:
- CVSS < 9.0, not on KEV, EPSS < 0.10
Deferred or risk-accepted:
- Vulnerability affects software not in your inventory
- Vulnerability requires local access or high privileges to exploit, and the affected system is not reachable by the exploit prerequisites given your architecture
Environment Context: Where the Three Signals Are Not Enough
CVSS, EPSS, and KEV are all signals about the vulnerability, not about your environment. A complete prioritization framework adds two more dimensions:
Asset criticality: A Tier 3 vulnerability on your internet-facing customer authentication system may warrant Tier 1 treatment. A Tier 1 vulnerability on a developer workstation that cannot reach production systems warrants a different urgency.
Exploit preconditions vs your configuration: CVSS assumes worst-case. A vulnerability requiring no authentication over the network (AV:N/AC:L/PR:N/UI:N) at CVSS 9.8 is only that severity if the affected service is network-accessible. If you have the service behind a firewall with no public access, the exploitability drops significantly. Model exploit preconditions against your actual network segmentation and configuration.
Attack path context — what can an attacker do after exploiting this vulnerability given your architecture? — is the analysis that exposure management platforms (Wiz, Tenable One, Qualys TotalCloud) attempt to automate. For environments without dedicated EASM or ASPM tooling, this analysis is manual and limited to the most critical assets.
Operationalising the Framework
Data integration: Ingest EPSS scores and the KEV catalogue into your vulnerability management platform. Most major platforms (Tenable, Qualys, Rapid7, Defender Vulnerability Management) have native integration with the KEV catalogue and EPSS API. If yours does not, a daily pull from https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json and the EPSS API feeds into a custom dashboard.
SLA definition: Define patch SLAs for each tier that are realistic for your team. An organisation that says “Tier 1 within 24 hours” but consistently takes 14 days is measuring performance against a metric that does not drive behaviour. Start with achievable SLAs and tighten them.
Board and executive reporting: Translate the framework into business language. “We patched 97% of KEV vulnerabilities within our 72-hour SLA this quarter” is a more meaningful security metric than “we have 12,000 open vulnerabilities.” Vulnerability count without prioritisation context is noise; SLA compliance against the highest-risk population is a signal.
Exception process: High-EPSS or KEV vulnerabilities in third-party systems outside your direct control (SaaS providers, supply chain partners) need an exception and risk acceptance process. Identify these explicitly rather than allowing them to age in the queue unaddressed.
What Changes in 2026
The growth in AI-assisted vulnerability research has accelerated the time from CVE publication to working exploit. In 2024 and 2025, multiple researchers demonstrated LLM-assisted exploit development that reduced the proof-of-concept timeline from days to hours for certain vulnerability classes. This compresses the window between a CVE appearing in the NVD and it appearing in attacker toolkits.
The implication for prioritization: for high-CVSS vulnerabilities in widely-deployed software, especially memory corruption and authentication bypass classes, the assumption that you have weeks before exploitation begins is no longer reliable. The KEV catalogue and EPSS scores are updated frequently enough to reflect the accelerating exploitation cadence, but CISO-level awareness that the window between disclosure and active exploitation has shortened is the most important framing shift for 2026.