TL;DR: LEV could help teams identify CVEs that may already have been exploited, even when they are missing from CISA KEV or have a low current EPSS score. Until an official feed exists, organizations should continue combining exploitation data, asset risk, severity, and remediation availability to prioritize vulnerabilities.
Likely Exploited Vulnerabilities (LEV) is a proposed metric from NIST and CISA researchers that estimates the probability that a vulnerability assigned a CVE ID has already been exploited in the wild. LEV uses historical EPSS data to supplement current EPSS scores and CISA’s KEV catalog, helping teams identify vulnerabilities that may need investigation or faster remediation.
Here’s how LEV works, where it fits alongside EPSS and CISA KEV, and how to prioritize vulnerabilities until an official LEV feed is available.
What would the Likely Exploited Vulnerabilities (LEV) metric look at?
The proposed LEV calculation uses a CVE’s historical EPSS scores to estimate the probability that exploitation has already been observed. NIST’s prototype also retrieves CVE information from NVD and compares its results with CISA KEV data. LEV could therefore surface higher-probability vulnerabilities that are not yet included in a KEV list or that have a deceptively low current EPSS score. However, an LEV probability would not confirm that exploitation occurred.
Translation for the overworked and under-caffeinated: LEV may help you spot the CVEs that may already have been exploited without appearing in a KEV catalog.
What is the Exploit Prediction Scoring System?
EPSS publishes a daily probability that exploitation activity will be observed for a published CVE within the next 30 days. It is especially useful when no direct evidence of exploitation is available. However, EPSS should not override confirmed threat intelligence, and it does not score vulnerabilities that do not yet have CVE identifiers.
What are Known Exploited Vulnerabilities?
CISA’s Known Exploited Vulnerabilities catalog contains CVEs known to have been exploited in the wild. Unlike EPSS and LEV, KEV inclusion is based on evidence of exploitation rather than a probability estimate.
How could LEV improve vulnerability management?
Here’s how LEV could help you manage vulnerabilities without losing your inner sense of calm (or your weekend):
Add historical context: Identify CVEs whose cumulative historical EPSS probabilities suggest exploitation may already have occurred.
Surface investigation candidates: Find vulnerabilities that may be underscored by current EPSS values or missing from relevant KEV lists.
Complement existing signals: Use LEV alongside confirmed exploitation evidence, asset exposure, business impact, severity, and available remediations.
Evaluate KEV coverage: Help researchers and catalog maintainers estimate whether a KEV list may be missing relevant vulnerabilities.
Can organizations use LEV today?
Organizations cannot currently consume LEV through an official NIST feed or API. The paper describes a Python implementation using NVD, CISA KEV, and historical EPSS data, but NIST lists no supplemental code. NIST also says LEV’s margin of error is unknown and that industry data is needed to test its performance.
Organizations could theoretically build their own implementation from the published equations, but LEV is not yet a plug-and-play vulnerability management signal. For immediate vulnerability prioritization, continue combining CISA KEV status, EPSS, vendor threat intelligence, asset exposure, business criticality, severity, and remediation availability. LEV is best treated as an emerging methodology to monitor rather than a mature operational standard.
How should teams prioritize vulnerabilities until LEV is available?
Until LEV becomes operational, prioritize vulnerabilities using confirmed exploitation evidence, exploit likelihood, asset exposure, business impact, severity, and remediation availability. Start with CISA KEV and active incident intelligence, then use EPSS and asset context to set remediation deadlines.
PDQ can also rank supported vulnerabilities using CVSS, business impact, access levels, exploitability, and weaponization, then connect vulnerability details with package deployment workflows.
Manage Windows & macOS devices from anywhere
With PDQ Connect, get real-time visibility into remote and local devices, deploy software, remediate vulnerabilities, automate routine maintenance, and remotely troubleshoot endpoints from one easy-to-use platform.
A practical five-step vulnerability prioritization framework
Use the following process to determine which vulnerabilities to patch first:
Check exploitation evidence. Prioritize vulnerabilities in CISA’s KEV catalog, vulnerabilities tied to active incidents, and vulnerabilities identified as exploited by trusted vendor or threat intelligence. Use EPSS, and LEV if an operational source becomes available, as additional probability signals.
Assess exploit availability. Check for public proof-of-concept code, functional exploits, weaponization, ransomware use, and active threat campaigns.
Map the vulnerability to asset risk. Identify whether affected systems are internet-facing, business-critical, privileged, or responsible for sensitive data.
Evaluate remediation options and impact. Confirm whether a patch, configuration change, workaround, isolation step, or compensating control is available. Account for testing requirements and potential downtime.
Assign a priority, deadline, and owner. Document the remediation SLA, deploy the fix according to risk, and verify that the vulnerability is no longer present.
Example vulnerability remediation SLAs
These sample targets can help teams translate vulnerability signals into action. Adjust them for your organization’s risk tolerance, regulatory requirements, maintenance windows, and available compensating controls.
Priority | Example criteria | Example target |
|---|---|---|
P1: Critical | Confirmed exploitation or KEV status affecting an internet-facing or business-critical asset | Mitigate within 24 hours and deploy the patch within 72 hours |
P2: High | High EPSS, a functional exploit, or likely weaponization affecting an exposed or important asset | Remediate within 7 days |
P3: Medium | High severity but no current exploitation evidence, with limited exposure or strong compensating controls | Remediate within 30 days |
P4: Routine | Low exploitability, low business impact, or minimal exposure | Remediate within 60 to 90 days or the normal patch cycle |
What should you do about an exploited or critical CVE?
When a vulnerability is confirmed or strongly suspected to be exploited, reduce exposure immediately while preparing the permanent fix:
Identify affected hosts and confirm whether they are exposed or business-critical.
Isolate high-risk systems when active exploitation or compromise is suspected.
Apply vendor workarounds, disable the vulnerable service, or use a compensating control when a patch cannot be deployed immediately.
Test and deploy the patch first to critical and internet-facing assets, then expand the rollout to remaining affected systems.
Rescan or otherwise verify remediation, review systems for signs of compromise, and close the ticket only after documenting the result.
LEV could eventually add historical exploitation context to vulnerability prioritization, but it is not yet an operational standard. Until a validated feed is available, teams should combine KEV, EPSS, threat intelligence, asset risk, and remediation availability rather than rely on one score.
PDQ brings vulnerability context and remediation workflows together, helping IT teams identify risky endpoint software, prioritize supported vulnerabilities, and deploy available fixes from the same platform. Try PDQ for free today.
