Back to knowledge base

Not every vulnerability is equally urgent: EPSS and KEV explained for decision-makers

Published on July 11, 2026 · Updated on July 22, 2026

The scan report has arrived and the counter reads forty findings. The person responsible for IT asks for time and budget, the board wants to know how bad it is, and somewhere the question nobody wants to ask out loud is hanging in the air: do we really have to fix all of this, and if so, in what order?

That is not a sign of unwillingness, it is the right question. Not every vulnerability is equally urgent, and the organisation that treats everything as equally urgent ends up doing the wrong things first. This article explains the two instruments that let you prioritise by actual risk: EPSS and KEV.

The problem with "how bad is it?": severity is not likelihood

Most reports order findings by a CVSS score: a number from 0 to 10 expressing how severe the consequences of a vulnerability could be. Useful, but it measures only half of the risk. CVSS tells you how hard the blow lands if things go wrong, not how likely it is that they will.

And that likelihood varies enormously. Of all published vulnerabilities, only a small fraction is ever actually exploited: research by FIRST and the Cyentia Institute puts the figure at around 6 percent. The rest exists mainly on paper: a risk in theory, but no attacker investing time in it. Steering purely on CVSS therefore spends scarce IT hours on theoretical risks while the vulnerability being scanned for today sits in the queue.

For the decision-maker this is the core insight: risk is severity times likelihood, and for that second factor two mature, public sources now exist.

EPSS: the probability that things go wrong

EPSS, the Exploit Prediction Scoring System by the international security organisation FIRST, gives for each vulnerability the estimated probability that it will actually be exploited within the next 30 days. The model is updated daily based on observed attack data from the real world.

The output is a percentage, and the distribution is heavily skewed: as the EPSS documentation by FIRST shows, the vast majority of vulnerabilities score low, while a small group scores high. That small group is where your attention should go. A vulnerability with an average CVSS score but a high EPSS score is, in practice, more dangerous than a "critical" finding no attacker cares about.

KEV: no longer probability, but certainty

The Known Exploited Vulnerabilities catalogue (KEV) by the US cyber agency CISA is even more direct: a public list of vulnerabilities with confirmed active exploitation. Not a prediction, but an observation. US federal agencies are required to remediate KEV vulnerabilities within a set deadline, and the catalogue is also widely used outside the US as a practical prioritisation source.

For your organisation the translation is simple: if a finding from your scan report appears in the KEV catalogue, the discussion about priority is over. This vulnerability has confirmed exploitation in the wild, so remediation belongs at the top, within days to at most two weeks.

The three-tier approach in practice

Together, the two sources produce a prioritisation that can be explained to the board and the auditor alike:

Two caveats keep this honest. First: probability scores apply per vulnerability, not per organisation. A low EPSS score on the system holding your crown jewels may still weigh heavier than the table suggests; context remains human work. The EPSS score is moreover a global average: a low score on a service that the scan demonstrably shows to be internet-facing deserves more attention than that global figure suggests on its own. Second: prioritising is not the same as crossing out. The planned category must demonstrably be worked through as well, just not in a panic.

What this means for the boardroom

NIS2 and the Dutch Cybersecurity Act require appropriate and proportionate measures. Risk-driven prioritisation is the definition of proportionate: you can explain why finding A was fixed within 48 hours while finding B sits in the regular process. That story is more convincing to a regulator or auditor than "we fix everything", which in practice is almost never true.

Concretely, this gives you three questions for the next meeting with your IT team or provider:

1. Are any findings from our latest scan in the KEV catalogue, and if so, have they been fixed?
2. Which remediation windows do we apply per priority class, and are they documented?
3. Can we demonstrate, per finding, when it was found and when it was resolved?

If you get those three questions answered, you need no deeper technical understanding to steer. How to turn that steering into a board-level report is described in from CVE list to board report, and for the security lead in from vulnerability list to board-level evidence.

Conclusion

Forty findings are not forty emergencies. EPSS and KEV turn an unsorted list into a tiered backlog: confirmed exploitation first, likely exploitation next, the rest as planned work. That is not only more effective, it is exactly the proportionate, explainable approach the duty of care asks of you.

Exposentry reports apply this weighting as standard: every CVE finding is enriched with its current EPSS score and KEV status, so the report itself already tells you what comes first, in plain language. OpenKAT supplies the CVSS severity per finding; Exposentry adds the EPSS and KEV prioritisation layer. We know that foundation from the inside: Exposentry founder Edward Hasekamp contributes to the OpenKAT project itself. Part of continuous vulnerability monitoring, built on OpenKAT. See the plans and pricing or start with a baseline scan.

Written by Edward Hasekamp, founder of Exposentry and collaborator on the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.