Blog

CTEM prioritisation without CVSS: using KEV, EPSS and business context

By Dan Swihart · Published 29 September 2026

Most remediation queues are sorted by one column: the CVSS base score. It is easy to sort and every scanner produces it, but it is not what the score was built for. The result is a queue with a theoretical worst case at the top and a flaw that attackers are using today somewhere in the middle.

Prioritisation is the third stage of the CTEM cycle, and it is where that queue gets rebuilt. Three inputs change the order: whether a flaw is being exploited, how likely exploitation is, and what it would reach in your environment.

Why CVSS base score alone misranks

CVSS measures how severe a vulnerability is in general. It does not measure how likely anyone is to exploit it, or what it would cost you if they did. FIRST, which maintains the standard, says so directly. Ranking by base score means answering a question the score was never designed to answer.

FIRST’s user guide states that Base scores “are designed to measure the severity of a vulnerability and should not be used alone to assess risk”. It adds that the Base Score should be supplemented with an analysis of the environment and with attributes that change over time: the Environmental and Threat metric groups.

A base score is fixed at publication. It cannot know that an exploit was released last week, or that the host has no route from the internet.

The effect is that a high score on an unreachable system gets the same priority as a moderate one on the VPN gateway. CVSS still describes what a flaw could do. It is one input, not the ranking.

What KEV is and how to use it

The CISA Known Exploited Vulnerabilities catalogue (KEV) lists CVEs with reliable evidence of exploitation in the wild. If a flaw is on it, someone has already used it against a real target. That makes it the strongest free signal available, and the simplest to apply.

CISA describes KEV as the authoritative source of vulnerabilities that have been exploited in the wild, and says organisations should use it as an input to their prioritisation framework. Its BOD 22-01 page sets three conditions for inclusion: a CVE ID, reliable evidence of active exploitation, and a clear remediation action such as a vendor update. The due dates bind US federal civilian agencies. CISA strongly encourages everyone else to prioritise the same fixes.

How to use it:

1. Match KEV against your inventory daily. A new entry that matches something you run is a same-day event.
2. Treat a match on an exposed asset as the top tier. Do not wait for a severity score to agree.
3. Remember its limits. An unlisted flaw may still be exploited, and a listed flaw on an unreachable host ranks below one on the perimeter.

Speed matters. In Verizon’s 2025 Data Breach Investigations Report, exploitation of vulnerabilities was the initial access vector in 20 percent of breaches. The median gap between a CVE’s publication and its appearance on KEV was five days, which Verizon uses as a proxy for time to mass exploitation. Full remediation was not routine: 38 percent for KEV vulnerabilities, and 9 percent for all vulnerabilities identified in scans (Verizon, 2025 DBIR).

What EPSS estimates, and how to use a threshold

EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days, as a number between 0 and 1. It forecasts across the whole vulnerability population. It does not know your network, assets or controls, so it ranks likelihood, not risk.

FIRST describes EPSS as a data-driven machine-learning model, with scores published daily for every CVE. Its FAQ is direct about the limits: EPSS supplies the threat likelihood component of risk only, it does not estimate impact, and a low score does not mean a system is safe.

KEV records exploitation that has been confirmed. EPSS forecasts exploitation not yet seen. FIRST’s guidance on using EPSS says that when a vulnerability is on KEV you treat it as actively exploited, whatever its EPSS score. EPSS earns its place on everything KEV does not cover.

Choosing a threshold

FIRST says there is no universal threshold: the right one depends on your remediation capacity, risk tolerance and asset context. It notes that 0.10 is commonly cited but carries no special authority.

The trade-off, in FIRST’s words, is that “a lower threshold catches more of what eventually gets exploited, at the increased cost of remediating more vulnerabilities”. A higher threshold gives a shorter list and misses more of what matters.

A starting point, and only that:

• Work out how many fixes your teams can close per month.
• Count how many reachable findings each candidate threshold would queue.
• Choose the lowest threshold whose queue you can clear, then review it each quarter against what you missed.

Reachability and asset criticality

Reachability asks whether an attacker can get to the vulnerable component from a position they could plausibly hold. Asset criticality asks what the business loses if it is compromised. Neither is a property of the CVE. Both come from your own scoping and discovery, and they move the order more than any public score.

