How to Prioritise Vulnerabilities Using CVSS, EPSS and CISA KEV

Each time a new vulnerability is uncovered, security professionals must make another judgement. Is it something they need to fix right away, or can it wait until more pressing threats are addressed? Sounds simple enough until you have hundreds of vulnerabilities to examine, limited resources and several sources telling you how critical each one is. 

Vulnerability exploitation made up 31% of breaches in Verizon’s 2026 Data Breach Investigations Report. But only 26% of critical vulnerabilities listed in its remediation data were fully remediated in 2025. The pressure to prioritise is obvious. 

But the severity level of a vulnerability doesn’t necessarily tell you how likely it is to be exploited, how exposed your systems are or what an attack might cost your organisation. And that's where CVSS, EPSS and CISA KEV come in. Each one delivers a separate piece of information that security professionals can use to help them decide what needs attention first.

What CVSS, EPSS and CISA KEV Actually Tell You

You need to understand what these three sources are measuring before you can use them to prioritise vulnerabilities. While they are often used together, they answer different questions about a vulnerability.

CVSS measures vulnerability severity

The Common Vulnerability Scoring System (CVSS) specifies the technical severity of a vulnerability. Its Base score uses a 0 to 10 scale, with higher scores indicating more serious weaknesses. The CVSS Base score examines aspects including how an attacker might exploit the vulnerability, what conditions are necessary and the effect of the vulnerability on affected systems. 

But the Base score is not the complete framework. FIRST’s CVSS v4.0 specification also incorporates Threat and Environmental metrics, which let businesses consider changing exploitation conditions and their own environments. The problem arises when teams rely on the Base score alone to determine what to patch. 

A critical vulnerability may be difficult to exploit in one setting, while a lower-scoring weakness may put a crucial business system at risk.

EPSS estimates exploitation probability

The Exploit Prediction Scoring System (EPSS) uses a different approach. It predicts the likelihood that a publicly disclosed vulnerability will be exploited in the wild in the next 30 days, rather than measuring its technical severity. EPSS offers a probability score as well as a percentile ranking. They’re not the same thing. 

The probability score estimates the likelihood of exploitation, while the percentile indicates how that score compares with other vulnerabilities. An EPSS score can help teams identify vulnerabilities that are worth paying attention to, based on the latest threat intelligence. But it doesn’t know if your organisation is using the affected software or if an attacker can reach it.

CISA KEV identifies known exploitation

The Cybersecurity and Infrastructure Security Agency maintains a Known Exploited Vulnerabilities (KEV) catalogue of vulnerabilities with credible evidence of exploitation in the wild. Unlike EPSS, KEV is not predicting what could happen. It confirms that exploitation has already occurred. CISA urges organisations to prioritise these vulnerabilities. 

Its guidance on known exploited vulnerabilities also states that federal civilian executive branch agencies have specific remediation requirements under Binding Operational Directive 22-01. KEV gives other organisations compelling evidence of a real threat, but the appropriate response will still depend on whether their systems are affected.

Why Your Environment Changes the Priority

Suppose two organisations are operating the same vulnerable software. One has it on an internet-facing server that handles customer information. The other uses it within an internal system with limited access and additional security controls. The vulnerability has the same CVSS Base score in both environments. Its KEV status and EPSS score are likewise identical. 

But the organisations don’t necessarily face the same level of risk. The difference comes down to exposure, reachability and business impact. Exposure is about whether attackers can access the affected system. Reachability takes a step further and considers whether they can actually reach the vulnerable component and meet the conditions needed to exploit it. 

Existing controls, such as network restrictions or authentication requirements, can affect both. Then there's the possible damage. A vulnerability in a critical payment system may be worthy of greater attention than the same issue in an isolated test computer. Research released in October 2026 offers an illustration of this approach. 

The authors of CAPE, a context-aware vulnerability prioritisation framework, analysed 6,138 scanner-reported CVEs across 30 open-source agentic applications. They observed that including deployment-specific reachability and exploitability evidence led to different priorities compared to approaches relying on CVSS, EPSS and KEV alone. 

The findings are limited to the applications tested, but they show why it is not enough to know that a vulnerability exists. Security teams also need to know the conditions under which it could be exploited.

How to Prioritise Vulnerabilities in Practice

So how do you take all this information and decide what to address first? A practical vulnerability prioritisation approach begins with confirming which vulnerabilities affect your organisation, then combines exploitation intelligence, local exposure and business consequences. There are five steps that are worth following.

1. Confirm which assets are affected.

Begin by checking the vulnerability against your asset inventory. Confirm the affected product, software version and configuration, then identify which systems may be at risk. Not every scanner finding represents an exploitable vulnerability. 

Some of the results might need further investigation, particularly if the component involved is not enabled or the configuration needed is not in place. You also have to know who owns the system. A vulnerability that is correctly prioritised can go unresolved if there is no accountable owner.

2. Review the available vulnerability intelligence.

Check the CVSS assessment, the current EPSS probability and whether the vulnerability is included in CISA KEV. Vendor advisories and credible exploitation reports may provide additional information. Especially watch for signs of recent exploitation. A vulnerability being exploited in the wild may demand a faster response than its severity rating would suggest. 

However, don’t attempt to build a risk score merely by multiplying CVSS and EPSS. FIRST’s official guidance on using EPSS warns against this because the two systems measure different things. Their product does not generate a meaningful combined risk score.

