Vulnerability Prioritisation Guide: CVSS, EPSS, KEV and Risk-Based Patching

Most organisations have far more open vulnerabilities than they can fix, and sorting the queue by CVSS base score sends effort to the wrong places. A base score describes how bad a flaw could be in a generic environment; it says nothing about whether anyone is exploiting it, whether the vulnerable asset is reachable, or what the asset does for the business. This guide explains how to combine the four public signals that matter (CVSS v4.0, EPSS, the CISA Known Exploited Vulnerabilities catalogue and SSVC) with your own asset and exposure context to build a prioritisation matrix that people can apply consistently. It is written for vulnerability management leads, security engineers and the IT owners who receive the tickets. Programme design, scanning and remediation workflow are covered in the Vulnerability Management Guide; here the focus is the decision of what to fix first.

Key takeaways

• Severity is not priority. FIRST says Base metrics should be enriched with Threat and Environmental values, and that EPSS "should never be treated as a risk score". Priority comes from combining exploitation evidence, exploit likelihood, exposure and business impact.
• KEV entries jump the queue. A CVE in the CISA catalogue has reliable evidence of exploitation; FIRST's own EPSS FAQ says to follow KEV even when the EPSS score is low.
• Use EPSS probability, not percentile, for thresholds. The probability is an absolute estimate of exploitation activity in the next 30 days; the percentile only ranks a CVE against the others. There is no official threshold, so pick one using coverage and efficiency.
• Write the matrix down and automate it. A documented rule set (for example SSVC-style outcomes mapped to remediation targets) removes daily debate and makes exceptions visible.
• Measure the debt, not just the closures. Track the age of KEV and high-likelihood findings on exposed assets; a falling ticket count can hide a growing pile of the findings that matter.

Why CVSS base scores alone fail as a queue

The CVSS v4.0 specification is explicit that the Base score is a starting point: consumers "should enrich the Base metrics with Threat and Environmental metric values" to get an input to risk assessment specific to their organisation. Sorting by base score alone produces three predictable problems:

• Too many "criticals": FIRST's EPSS model page gives a worked example using CVEs from October 2023. Remediating everything at CVSS 7 or above covered 82.2% of the vulnerabilities later exploited but required acting on 57.4% of all CVEs, with an efficiency of 3.96%. An EPSS threshold of 10% (which FIRST calls arbitrary) needed action on 2.7% of CVEs, with 63.2% coverage and 65.2% efficiency.
• Exploited "mediums" wait: a flaw rated 6.5 that is being used by ransomware crews sits behind dozens of theoretical 9.8s on internal test servers.
• No environment: the same CVE on an internet-facing VPN appliance and on an isolated lab host gets the same score.

The point of the example is not that one signal wins. CVSS alone gives high coverage at enormous cost; EPSS alone gives efficiency but misses some exploited CVEs. Combining signals, with KEV as an override, is what closes the gap.

The prioritisation signals compared

NIST has also proposed a further metric, Likely Exploited Vulnerabilities (LEV), in CSWP 41 (May 2025). LEV estimates the likelihood that a vulnerability has already been observed exploited and is intended to help correct EPSS errors and measure how complete KEV-style lists are. Treat it as an emerging input rather than a production signal until performance measurements are published.

Using CVSS v4.0 properly

CVSS v4.0 splits metrics into four groups and introduces nomenclature that tells the reader which groups were used: CVSS-B (Base only), CVSS-BT (Base and Threat), CVSS-BE (Base and Environmental) and CVSS-BTE (all three). A score quoted without that label should be assumed to be Base only.

The qualitative scale is unchanged: None 0.0, 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. A vector string records exactly what was asserted, for example CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:A. Store vectors, not just numbers, so you can recompute when you change your Environmental values.

• Automate the Threat metric: set E to A when the CVE is in KEV or your threat intelligence confirms exploitation, P when a public proof of concept exists, U otherwise. This is the cheapest way to make CVSS reflect reality.
• Set CR, IR and AR per asset class, not per finding: tag crown-jewel systems once in the CMDB and let the tooling apply the values.
• Do not average v3.1 and v4.0: during the transition, keep the version alongside the score and compare like with like.

Using EPSS without misusing it

EPSS produces a daily estimate of the probability that exploitation activity will be observed against a CVE in the next 30 days, using exploitation data from partners such as honeypots, IDS and IPS sensors and host-based detection. FIRST's guidance contains several rules that are frequently ignored:

