Comparing NIST LEV, EPSS, and KEV for Vulnerability Prioritization

In today’s threat landscape, security teams need to focus on flaws most likely to be exploited. Traditional CVSS severity scores alone fall short because they don’t capture real-world attack trends. Three complementary approaches have emerged to quantify exploitation likelihood:

1. NIST’s Likely Exploited Vulnerabilities (LEV) metric: A statistical model that estimates a probability score (0–1) of exploitation.
2. Exploit Prediction Scoring System (EPSS): An ML-driven, community-supported standard predicting the chance a vulnerability will be exploited within 30 days (0–100%).
3. Known Exploited Vulnerabilities (KEV) list: A CISA-curated set of CVEs with confirmed evidence of exploitation.

This post explains each approach—data inputs, methodologies, use cases, and limitations—and provides guidance on combining them to create a risk-based patch management strategy.

‍

1. Why Move Beyond CVSS

• Context Gap: CVSS measures theoretical impact (attack vector, complexity, privileges) but not real-world data on exploitation.
• Static Scores: Once published, CVSS ratings don’t adapt to changes in exploit availability or patch adoption.
• Resource Misallocation: Teams may waste time addressing high-severity but low-risk flaws, while overlooking moderate-severity issues that attackers actively target.

Probability-based models—such as LEV and EPSS—integrate actual exploitation signals (e.g., public Proof-of-Concepts, threat intelligence) so that remediation efforts align more closely with operational risk.

‍

2. NIST’s Likely Exploited Vulnerabilities (LEV)

2.1 Overview

NIST CSWP 41, titled “Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability,” was published on May 19, 2025. Rather than assigning a severity rating, LEV computes a probability score in the range [0,1] representing the chance that a vulnerability will be exploited in the wild within a specified window (e.g., 90 days).

Key differentiators of the LEV metric include:

• Statistical Modeling: LEV relies on regression and Bayesian inference to quantify how various factors influence exploitation likelihood.
• Contextual Data Integration: The model incorporates both technical attributes (e.g., CVSS vector string, presence of a public exploit) and temporal data (e.g., time since disclosure, patch availability ratio).
• Alignment with NIST Guidance: LEV is explicitly designed to integrate with NIST’s RMF and CSF, helping organizations satisfy criteria in the “Identify” and “Protect” functions.

2.2 Data Sources and Methodology

The LEV framework aggregates multiple data inputs, each contributing to a vulnerability’s probability score:

1. CVE Metadata: Basic information such as CVSS vector string, affected products, and publication date.
2. Proof-of-Concept (PoC) Exploits: Indicators of PoC availability from repositories like Exploit DB.
3. CISA KEV Inclusion: A binary flag if the CVE appears on the Known Exploited Vulnerabilities list.
4. Patch Adoption Rate: The percentage of publicly exposed instances patched within a given timeframe—a proxy for attacker opportunity.
5. Historical Exploit Frequency: Counts of past exploit events for similar vulnerability families or vendors.
6. Vendor Advisories and Bulletins: Signals from vendor security bulletins about exploitation trends.

From these data points, NIST researchers apply statistical techniques:

• Feature Engineering: Variables such as “time since disclosure” are normalized; categorical variables (e.g., vulnerability type) are one-hot encoded.
• Regression Analysis: A logistic regression model estimates the log-odds of exploitation, calibrated on a labeled dataset where the outcome is observed exploitation.
• Bayesian Inference: For newer vulnerabilities with sparse data, LEV uses Bayesian priors derived from historical families to avoid zero-probability bias.

The resulting formula resembles:

P(exploit) = sigmoid(β0 + β1 * TimeSinceDisclosure + β2 * PoC_Flag + β3 * PatchAdoptionRate + β4 * KEV_Flag + ...)

Where each β_i represents the weight learned during model training, and sigmoid(x) = 1 / (1 + e^{-x}) maps log-odds to a [0,1] probability.

2.3 Score Interpretation and Thresholds

