What to patch first: CISA KEV, EPSS and CVSS

Many published vulnerabilities are never used in an attack, while some with modest scores are used constantly. A severity score on its own cannot tell the two apart. The way to spend limited patching time well is to ask three separate questions about each vulnerability, and each has a public source that answers it.

Three signals, three questions.

CVSS, the Common Vulnerability Scoring System, rates technical severity: how the vulnerability is reached, how hard it is to exploit and what an attacker gains. Scores map to ratings: Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0). The base score describes the vulnerability, not your exposure to it. The CVSS specification itself asks users to add threat and environmental information before using it to assess risk.

EPSS, the Exploit Prediction Scoring System, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It is a model trained on observed exploitation, recalculated every day, so a score can rise sharply when an exploit is published. The percentile shows how a score ranks against every other scored CVE.

The CISA KEV catalog lists vulnerabilities with reliable evidence of exploitation in the wild. To be added, a vulnerability needs a CVE identifier, that evidence, and a clear fix, such as a vendor update. US federal agencies must fix listed vulnerabilities within set deadlines, and CISA recommends that every organisation use the catalog to prioritise.

A simple order of work.

1. Anything in KEV on a system reachable from the internet. Fix it now. If the product cannot be updated, for example because it is end-of-life, take it off the network or replace it: that is CISA's own instruction to US agencies.
2. A high EPSS score on an internet-facing system. There is no official cut-off; TrustSek treats 0.5 and above as high. Check the percentile too, and look again in a few days, because scores move.
3. Critical and High CVSS scores on internet-facing systems, then the same on internal systems.
4. Everything else in your normal patch cycle, rechecked against KEV and EPSS as they change.

Exposure matters as much as the score. A KEV entry on a server reachable from the internet is far more urgent than the same entry on an isolated test machine. Keep an inventory of what you expose, or the order above has nothing to work on.

Why CVSS alone sends teams in the wrong direction.

CVSS scores rarely change after publication, and many vulnerabilities score High or Critical. Patching by CVSS alone means treating a long list as equally urgent, while a Medium vulnerability that attackers actually use can wait in the queue. EPSS and KEV add what CVSS leaves out: whether anyone is trying. Use all three, in the order above.

Where to look a vulnerability up.

• CISA KEV: the catalog is searchable, and downloadable as CSV and JSON for automatic matching.
• EPSS: FIRST publishes the scores for every CVE daily, with a free API.
• CVSS: the NIST National Vulnerability Database, or the vendor's own advisory.
• ENISA's European Vulnerability Database (EUVD): launched in May 2025 under NIS2, with a separate view of exploited vulnerabilities.

What NIS2 expects.

Article 21(2)(e) of the NIS2 Directive requires essential and important entities to take measures for security in the acquisition, development and maintenance of their systems, "including vulnerability handling and disclosure". In Sweden the directive is implemented by the Cybersecurity Act. A written rule for what you fix first, and how fast, built on KEV and EPSS, is concrete evidence that vulnerabilities are handled on purpose rather than as they come. See who NIS2 covers in Sweden and what outside-in evidence covers under NIS2.

What can be seen from the outside.

Public web servers and pages often state which software and version they run. Matching those versions against published vulnerabilities shows what an attacker can see without touching anything. It has limits: a fix that a Linux distribution backports without changing the version number looks unpatched from outside, and software that hides its version cannot be matched at all.

What TrustSek checks.

The vulnerabilities module matches the server software and JavaScript libraries your site advertises against the CISA KEV catalog, EPSS, the NVD, OSV and Retire.js, and reports them in the order this guide recommends:

Matches on version alone carry lower confidence, and lower still for Apache, nginx and PHP, which distributions often patch without changing the version. Detection is passive and version-based: the scan reads what the site serves and does not test or exploit anything.

Questions

Is a vulnerability with a low EPSS score safe to ignore?

No. It is less urgent today, but EPSS is recalculated daily and can jump when an exploit is published. Patch it in your normal cycle and keep checking.

What if a KEV vulnerability has no fix for our version?

KEV only lists vulnerabilities that have a clear remediation, so a fix exists, though perhaps only in a newer version. If you cannot move to it, isolate or retire the system. CISA requires exactly that of US agencies for products that cannot be updated.

Does hiding version numbers make us safer?

A little. It removes a free step for attackers and lowers the number of version matches anyone can make from outside, but the vulnerable software is still there. Hide versions, and patch anyway.

See what your site reveals

The free check matches the software your site advertises against known-exploited and published vulnerabilities, alongside the five other modules.

Your domain

Check your domain

Free, no sign-up. Takes about 30 seconds.