• Probability versus percentile: the probability is absolute; the percentile ranks a CVE against all currently scored CVEs. A CVE at the 95th percentile can still have a low probability. Set thresholds on probability.
• No official threshold: the FAQ says there is no universal threshold and that 0.10 is commonly cited but "carries no special authority". Choose a threshold by testing coverage (share of exploited CVEs you would catch), efficiency (share of your actions that hit exploited CVEs) and effort (share of CVEs you would act on) against your own backlog.
• Never multiply EPSS by CVSS: FIRST states that doing so "does not compute probability x severity and is never a good idea". Use the two in a matrix instead.
• Threat only: EPSS does not know your environment or compensating controls. Combine it with exposure and asset criticality.
• Record the model version: the first line of the EPSS CSV names the model, and the model is retrained roughly annually. Scores can shift on a model change, so log the version with each prioritisation decision.

FIRST's user guide suggests a simple quadrant: high severity and high probability, patch first; high severity and low probability, monitor in case the threat changes; low severity and low probability, deprioritise.

KEV and SSVC: evidence and decisions

The Known Exploited Vulnerabilities catalogue

CISA adds a vulnerability to KEV only when it has an assigned CVE ID, reliable evidence of active exploitation (scanning, research and public proof-of-concept code do not count) and clear remediation guidance. BOD 22-01 makes KEV remediation mandatory for US federal civilian agencies; CISA recommends that everyone else build a requirement to address KEV vulnerabilities into their vulnerability management plan and use the catalogue as an input to frameworks such as SSVC.

The catalogue is small relative to the CVE corpus. In the version dated 21 October 2026 it held 1,754 entries, 361 of them flagged "Known" for ransomware campaign use, and 1,025 entries carried a federal due date 21 days after the date added. That size is the point: KEV is a short list you can realistically clear.

KEV also lags. CitrixBleed 2 (CVE-2025-5777) was disclosed on 17 June 2025, exploitation was reported from around 20 June, and CISA added it to KEV on 10 July with a due date of the following day. Organisations that waited for the KEV listing to act on a 9.3 flaw in an internet-facing gateway were already weeks late.

Stakeholder-Specific Vulnerability Categorization

SSVC replaces a score with a decision tree. CISA's version uses five decision points:

The outcomes are Track (remediate within standard timelines), Track* (standard timelines, closer monitoring), Attend (supervisory attention, remediate sooner than standard) and Act (supervisory and leadership attention, remediate as soon as possible). CISA's Vulnrichment project adds the first three decision points to many new CVE records in the CISA ADP container, so the public half of the tree can be automated; the two organisational inputs must come from your own asset data.

Building a prioritisation matrix

A workable matrix combines evidence of exploitation, exploit likelihood, exposure and business impact. The tiers below are an illustrative starting point; your remediation targets belong in policy (see the Remediation SLAs and Vulnerability Exceptions Guide).

• Exposure first: confirm reachability from the internet or from user networks with attack surface data, firewall rules and cloud security group analysis. See the Exposure Management and CTEM Guide.
• Re-evaluate daily: KEV additions and EPSS jumps should promote existing findings automatically. A finding's tier is not fixed at discovery.
• Compensating controls lower tiers only with evidence: record the control (WAF rule, disabled feature, network isolation) as a Modified Base metric or an exception with an expiry date.
• Treat the backlog as debt: prioritisation debt accumulates when P3 and P4 findings never close and quietly become P1 when exploitation starts. Review aged findings monthly, which also satisfies CIS Safeguard 7.2's monthly review of the remediation process.

Where identity fits

Many of the vulnerabilities that reach KEV leak or bypass credentials: session tokens from memory over-reads, machine keys, service account passwords on edge devices. Two adjustments follow:

• Raise priority for identity-bearing assets: identity providers, VPNs, SSO gateways, secrets stores, CI/CD servers and backup consoles hold credentials that unlock everything else. Give them the highest CR and IR values and Essential mission prevalence.
• Patching is not the end of a P1: when the flaw exposes secrets or sessions, the remediation ticket must include terminating sessions and rotating keys, tokens and service account credentials that the device held. See the Session Hijacking and Cookie Theft Guide and the Secrets Rotation Runbook Template.

Implementing risk-based prioritisation