• Probability Value: A score near 1.0 implies a very high likelihood of exploitation; near 0 implies a low probability.
• Risk Tiers: NIST recommends categorizing continuous scores into tiers (e.g., Low: 0–0.2, Medium: 0.21–0.5, High: 0.51–0.8, Critical: 0.81–1.0) to facilitate organizational triage.
• Time Window: Organizations should specify the timeframe (e.g., next 90 days) when interpreting scores.

2.4 Use Cases and Integration

• Vulnerability Management Platforms: Teams can integrate LEV via NIST-provided scripts or APIs. When ingesting new CVEs, the platform fetches LEV scores and displays them alongside CVSS scores.
• Asset-Centric Risk Dashboards: By combining LEV with asset criticality (e.g., business impact, exposure), security teams compute a “Risk = LEV × AssetCriticality” value to prioritize patching.
• Incident Response Prioritization: When triaging alerts, responders can reference LEV to gauge the probability that an observed indicator of compromise corresponds to an exploitable vulnerability in their environment.

2.5 Strengths and Limitations

Strengths:

• Transparent Methodology: Regression and Bayesian models are well-documented, enabling organizations to audit the derivation of scores.
• Contextual Nuance: Incorporates temporal and exploitation data, reducing noise associated with severity-only approaches.
• Alignment with NIST Frameworks: Facilitates compliance with federal guidelines (e.g., RMF, CSF).

Limitations:

• Data Dependence: Relies on timely, accurate data feeds. If patch adoption rates or PoC indicators lag, LEV scores may be skewed.
• Lag for Zero-Days: New vulnerabilities without historical data may default to priors, underestimating real exploitation risk until enough signals accumulate.

Model Maintenance: Organizations must retrain or recalibrate models periodically to account for evolving threat landscapes. CSWP 41, titled “Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability,” was published on May 19, 2025. Rather than assigning a severity rating, LEV computes a probability score in the range [0,1] representing the chance that a vulnerability will be exploited in the wild within a specified window (e.g., 90 days).

‍

3. Exploit Prediction Scoring System (EPSS)

3.1 Overview

EPSS, governed by the Forum of Incident Response and Security Teams (FIRST), is an open, community-driven standard that predicts the probability of a vulnerability being exploited within the next 30 days. Since its initial release in 2020, EPSS has undergone multiple iterations; EPSS v4 launched in April 2025 with enhanced features.

Core characteristics of EPSS include:

• Machine Learning Model: EPSS employs supervised learning (e.g., gradient boosting) trained on historical data mapping CVEs to observed exploitation.
• Frequent Updates: The EPSS dataset and model parameters are updated monthly to reflect new vulnerabilities and attack patterns.
• Public API and Scoring Service: Organizations can query EPSS scores via RESTful endpoints or download bulk CSVs for offline processing.

3.2 Data Sources and Model Architecture

EPSS integrates a variety of data inputs:

1. CVE Attributes:
   
   • CVSS vector components (attack complexity, user interaction, privileges required).
   • CWE classification (vulnerability types such as buffer overflow, injection).
   • Vendor and product names.
2. Textual Features:
   
   • Natural language processing (NLP) on NVD descriptions, extracting keywords and embedding vectors.
   • TF-IDF scores for terms correlated with historical exploits.
3. Historical Exploit Data:
   
   • Public exploit repositories (e.g., Exploit DB, Metasploit).
   • Threat intelligence sources (e.g., Recorded Future, LogRhythm) indicating real-world exploitation.
4. Temporal Signals:
   
   • Time since disclosure.
   • Time since public PoC release.
   • Patch availability (time-to-patch metrics aggregated from vendor advisories).

Model Workflow:

1. Feature Engineering: Numerical features are normalized; categorical features (e.g., vendor) are one-hot encoded or mapped to industry sectors. Text embeddings are derived via word2vec or similar algorithms.
2. Training Dataset Construction: Historical CVEs are labeled as “exploited” or “not exploited” based on evidence from exploit feeds and security bulletins.
3. Model Training: A gradient boosting decision tree (e.g., XGBoost) is trained to minimize log loss, optimizing for both precision and recall on a holdout validation set.
4. Output Scoring: The trained model outputs a probability (0–1), typically represented as a percentage (0–100%).
5. Calibration and Validation: EPSS maintainers calibrate using isotonic regression to ensure probabilities correspond closely to observed frequencies. Continuous validation against new exploit data measures model drift.

