CVSS, EPSS and KEV: which vulnerability to fix first

A product of any size ships with known vulnerabilities in its components, and new ones are published every day. You cannot fix them all at once. Three public signals help decide what comes first, and they answer three different questions:

Signal	Question it answers	Who publishes it
CVSS	How bad would it be if exploited?	FIRST defines it; vendors and databases score each vulnerability
EPSS	How likely is it to be exploited in the next 30 days?	FIRST, recalculated every day
KEV	Is it being exploited right now?	The US CISA (Known Exploited Vulnerabilities catalogue); in Europe, the EU Vulnerability Database

Confusing them is the most common mistake in vulnerability management, and under the Cyber Resilience Act it has a cost: only one of them can start the reporting clock.

CVSS: severity

The Common Vulnerability Scoring System rates the technical severity of a vulnerability from 0 to 10, from metrics such as how it can be reached (network, adjacent, local, physical), how complex the attack is, which privileges and user interaction it needs, and the impact on confidentiality, integrity and availability.

Score	Rating
0.1 to 3.9	Low
4.0 to 6.9	Medium
7.0 to 8.9	High
9.0 to 10.0	Critical

CVSS 3.1 is still the version most databases publish. CVSS 4.0, released by FIRST in November 2023, refines the metrics (attack requirements, impact on subsequent systems, supplemental metrics such as automatable) and is gradually replacing it. Score a vector yourself with our CVSS 3.1 and CVSS 4.0 calculators.

What CVSS does not tell you: whether anyone will ever exploit it. Most vulnerabilities rated high or critical are never exploited in the wild. Sorting by CVSS alone means fixing many things that do not matter before the few that do.

EPSS: probability

The Exploit Prediction Scoring System, also from FIRST, estimates the probability that a vulnerability will be exploited in the wild in the next 30 days. It is a model trained on real exploitation activity and on what is known about each vulnerability (public exploit code, mentions, vendor, age), recalculated daily for every published CVE. Each score comes with a percentile: an EPSS of 0.40 might put a vulnerability above 98% of all others.

EPSS is good at the question CVSS cannot answer: among two high-severity vulnerabilities, which one is attackers’ focus. It is a forecast, not a fact, and it knows nothing about your product: a likely-exploited vulnerability in code your product never runs is still not your emergency. Look up today’s scores with our EPSS lookup.

KEV: proof of exploitation

The Known Exploited Vulnerabilities catalogue, kept by the US CISA since November 2021, lists vulnerabilities for which there is reliable evidence of exploitation in the wild, with a required remediation date for US federal agencies. It is short compared with the full CVE list, and every entry deserves attention.

In Europe, ENISA’s EU Vulnerability Database (EUVD), opened in 2025, also flags exploited vulnerabilities. Vendor advisories, national CERTs and your own incident evidence are further sources.

Which one starts the CRA clock

Since 11 September 2026, the Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities in their products: an early warning within 24 hours of becoming aware, a notification within 72 hours, a final report later.

The regulation defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. That is a KEV-type signal, not a CVSS or EPSS one:

a CVSS 9.8 vulnerability that nobody exploits does not start the clock;
a high EPSS score does not start the clock;
a medium-severity vulnerability listed in KEV, in a component your product uses in an affected way, can.

So watch exploitation lists every day, not only at release time. See the reporting clock.

A simple way to combine them

Exploited and affecting your product (KEV or EUVD, and the vulnerable code is reachable): act now. Assess within hours, fix or mitigate, and report under Article 14 if the product is affected.
High EPSS (for example in the top few percent) and reachable: next in line. Fix in days, not weeks.
High or critical CVSS, low EPSS: plan it in the normal release cycle, faster if the component faces the network.
The rest: batch with regular dependency updates.

At every level, check whether your product is actually affected before spending effort: is the component really shipped, is the vulnerable code present and reachable? Record the answer as a VEX statement, so you do not redo the analysis at the next release.

Frameworks such as SSVC (Stakeholder-Specific Vulnerability Categorization, from CERT/CC, with a CISA version) turn this kind of reasoning into a decision tree, if you want something more formal.

How Provetry helps

On paid plans, Provetry matches every component of your supported releases against new vulnerabilities, CISA KEV and the EUVD every day, shows exploited vulnerabilities first and EPSS next, alerts you as soon as one is exploited, and opens the reporting case with its clock and drafts when you confirm the product is affected.