1. Fix the inventory join: make sure every scanner finding resolves to an asset record with owner, environment, internet exposure and business service. Findings that cannot be joined cannot be prioritised. See the Asset Inventory and CMDB Security Guide.
2. Ingest the public feeds: pull the KEV JSON feed and the daily EPSS CSV, and read CVSS v4.0 vectors and CISA ADP SSVC values from CVE records. Store the EPSS model version and score date with each finding.
3. Write the rule set: document the tiers, the EPSS threshold and its rationale, and what evidence lowers a tier. Get IT and business owners to sign it, because they will receive the tickets.
4. Back-test before switching: run the new rules in parallel with the current CVSS-based queue for one or two patch cycles. Compare how many findings each approach flags and how many KEV entries each would have caught.
5. Pilot with one platform team: start with a team that owns exposed infrastructure, collect feedback on false urgency, and tune the threshold.
6. Automate promotion: schedule a daily job that re-tiers open findings when KEV or EPSS changes and notifies owners of promotions.
7. Roll back safely: keep the old severity field on every ticket so you can revert the queue view if the new rules misbehave; never delete the CVSS data.

Decision guidance by organisation size

• Small organisations (no dedicated VM team): use KEV as the must-fix list, EPSS with a single conservative threshold for everything internet-facing, and vendor automatic updates for the rest. Spend time on an accurate list of internet-facing systems rather than on scoring nuance.
• Mid-sized organisations: add asset criticality tags and implement the four-tier matrix in the scanner or ticketing tool. SSVC with Vulnrichment inputs is achievable here.
• Large or regulated organisations: full CVSS-BTE scoring driven by CMDB attributes, SSVC with mission prevalence from business impact analysis, attack path analysis for choke points, and a formal exception process with risk owner sign-off. See the Risk-Based Vulnerability Management Guide.
• Choosing SSVC or a scored matrix: SSVC suits organisations that want explainable decisions and already map assets to business services. A numeric matrix suits teams whose tooling only sorts by number; keep its inputs visible so it does not become another opaque score.

Detection and measurement

Log every tier decision with its inputs (CVSS vector, EPSS score and model version, KEV status, exposure flag, asset criticality) so you can audit why a finding was or was not urgent. Useful metrics:

• KEV exposure window: median days from KEV addition (or from your own exploitation evidence) to remediation on affected assets.
• Open KEV findings on internet-facing assets: target zero; report the count and age weekly.
• Coverage and efficiency of your threshold: recalculate quarterly against KEV additions to check the threshold still catches exploited CVEs without flooding teams.
• Prioritisation debt: count of P1 and P2 findings past target, and the age distribution of P3 findings.
• Promotion latency: time between a KEV or EPSS change and the owner being notified.
• Unjoined findings: percentage of findings with no asset owner or criticality, which cannot be prioritised at all.

Framework mapping

Common failure patterns

• Sorting by base score and calling it risk-based: the queue is still dominated by theoretical criticals, and exploited mediums wait months.
• Waiting for KEV: KEV confirms exploitation; it does not predict it. CitrixBleed 2 was being exploited for weeks before its listing, so exposed edge devices need action on vendor advisories and threat intelligence, not only on catalogue entries.
• Using the EPSS percentile as a threshold: "top 5%" sounds selective but can include many CVEs with low absolute probability.
• Multiplying scores into a single number: EPSS times CVSS, or vendor "risk scores" with undisclosed inputs, hide the reason for a decision and cannot be audited.
• Prioritising findings that cannot be fixed by anyone: no owner, no maintenance window, no patch path. Fix ownership and end-of-life replacement before tuning scores.
• Closing the ticket at patch time: after flaws that leak sessions or keys, as with ToolShell in July 2025, where stolen ASP.NET machine keys let attackers sign trusted payloads after the fix, access survives patching unless the secrets are rotated.

Practitioner checklist

• Ingest KEV, daily EPSS (with model version) and CVSS v4.0 vectors into the vulnerability platform.
• Tag every asset with owner, internet exposure and criticality, and set CR, IR and AR from those tags.
• Set CVSS Exploit Maturity automatically from KEV and threat intelligence.
• Document a tiered matrix with KEV as an override and an EPSS probability threshold justified by coverage and efficiency.
• Re-tier open findings daily and notify owners of promotions.
• Require session termination and credential rotation in the remediation steps for flaws that expose secrets.
• Record compensating controls as evidence with an expiry, not as silent downgrades.
• Report KEV exposure window, open KEV on exposed assets and prioritisation debt monthly.

Standards and references

• FIRST: Common Vulnerability Scoring System v4.0 Specification Document
• FIRST: The EPSS Model
• FIRST: EPSS Frequently Asked Questions
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• CISA: Vulnrichment
• NIST: CSWP 41 Likely Exploited Vulnerabilities, A Proposed Metric
• NIST: SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning

Related NHI Mgmt Group resources: Vulnerability Management Guide · Zero-Day and Exploited Vulnerabilities Guide · Vulnerability Scanning Guide · Patch Management Guide · Vulnerability Management Buyer's Guide