They should do it whenever remediation capacity is constrained and the environment changes quickly. Runtime verification tells you whether a vulnerability is active, while KEV and EPSS help indicate whether attackers are likely to care. Used together, they produce a stronger triage signal than severity alone.
When runtime verification adds value to KEV and EPSS
runtime verification matters most when patch queues are long, assets change quickly, or the same CVE has very different exposure across environments. KEV and EPSS are useful prioritisation signals, but they do not tell you whether the vulnerable code path is actually present, reachable, or actively used right now. Runtime verification closes that gap, which is why it is most valuable as a triage filter rather than as a standalone control.
Think of the combination as a decision stack: CISA’s Known Exploited Vulnerabilities Catalog tells you a weakness is confirmed in active exploitation, while FIRST EPSS estimates how likely exploitation is. Runtime verification adds a current-state check, so teams can separate “highly scored but dormant” from “present, exposed, and worth stopping first.”
The combination is especially useful in fleets where configuration drift, ephemeral deployments, feature flags, container rebuilds, or managed services can change exposure faster than the patch cycle. In those conditions, severity alone is a poor queueing signal because the real question is not just whether a vulnerability exists, but whether it is live in the paths that matter. Runtime verification helps answer that operational question before you spend scarce remediation effort.
What runtime verification tells you that KEV and EPSS do not
KEV and EPSS are both external signals, but they answer different parts of the triage problem. KEV is a “known active exploitation” indicator, and EPSS is a likelihood model. Runtime verification is local evidence: it shows whether the vulnerable package, code path, option, library version, exposure surface, or service state is actually present in your environment.
That distinction matters because a vulnerability can be relevant in theory and irrelevant in practice. A container image may contain a vulnerable component that is never started; a service may have a vulnerable endpoint that is not reachable from the network; or a control may already have removed the attack path even though the CVE remains in inventory. Runtime verification is the signal that prevents teams from treating every matched CVE as equally urgent.
For application and platform teams, this is the difference between inventory-based prioritisation and environment-based prioritisation. A strong external indicator still deserves attention, but runtime evidence tells you whether the issue is on an active path, which is often what decides whether to patch now, mitigate now, or schedule the fix into the next maintenance window.
How to combine the signals without over-prioritising noise
The most effective pattern is to use KEV and EPSS to rank candidates, then use runtime verification to confirm whether each candidate is materially exposed. That workflow works well when capacity is constrained because it reduces false urgency from theoretical exposure and improves confidence that the top items are the ones most likely to matter operationally.
A practical rule is to treat KEV as the strongest escalation signal, EPSS as the probability signal, and runtime verification as the applicability signal. When all three point in the same direction, the item moves to the top of the queue. When KEV or EPSS is high but runtime verification says the vulnerable condition is absent, teams can usually downgrade the item while keeping it tracked for drift or redeployment.
For teams managing application stacks, containers, or infrastructure-as-code, NIST SP 800-190 Container Security is a useful companion because it reinforces why image, registry, orchestrator, and runtime states should be checked together. If a vulnerability is only present in a build artifact but not in the live service path, that difference should change the remediation order.
Risk and Threat Considerations
When teams rely on KEV or EPSS alone, they can overreact to vulnerabilities that are not actually reachable and underreact to issues that are quietly live in production. The main risk is misallocation of scarce remediation capacity, especially in fast-moving environments where exposure can change between scan, ticket creation, and fix deployment.
Failure mechanism: KEV and EPSS describe exploitation relevance, but not local presence or reachability. Without runtime verification, teams may prioritise by external signal alone and miss the difference between a vulnerable component that is merely installed and one that is actively serving traffic or exposed to real requests.
Impact: High-scoring but low-exposure items can crowd out genuinely active risk, while exposed services can remain unpatched longer than intended. That increases the chance that remediation effort is spent where it delivers the least reduction in actual attack surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Runtime verification and KEV/EPSS both support faster vulnerability prioritization. |
| Recommendation — Continuously validate exposure and prioritize remediation for actively exploitable weaknesses. | ||
| NIST CSF 2.0 | ID.RA-05 — Threats, vulnerabilities and likelihood are used to determine risk | KEV and EPSS are risk inputs used to rank vulnerabilities by likelihood and impact. |
| PR.DS-08 — Integrity verification is performed | Runtime verification checks whether a vulnerable condition is actually present in the live environment. | |
| Recommendation — Combine threat and likelihood signals to rank vulnerabilities by risk. Verify runtime state to confirm whether the risky condition is actually active. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The question is about using vulnerability signals to prioritize remediation work. |
| SI-2 — Flaw Remediation | The combined signals inform what should be remediated first under constrained capacity. | |
| Recommendation — Use vulnerability intelligence and validation data to prioritize remediation. Use exposure and exploitability evidence to drive remediation ordering. | ||
Practitioner Guidance
What to prioritise: Use the combined signal first for assets with limited patch windows, high churn, or large numbers of similar hosts. Those are the environments where runtime verification most improves decision quality.
What to verify: Confirm that the runtime check is measuring the live code path or effective exposure, not just a static inventory record. If the check cannot distinguish installed from reachable, it is not strong enough to override a high-confidence KEV signal.
Decision rule: If KEV is positive and runtime verification confirms exposure, escalate immediately even when EPSS is moderate. If EPSS is high but runtime verification shows no active exposure, keep the item tracked, but do not let it displace confirmed live risk.
Practitioner takeaway: The best use of runtime verification is not to replace KEV or EPSS, but to make prioritisation environment-specific so constrained remediation effort lands on vulnerabilities that are both likely to matter and actually present.