What is the KEV catalogue?

KEV stands for Known Exploited Vulnerabilities, a public catalogue by the US cyber agency CISA listing vulnerabilities with confirmed active exploitation. If a vulnerability is in the KEV, exploitation is no longer a probability but an established fact, and remediation belongs at the top of the list.

Why is a CVSS score alone not enough to prioritise?

CVSS measures how severe the consequences of a vulnerability could be, not how likely exploitation is. Only a small fraction of all published vulnerabilities is ever actually exploited. Steering on CVSS alone treats a theoretical risk with the same urgency as a vulnerability attackers are actively scanning for today.

How do I use EPSS and KEV together in practice?

As a simple ordering: vulnerabilities in the KEV catalogue are fixed with priority, typically within days. Vulnerabilities with a high EPSS score follow immediately after. The rest is handled in the regular patching process, weighted by severity and the importance of the affected system.

What does this mean for me as a director or board member?

That you can ask better questions than "have all vulnerabilities been fixed?". Ask your IT team or provider: are any findings in the KEV catalogue, what is our remediation deadline for actively exploited vulnerabilities, and can we demonstrate that deadline? That is risk-driven management an auditor can work with.

Back to knowledge base

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

Q: What is EPSS?

EPSS stands for Exploit Prediction Scoring System, a public scoring model by FIRST. For each vulnerability it gives the estimated probability that it will actually be exploited within the next 30 days, updated daily based on observed attack data. A high EPSS score means: this is not theoretical, this is being hunted.

Published on July 11, 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, in the order of a few percent, is ever actually exploited. 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 differences are large: the vast majority of vulnerabilities score well below one percent, a small group scores tens of percent. 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 that norm is being adopted worldwide as a reasonable standard.

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. Attackers are using this vulnerability today, so remediation belongs at the top, measured in days rather than months.

The three-tier approach in practice

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

Priority	Criterion	Reasonable remediation window
Now	Finding is in the KEV catalogue: exploitation confirmed	Within days
This week	High EPSS score: high probability of short-term exploitation	Within 1 to 2 weeks
Planned	Remaining findings, weighted by severity and system importance	Regular patching process, within 30 to 90 days

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. 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:

Are any findings from our latest scan in the KEV catalogue, and if so, have they been fixed?
Which remediation windows do we apply per priority class, and are they documented?
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 finding is enriched with its current EPSS score and KEV status, so the report itself already tells you what comes first, in plain language. 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 core maintainer of 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.