FIRST’s guidance on localising EPSS lists the same checks: presence, reachability and consequence.

Scoping supplies criticality. If it produced a ranked list of business processes and the systems on the path to them, criticality is a lookup rather than an argument. Without it, every asset becomes “high”.

Attack path analysis is the best source for reachability. Short of that, four questions per finding go a long way:

• Is it exposed to the internet, a partner network or only an internal segment?
• Does exploitation need authentication, and could an attacker plausibly have it?
• Does a control, such as segmentation or a firewall rule, block the known exploit route?
• Does the host connect to something on the critical-process list?

Record the answers next to the finding.

A worked ranking

The five findings below are illustrative. They are invented to show the mechanics, and none is a real CVE or organisation. The rule: exploited and reachable first, ordered by asset criticality; then reachable, with a meaningful EPSS score, on a critical asset; then the rest by reachability and score.

Sorted by CVSS alone the order is A, E, C, D, B. The VPN gateway comes last, and the top two are the least likely to matter.

Applying the rule:

1. B. On KEV, internet-reachable, critical. Fix today, or apply a compensating control if the patch needs a window.
2. D. On KEV and reachable, but low value. The cheapest fix is to decommission the site.
3. C. Not on KEV, but reachable, with a meaningful EPSS score on a critical asset. Validate it: test whether the injection works against the real application.
4. E. Needs local login, low value. Scheduled patching.
5. A. No route, low value. Next routine window, or delete the VM.

The order moved because context was added, not because a formula ran. A ranking you can explain in a sentence per row survives a challenge from an asset owner.

How this maps to the prioritisation stage

Prioritisation sits between discovery and validation. Discovery supplies findings and scoping supplies criticality. Prioritisation ranks them on exploitation evidence and reachability, then hands a short list to validation. The output is the ten or so items worth proving, not a re-sorted backlog.

Gartner describes CTEM as a continuous programme rather than a one-off assessment. The ranking shows that most clearly: KEV entries, EPSS scores and your environment all change, so it is rebuilt each cycle.

Two habits keep it honest. Store the KEV flag, EPSS value, reachability answer and criticality per item, with the date, so a disputed ranking can be explained. And feed the top into validation: a ranking is still an opinion, and testing turns items into proven paths or documented downgrades.

CTEM vs vulnerability management covers how this differs from scanner-driven ranking.

What to ask vendors

Ask which inputs the ranking uses, whether you can see and change the weights, and whether it shows its reasons per finding. A proprietary score with no reasons is a number you cannot audit. You want an answer that names KEV, an exploit-likelihood source, reachability and asset context.

• Which exploitation feeds does the ranking use, and is KEV matched daily?
• Is EPSS shown as its own field, or folded into a proprietary score?
• Is reachability computed from your environment, or assumed from the CVE’s attack vector?
• Where does criticality come from: a scoping model you control, or a default tag?
• Can I export the ranking with the inputs behind each row?

The vendor directory records what each product claims for prioritisation, and the evaluation checklist covers all five stages. For two platforms that both market prioritisation, see Wiz vs Tenable One.

FAQ

Should we stop using CVSS?

No. Keep it as one input and stop using it alone. FIRST says Base scores should not be used alone to assess risk. Use severity to describe potential impact, then let exploitation evidence, reachability and asset criticality set the order.

What EPSS threshold should we use?

FIRST says there is no universal threshold. Pick the lowest one whose reachable queue your teams can clear, and review it quarterly. A lower threshold catches more eventual exploitation at the cost of more fixes.

If something is on KEV but not reachable, do we ignore it?

No, but it drops in urgency. KEV tells you exploitation is real, not that it applies to you. Confirm the reachability answer, note any compensating control and schedule the fix. If the asset becomes reachable, the item moves to the top.

Next

Build the ranking on one scope before you buy anything. A spreadsheet with the KEV flag, EPSS value, reachability and criticality is enough for a first cycle.

• Take the two-minute quick check to see whether prioritisation is your weakest stage.
• Use the assessment to score all five stages.
• Read the only CTEM metrics leadership will read to see how to report what the ranking produced.