3.3 Score Interpretation and Risk Tiers

• Probability Score: A numerical value (e.g., 0.73 indicates a 73% chance of exploitation within 30 days).
• Categorical Tiers (Example):
  
  • Low: 0–10%
  • Medium: 11–50%
  • High: 51–75%
  • Critical: 76–100%
• Use Cases:
  
  • SIEM and Ticketing Integration: Automatically tag incoming CVE alerts with EPSS scores to inform ticket prioritization.
  • Dashboards: Vulnerability management consoles display EPSS alongside CVSS for more nuanced decision-making.
  • Threshold-Based Alerting: Teams can configure alerts when EPSS exceeds a certain level (e.g., >80%).

3.4 Strengths and Limitations

Strengths:

• Data-Driven and Continuous: Monthly retraining ensures the model captures emerging threats and attacker behaviors.
• Community Adoption: EPSS is integrated into commercial scanners (e.g., Tenable, Qualys) and open-source tools, increasing ecosystem support.
• Granular Predictions: Provides fine-grained probabilities, enabling security teams to calibrate response actions based on tolerance for risk.

Limitations:

• Black-Box Nature: Because EPSS relies on ensemble ML models, understanding why a particular CVE receives a high score can be opaque without deeper model introspection.
• Bias Toward Well-Known CVEs: Vulnerabilities with more public information (e.g., popular software) may be overrepresented, skewing predictions.

Short-Term Horizon: EPSS focuses on a 30-day window; vulnerabilities that might be weaponized later fall outside its scope.

‍

4. Known Exploited Vulnerabilities (KEV) List

4.1 Overview

The Known Exploited Vulnerabilities (KEV) catalog, maintained by the Cybersecurity and Infrastructure Security Agency (CISA), provides a curated list of CVEs for which there is verifiable evidence of exploitation in the wild. KEV is designed to enable agencies, critical infrastructure owners, and the broader community to address the most pressing threats immediately.

Key characteristics include:

• Definitive Evidence Requirement: A CVE is added only when there is documented proof, via incident reports, security advisories, or threat intelligence, that it has been exploited.
• Rapid Publication: CISA commits to publishing new KEV entries within a defined timeframe (e.g., 28 days from confirmed exploitation).
• Mandatory Compliance: Executive Order and Binding Operational Directive (BOD) mandates require federal agencies and contractors to patch KEV-listed CVEs within strict deadlines (e.g., 180 days, or shorter if critical).

4.2 Data Collection and Inclusion Criteria

• Threat Intelligence Sources: CISA ingests reports from US-CERT, the FBI, private-sector Computer Emergency Response Teams (CERTs), and trusted vendors.
• Incident Response Feeds: Real-world breach data submitted by organizations and security vendors.
• Vendor Advisories: Information about exploitation tendencies, such as attack chain details from major software providers (e.g., Microsoft, Adobe).
• Analyst Verification: Each candidate CVE undergoes analyst review to confirm exploitation evidence before KEV inclusion.

Once verified, the CVE is listed along with:

• Date Added: The calendar date when KEV inclusion becomes official.
• Exploitation Summary: Brief description of how the exploit was observed (e.g., publicly available PoC code or targeted attacks).
• Patch Availability: Details on vendor-issued patches or mitigations.

4.3 Use Cases and Integration

• Emergency Patching: Security teams use KEV as a “fire list” to drive immediate remediation efforts. For example, a KEV entry might trigger an all-hands patch day within an organization.
• Compliance Reporting: Federal agencies must report compliance with BOD directives, often submitting evidence that KEV-listed CVEs were addressed within mandated timelines.
• Risk Acceptance: In cases where patches are unavailable or break critical systems, risk acceptance processes are documented, citing KEV timelines and compensating controls.

