KEV, EPSS and SSVC: How to Prioritise Exploitable Vulnerabilities Before They Become Incidents

Most vulnerability management programmes still operate as if CVSS were the answer to "what should we patch first?". It isn't. CVSS is a severity score; it tells you how bad a vulnerability could be in theory, not whether anyone is actually exploiting it, not whether your environment is reachable, not whether it should be your week's priority. The result: backlogs of thousands of "critical" findings, IT teams that can't keep up, and the exposures that get exploited are often not the ones at the top of the CVSS list.

Three frameworks have emerged to close that gap: CISA KEV (what's actually being exploited), EPSS (what's likely to be exploited soon), and SSVC (what should we do about it). Combined, they turn vulnerability prioritisation from a guessing game into a defensible decision process. This article explains each, shows how to combine them in practice, and provides a decision tree, KPIs and a checklist for operational rollout.

Why CVSS alone isn't enough

CVSS gives a severity score from 0 to 10 based on theoretical impact and exploitability. Useful as a starting filter, but blind to several factors that determine real risk:

• Whether the vulnerability is being exploited right now in the wild.
• How likely it is to be exploited in the next 30 days.
• Whether your specific environment exposes the vulnerable component to a reachable attack path.
• What compensating controls already mitigate the risk.
• What business value is at stake if the vulnerability is exploited.

A CVSS 9.8 on an isolated dev system is less urgent than a CVSS 6.5 with active exploitation on a customer-facing API. Without that context, prioritising by CVSS alone produces noise that drowns the signal.

CISA KEV: what's actually being exploited

The Known Exploited Vulnerabilities (KEV) catalogue is published by CISA. Inclusion criteria: documented in-the-wild exploitation, a CVE identifier, and clear remediation guidance. As of mid-2026 the catalogue lists over 1,200 entries with deadlines for US federal agencies — and is widely adopted as ground truth across industries.

Why it matters: if a CVE is in KEV, exploitation isn't theoretical. Someone is using it right now. That moves it to the front of the queue regardless of CVSS score. KEV inclusion is the strongest single signal of urgency available.

Operational use:

• Subscribe to the KEV feed (CSV/JSON updated continuously).
• Cross-reference every internal vulnerability finding against KEV.
• Any KEV match in an in-scope asset moves to priority tier 1.
• Track time from KEV publication to remediation in your environment as a KPI.

EPSS: predicting what will be exploited

The Exploit Prediction Scoring System (EPSS) is maintained by FIRST.org. It produces a daily-updated score from 0 to 1 representing the probability that a given CVE will be exploited in the next 30 days. Built from a machine-learning model trained on exploitation telemetry, threat intelligence and vulnerability metadata.

Useful thresholds in practice:

• EPSS > 0.5 → high probability of exploitation soon; treat with KEV-level urgency even if not yet in the catalogue.
• EPSS 0.1-0.5 → meaningful probability; queue for the next remediation cycle, monitor for changes.
• EPSS < 0.1 → low predicted probability; CVSS and asset context drive the decision.

EPSS complements KEV: KEV tells you what's exploited, EPSS tells you what's about to be. Both feeds together cover the actionable horizon.

SSVC: turning data into decisions

Stakeholder-Specific Vulnerability Categorization (SSVC), developed by CMU's CERT Division, formalises the decision process. Instead of producing a score, it produces a decision: act now, act soon, act eventually, or no action.

SSVC decisions take into account:

• Exploitation status — none, PoC available, active exploitation.
• Exposure — small, controlled, open.
• Impact on mission — degraded, MEF impacted, mission failure.
• Safety impact — none, minor, major, hazardous.

The output is a decision label — Immediate, Out-of-cycle, Scheduled or Defer — that aligns with your remediation SLAs and is defensible to leadership and auditors.

A practical model: combining KEV + EPSS + SSVC

None of the three replaces the others; combined they form a layered prioritisation engine.

• Layer 1 — KEV match: if the CVE is in KEV and the asset is in-scope, the decision is Immediate. Skip further analysis.
• Layer 2 — EPSS threshold: if EPSS > 0.5 and the asset is exposed, the decision is Out-of-cycle (act this week).
• Layer 3 — SSVC tree: for everything else, walk the SSVC tree with the asset and threat context. Outcome is Scheduled or Defer.

This gives you a small list of true priorities (typically <5% of the raw scanner output) that can actually be remediated within SLA, plus a defensible explanation for everything else.

Decision tree (printable)

Step 1. Is the CVE in CISA KEV?

• Yes + asset in-scope → Immediate (24-72h).
• Yes + asset not in-scope → Scheduled, monitor scope changes.
• No → Step 2.

Step 2. Is EPSS > 0.5?

• Yes + asset exposed → Out-of-cycle (7 days).
• Yes + asset isolated → Scheduled.
• No → Step 3.

Step 3. Walk SSVC tree (exploitation status, exposure, impact, safety).

• Immediate or Out-of-cycle → escalate.
• Scheduled → next monthly cycle.
• Defer → document rationale, review quarterly.

Turning this into an operational process

Six steps to operationalise:

• Ingest feeds: KEV (CSV), EPSS (CSV/API), your scanner output. Refresh daily.
• Enrich findings: for every finding, attach KEV status, EPSS score, asset criticality from CMDB, exposure (public/internal/isolated).
• Apply prioritisation engine: run the layered logic above; output is a tiered queue.
• Route to remediation: tier 1 to IT change with expedited approval, tier 2 to standard change, tier 3 to scheduled cycles.
• Verify closure: confirm patch applied, re-scan to validate, close the ticket only after re-validation.
• Report: track time-to-remediate per tier, ageing exposures, KEV closure rate.

Metrics that actually add value

• Time from KEV publication to internal remediation (target: <72h for tier 1 assets).
• Percentage of EPSS > 0.5 findings closed within 7 days.
• Ageing exposures: open tier 1 findings > SLA (target: 0).
• Ratio of tier 1 / tier 2 / tier 3 findings — useful to spot prioritisation drift.
• Validation re-scan rate (closed tickets that survive re-scan).
• Detection coverage for the top 20 KEV exploits relevant to your stack (handled by your managed SOC).

Technical example: prioritising a VPN CVE

Scenario: scanner reports a critical CVE (CVSS 9.8) in your edge VPN appliance.

• KEV check: CVE present in KEV (added two days ago). → Immediate.
• Exposure: internet-facing, used by all remote workforce.
• Decision: emergency change, patch within 24h, validate via re-scan and exposure check, notify SOC to elevate detection on the appliance for the next 7 days.

Without KEV + business context, this CVE might have sat in a queue of 200 "criticals" for a month.

Technical example: prioritising an internal CVE

Scenario: scanner reports a critical CVE (CVSS 9.1) in a database server used by an internal reporting tool, accessible only from a management VLAN.

• KEV check: not in KEV.
• EPSS: 0.08 — low probability of exploitation in next 30 days.
• SSVC: exposure controlled, impact degraded (not MEF), no safety impact. → Scheduled.
• Decision: patch in the next monthly maintenance window. No emergency action needed.

Without the layered model, this would compete for attention with the VPN CVE — and IT bandwidth gets wasted on lower-impact work.

The common mistake: confusing compliance with risk reduction

Compliance frameworks often define remediation SLAs by CVSS tier (e.g., "patch all critical CVSS within 30 days"). Following that literally without the KEV/EPSS/SSVC layer means treating exploited and unexploited criticals the same way — which guarantees the exploited ones don't get fixed fast enough and the unexploited ones consume capacity that should go elsewhere.

The right framing for the auditor: "our prioritisation model uses CVSS as the input filter and KEV/EPSS/SSVC for decision-making. Our SLAs are tiered accordingly. Here's the evidence of closure rates per tier." Audit-defensible and operationally sound.

What the SOC does in this model

The managed SOC role complements vulnerability management. For every KEV-listed CVE relevant to your stack, the SOC should:

• Verify detection coverage for the exploitation TTPs.
• Tune alerts during the remediation window for affected assets.
• Hunt retroactively for evidence the vulnerability was exploited before remediation.

This bridges vulnerability and threat management — neither one alone tells the full story.

What threat intelligence adds

KEV and EPSS aggregate public signal. Targeted threat intelligence adds context specific to your sector and adversary landscape: which exploits are being weaponised by groups that target your industry, what TTPs are emerging that haven't yet hit the public catalogues, which exposed software in your stack appears in recent campaigns.

For regulated sectors (finance, healthcare, critical infrastructure), this sectoral context often shifts prioritisation: a CVE with low EPSS that's being weaponised by an APT targeting your sector deserves attention KEV may not yet reflect.

How Hard2bit helps

If you're building this model from scratch, the most common stumbling blocks are feed integration, asset context enrichment and the decision logic itself. Our vulnerability management service covers the operational discipline: feeds integrated, prioritisation engine tuned, remediation routing in place, KPIs tracked and reported. For organisations also running a managed SOC with us, the two functions share context — vulnerabilities and detections aligned.

Checklist for KEV + EPSS + SSVC rollout

• KEV feed ingested and cross-referenced with internal findings.
• EPSS feed integrated, scores attached to findings, refreshed daily.
• SSVC decision tree documented and applied to non-KEV/non-high-EPSS findings.
• Asset criticality available from CMDB or equivalent.
• Exposure status (internet-facing / internal / isolated) per asset.
• Tiered remediation SLAs aligned with the decision output.
• Ticketing integration with IT change for tier 1 expedited approval.
• Re-scan validation as the closure gate.
• KPI reporting with tier-by-tier metrics for the security committee.
• SOC alignment on detection for top KEV CVEs in your stack.

Conclusion

CVSS-only prioritisation produces backlogs that paralyse remediation. KEV + EPSS + SSVC produces a small, defensible list of actual priorities — and a structured rationale for everything else. The model is published, the feeds are public, the integration is achievable with existing tooling. The hard part is the discipline of running it consistently.

Organisations that adopt this layered model typically reduce time-to-remediate for KEV-listed exposures by 60-80% within the first quarter, while reducing total ticket volume on IT change. The risk reduction is real and measurable.

If you want help implementing this, talk to a Hard2bit specialist and we'll scope a focused first phase.

Disclaimer: KEV, EPSS and SSVC are continuously evolving frameworks. Specific thresholds and decision criteria in this article reflect practical experience as of mid-2026 and should be adapted to your sector, risk appetite and existing tooling. This article is informational and does not replace a formal vulnerability management assessment or compliance review.