# CVE, CVSS, EPSS, KEV explained for small vendors Canonical: https://craguard.eu/blog/cve-cvss-epss-kev-explained Language: en Last updated: 2026-09-02 - [CRAguard](https://craguard.eu/)/ - [Blog](https://craguard.eu/blog)/ - CVE, CVSS, EPSS, KEV explained for small vendors 19 Aug 2026 · CRAguard Summary A CVE is a vulnerability identifier, CVSS its severity (0–10), EPSS the probability of exploitation, and KEV is CISA's catalogue of actively exploited vulnerabilities. Together they answer two questions: how bad is it, and how likely is someone to use it. We show the exact thresholds we use to turn them into one human verdict — and why a KEV listing is a possible trigger for the 24-hour report under Article 14. When a new vulnerability appears, a small company doesn't need an academic lecture — it needs to know **what to do and by when**. Four acronyms serve that purpose. Each answers a different question, and together they produce a clear decision. Let's walk through them in plain language and show how we turn them into one verdict. ## CVE — which vulnerability it is **CVE** (Common Vulnerabilities and Exposures) is simply an **identifier**, for example `CVE-2026-1234`. It's a worldwide catalogue of publicly known vulnerabilities so that everyone refers to "the same hole" the same way. A CVE by itself says nothing about how serious it is or whether anyone is exploiting it — it's just a name. The details (CVSS, description, fixed versions) are attached to it from databases like NVD or OSV.dev. ## CVSS — how bad it is **CVSS** (Common Vulnerability Scoring System) is a **severity score from 0 to 10**. It expresses the impact exploitation would have: usually split into *Low*, *Medium* (≥ 4.0), *High* (≥ 7.0) and *Critical* (≥ 9.0). It answers "how bad would it be if someone used it" — but not whether anyone actually is. A high CVSS on a component whose vulnerable function you never call may in practice be a smaller problem than a medium CVSS right in your input path. Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## EPSS — how likely someone is to use it **EPSS** (Exploit Prediction Scoring System, from the FIRST organisation) is a **probability from 0 to 1** that a given vulnerability will be exploited in the near term. `0.02` means ~2%, `0.7` means ~70%. Where CVSS says *how bad*, EPSS says *how likely*. The combination of the two is more useful than either alone — high severity with high probability is a different league from high severity with near-zero probability. ## KEV — who is already exploiting it **KEV** (Known Exploited Vulnerabilities) is a public catalogue from the US agency CISA that lists vulnerabilities **actively exploited in the real world**. If a CVE is in KEV, it's not a theoretical risk — someone is genuinely using it for attacks. For the CRA this is pivotal: the reporting duty under **Article 14** attaches to an *actively exploited vulnerability*. A KEV listing that touches a component in your product is therefore a **possible trigger for the 24-hour report** — with the caveat that whether it is being exploited in *your* product is for you to assess. ## How we turn this into one verdict Four numbers are nice, but the decision must be one. So we fold them into three verdicts — **Fix now**, **Plan**, **Informational** — following a fixed order of rules (first match wins): - The vulnerability is in **KEV** → **Fix now** (actively exploited). - **CVSS ≥ 9.0** → **Fix now** (critical severity). - **CVSS ≥ 7.0 and EPSS ≥ 0.10** → **Fix now** (high severity and real probability). - **CVSS ≥ 7.0** → **Plan** (high severity, low probability). - **CVSS ≥ 4.0 or EPSS ≥ 0.01** → **Plan** (medium risk). - **CVSS unknown** → **Plan** (better to assess than to miss). - Otherwise → **Informational**. This order has logic: real-world exploitation (KEV) beats everything, critical severity stands on its own, and the combination of high severity with probability pulls a finding up even without KEV. Unknown CVSS deliberately falls to "Plan" — we don't want it dropping off the radar just because it has no score yet. ## A worked example on one vulnerability Imagine `CVE-2026-XXXX` appears in a library you use, with CVSS 8.1. How do you decide? - **Is it in KEV?** If yes → **Fix now**, end of debate, regardless of the other numbers. - **Not in KEV, CVSS 8.1.** It isn't ≥ 9.0, so rule 2 doesn't fire. We look at EPSS. - **EPSS 0.15** (15%). CVSS ≥ 7.0 and EPSS ≥ 0.10 → **Fix now** (rule 3). - **Were EPSS 0.03**, rule 3 wouldn't fire, but CVSS ≥ 7.0 → **Plan** (rule 4). So the same vulnerability ends up as "Fix now" or "Plan" depending on the probability of exploitation — and that's exactly the point: not every high CVSS is firefighting. And if the same CVE reached KEV a week later, the verdict automatically flips to "Fix now" and triggers the Article 14 reporting consideration. ## What to take away For a small company the practical conclusion is simple: **KEV and Fix now mean today**, the rest can go into a plan. And because new CVEs and new KEV listings arrive daily, this isn't a one-off check but a background process. How you actually report through ENISA's platform once a finding turns out to be "actively exploited" is covered in the [Article 14 step by step](https://craguard.eu/blog/article-14-step-by-step-enisa-platform) article. ## FAQ - **Is a high CVSS always "Fix now"?** No — CVSS ≥ 9.0 alone yes, but CVSS 7–9 depends on EPSS and KEV. That's why we combine several signals. - **Where do EPSS and KEV come from?** EPSS from the FIRST organisation, KEV from CISA's catalogue — both public, updated continuously. - **Does "no finding" mean secure?** No. Databases don't see 0-days or unknown holes; the absence of a finding is no guarantee. - **Why does unknown CVSS fall to "Plan"?** So a finding doesn't drop off the radar just because it has no score yet — better to assess it. ## Why one verdict instead of four numbers A small company doesn't have the capacity to read four metrics at every finding and decide anew. The point of a verdict is to make the decision **for you, and consistently**: the same rule, the same thresholds, every time. That also makes the audit trail credible — at an inspection you can show you didn't decide by mood but by a clear rule that puts KEV above everything and combines severity with probability. ## How CRAguard helps CRAguard compares your SBOM daily against OSV, KEV and EPSS, scores each finding with exactly this rule, and shows *why* it got its verdict in the detail view. "Fix now" reaches you by email immediately, the rest in a weekly digest — so you never catch the 24-hour Article 14 clock too late. [Find out whether the CRA applies to you](https://craguard.eu/checker), or [join the waitlist](https://craguard.eu/#waitlist). *This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Art. 14) and the public CVE/NVD, CVSS and EPSS (FIRST) and KEV (CISA) sources. A CRAguard verdict is input for assessment, not confirmation that you are vulnerable or compliant.* Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## Sources - [EUR-Lex — Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [ENISA — Single Reporting Platform](https://www.enisa.europa.eu/) --- Source: CRAguard — https://craguard.eu