3. Establish how exposed the system is.

Then, assess whether an attacker could realistically exploit the vulnerability in your environment.

• Can the service be accessed from the internet?
• Does exploitation require authentication or a particular configuration?
• Are there network restrictions or other controls that limit exposure?

If the answer is not obvious, then the most pressing action may be further investigation. Don't treat unknown exposure as proof that the system is safe.

4. Consider the business consequences.

Look beyond the technical implications listed in the vulnerability advisory.

• Could exploitation disrupt a critical service, reveal sensitive information or give an attacker access to other important systems?
• How difficult would recovery be?

The same vulnerability may justify different remediation timeframes, depending on the affected asset and the consequences of a successful attack.

5. Decide what action to take.

Assess the evidence and choose an appropriate response. That can mean an urgent patch, temporary controls, isolating an affected system or investigating further before making a final decision. In certain cases, a documented deferral may be appropriate. But it should have a clear rationale, an accountable owner and a review date. 

The goal is not to patch all vulnerabilities at once. It is to direct remediation efforts towards the areas of greatest concern to your organisation.

What Happens When CVSS, EPSS and KEV Disagree?

One of the more confusing aspects of vulnerability management is what to do when different sources seem to be giving conflicting signals. You can have a critical CVSS score but a low EPSS probability. Or a moderate-severity vulnerability can have a high estimated likelihood of exploitation. Neither situation necessarily means one source is wrong. 

Often, they reflect the different questions that each source is supposed to answer. Let’s discuss three common scenarios.

High CVSS, low EPSS and no KEV listing

The vulnerability has a critical severity rating, but a relatively low likelihood of exploitation as indicated by EPSS. It has also not been added to CISA KEV. It should not be automatically pushed to the bottom of your remediation queue. If the affected system is internet-facing, supports a critical service or holds sensitive information, the possible consequences may still warrant prompt action. 

A low EPSS score does not mean that exploitation will not occur. But if the vulnerable component is not reachable and safeguards are in place, then the team may have good reason to assign a different remediation timeframe, provided those assumptions are verified.

Moderate CVSS and high EPSS

Consider a vulnerability that is assessed as being of moderate severity, but with a high estimated probability of exploitation. It is tempting to prioritise fixing the critical vulnerabilities when patching resources are limited. But that could leave an exposed system open to an attack that's more likely to occur. 

The sensible thing to do is to look at the affected assets, check for relevant exploitation evidence and determine whether the vulnerability could be exploited in your environment. If it can, remediation may need to take priority over some higher-severity findings.

KEV-listed vulnerability with low EPSS

This combination may seem contradictory at first. So how can a vulnerability have confirmed exploitation but a low estimated probability of being exploited? This is because KEV records evidence of past exploitation, while EPSS estimates the probability of exploitation over the next 30 days. FIRST recommends prioritising KEV-listed vulnerabilities regardless of their EPSS score. 

Recent confirmed exploitation is especially important, even if the predicted probability is low. For an affected organisation, the first job is to establish exposure, check the applicable remediation requirements and decide how quickly the vulnerability needs to be addressed. And there's one more distinction across all three scenarios that you should remember. 

An urgent investigation doesn’t necessarily mean an immediate patch deployment. Teams may first need to confirm exposure, assess the operational consequences or introduce temporary controls while preparing a safe fix.

How to Make Remediation Decisions Defensible

Prioritising vulnerabilities is just one part of the work. Security teams must also justify why they chose one response over another, especially if a critical vulnerability is left unpatched. A defensible remediation decision should be supported by the evidence available at the time. 

This includes the vulnerability intelligence considered, affected assets, exposure assessment, business impact and any existing controls. It should also say who owns the decision, what action has been agreed and when it needs to be completed. If remediation is deferred, the organisation should have a defined exception process. 

This involves documenting the reason for the delay, who has accepted the remaining risk and when the decision will be reviewed again. And such reviews can't be based on a calendar alone. Vulnerability intelligence changes. An exploit could be released. A vulnerability could be added to KEV. A previously restricted system could become exposed.

VulnCheck’s exploitation study identified 495 vulnerabilities with evidence of exploitation in the first half of 2026. Of these, 23.43% were observed being exploited on or before their CVE publication dates. These findings come from VulnCheck’s own exploitation intelligence dataset, which is separate from CISA KEV. 

They show why teams can’t assume that their initial assessment will remain accurate. A good vulnerability management policy should therefore specify what triggers reassessment, not just how quickly vulnerabilities must be addressed.

Final Thoughts: Better Vulnerability Prioritisation Starts With Better Decisions

With security teams facing a growing list of vulnerabilities, it makes sense that they'd want a straightforward way to prioritise. CVSS, EPSS and CISA KEV are all useful, but none can make that decision alone. Severity, exploitation probability and confirmed exploitation provide useful evidence. 

The final priority will depend on how those findings relate to the organisation’s systems, exposure and business risks. Effective risk-based vulnerability prioritisation is not about finding the perfect score. It’s about consistent decision-making, based on evidence and open to review when circumstances change. 

A useful place to start is with your existing remediation queue. Can your team explain why one vulnerability is being addressed before another, particularly when their severity and exploitation signals disagree? If the answer isn't clear, it may be time to rethink how those decisions are made. 

It's a conversation worth continuing as organisations rethink how they approach vulnerability management and cyber risk, and one we're following closely at EM360Tech.