Practical steps to integrate KEV into workflows:

1. Automated Feeds: Subscribe to CISA’s KEV JSON feed, scheduling a daily check-in to retrieve new entries.
2. Ticket Generation: Configure vulnerability management tools (e.g., ServiceNow, Jira) to auto-create tickets for any assets mapped to KEV CVEs.
3. Patch Testing and Deployment: Prioritize patch validation in staging environments, ensuring rapid roll-out to production within KEV deadlines.

4.4 Strengths and Limitations

Strengths:

• High Confidence: Every KEV entry is backed by confirmed evidence, eliminating guesswork.
• Mandatory Action: Regulatory mandates drive organizations to devote resources to patched vulnerabilities on KEV.
• Simplicity: A binary inclusion list—either a CVE is on KEV or not—streamlines decision-making.

Limitations:

• Retrospective Nature: KEV reflects past exploitation; it cannot predict emerging threats or unseen zero-day usage.
• No Probability Ranking: KEV does not distinguish between CVEs that are exploited in low-volume targeted attacks versus widespread ransomware campaigns.

Potential Lag: Analyst verification and publication processes can introduce a time lag from first exploitation to KEV listing.

‍

5. Comparative Analysis

5.1 Scope and Measure of Risk

• NIST LEV quantifies a vulnerability’s likelihood of exploitation through a statistical lens, blending multiple signals into a continuous probability.
• EPSS offers a machine learning–driven probability that focuses on a short-term (30-day) window, leveraging extensive feature sets and frequent retraining.
• KEV lists vulnerabilities only after confirmed exploitation, serving as a reactive but high-confidence source for immediate remediation.

5.2 Data Inputs and Modeling Complexity

• NIST LEV relies on regression and Bayesian inference, offering transparency in how each factor influences risk. It integrates CVE metadata, KEV flags, PoC availability, patch adoption, and historical exploit data.
• EPSS utilizes gradient boosting or similar ensemble methods, incorporating CVE attributes, text embeddings derived from vulnerability descriptions, exploit repository indicators, and temporal signals. While powerful, the inner workings can appear as a “black box” to some users.
• KEV bypasses modeling—its inclusion criteria are binary and based on analyst verification of real-world exploitation evidence.

5.3 Update Cadence and Latency

• NIST LEV: Intended to be updated on a quarterly or semiannual basis as NIST researchers gather new data; organizations can also implement their retraining cadence if hosting the LEV model locally.
• EPSS: Maintained on a monthly release cycle, meaning new CVEs and exploitation trends are rapidly incorporated, minimizing model drift.
• KEV: Updated as soon as exploitation evidence is verified—typically within 28–60 days of first observed exploitation, depending on report timeliness and analyst workload.

5.4 Transparency and Explainability

• NIST LEV: High transparency—NIST publishes methodology, model parameters, and variable weightings. Organizations can replicate or adapt the statistical model internally.
• EPSS: Moderate transparency—while feature lists and general model architecture are documented, detailed coefficients and decision paths can be opaque without deeper ML expertise.
• KEV: Fully transparent in terms of inclusion criteria—each entry cites sources and exploitation details, but provides no likelihood scores or rankings.

5.5 Use Cases and Decision Workflows

1. Immediate Patching:
   
   • KEV: If a CVE is on KEV, treat it as the highest priority—deploy emergency patches within mandated deadlines.
2. Short-Term Prioritization (Next 30 Days):
   
   • EPSS: For vulnerabilities not on KEV, use EPSS to identify those most likely to be exploited imminently. For example, vulnerabilities with an EPSS score of 80% or higher should be prioritized at the top of the 30-day patching schedule.
3. Longer-Term Strategic Planning (1–3 Months):
   
   • NIST LEV: For a broader planning horizon, use LEV scores to inform quarterly patch cycles, especially when staffing or maintenance windows are limited. LEV’s more comprehensive data inputs allow risk managers to understand exploitation trends over a multi-month timeframe.

5.6 Integration Effort and Operational Overhead

• NIST LEV: Requires statistical expertise to host and retrain models locally, or organizations can rely on NIST-published scores. Integrations may involve ETL pipelines to pull CVE data, PoC feeds, and patch metrics into the LEV computation engine.
• EPSS: Minimal overhead—public API, downloadable CSVs, or built-in integrations in commercial scanners simplify adoption. No local model maintenance is needed unless deep customization is required.

KEV: Easiest to integrate—simply consume a JSON feed and match CVEs against asset inventories. Ticketing and patching workflows can be triggered automatically upon KEV ingestion.

‍

6. Recommendations and Best Practices

6.1 Layered, Risk-Based Vulnerability Prioritization

To maximize efficiency and reduce exposure windows, adopt a tiered approach:

1. Tier 1 (Immediate):
   
   • KEV CVEs: Deploy patches within 30–60 days as required by mandates. For critical infrastructure, aim for 14–28 days where feasible.
2. Tier 2 (Short-Term):
   
   • EPSS > 75%: For vulnerabilities with high short-term exploit probability, schedule patch testing and deployment within your standard patch window (e.g., next monthly cycle).
3. Tier 3 (Long-Term / Strategic):
   
   • LEV > 0.6 (or organization-specific threshold): Integrate into quarterly or semiannual patch cycles for lower-probability but still significant vulnerabilities.
4. Tier 4 (Low Risk):
   
   • LEV < 0.2 and EPSS < 10%: Manual review, or patch during low-priority maintenance windows unless new evidence emerges.

6.2 Contextual Enrichment

Exploitation probability should never be the sole decision factor. Always combine probability scores with:

• Asset Criticality: Business impact, data sensitivity, and potential compliance implications.
• Threat Actor Intelligence: Indicators that specific threat groups are targeting certain CVEs.
• Compensating Controls: Network segmentation, web application firewalls (WAFs), intrusion prevention systems (IPS), and endpoint detection and response (EDR) solutions may reduce the need for immediate patching.

6.3 Automation and Workflow Integration

• SIEM/SOAR Playbooks: Automate ticket creation and escalations based on probability thresholds. For instance, trigger an automated playbook if EPSS > 80% and asset is internet-exposed.
• CMDB and Asset Inventory Sync: Ensure all assets are tagged with up-to-date configurations to accurately match CVEs with vulnerable systems.
• Scheduled Re-Evaluation: Configure automated scripts to re-fetch LEV and EPSS scores weekly, updating tickets and dashboards to reflect changes.

6.4 Continuous Monitoring and Model Validation

• Periodic Audit: Every quarter, assess how well your probability-based prioritization aligns with observed incidents. Compare patched vulnerabilities against any new exploitation observed in your environment.
• Threshold Calibration: Adjust EPSS and LEV thresholds (e.g., moving from 75% to 65%) based on organizational risk appetite and incident metrics (e.g., number of successful exploits).
• Feedback Loops: Feed back internal incident data into local versions of LEV or custom EPSS-like models to fine-tune predictions for your specific environment.

‍

7. Conclusion

The transition from severity-only to probability-based vulnerability prioritization is essential for modern security operations. Each of the three approaches d

• KEV: A definitive, evidence-based list of vulnerabilities known to be exploited. Ideal for emergency patching and compliance-driven mandates.
• EPSS: A rapidly updated, ML-driven predictor focused on short-term (30-day) exploitation probability. Enables dynamic, data-driven triage that keeps pace with evolving threat landscapes.
• NIST LEV: A transparent statistical model providing a broader, context-rich probability score. Aligns directly with NIST’s RMF and CSF, supporting risk-based decision-making over longer timeframes.

Rather than choosing one approach, organizations attain the greatest resilience by layering these tools: use KEV for urgent remediations, EPSS for tactical prioritization, and LEV for strategic planning. By combining probability metrics with asset criticality, threat intelligence, and automation, security teams can allocate resources more efficiently, reduce exposure windows, and enhance their overall cybersecurity posture.