Frequently Asked Questions
The basics
What is EPSS?
EPSS (Exploit Prediction Scoring System) is a data-driven model that estimates the probability a vulnerability will be exploited in the wild within the next 30 days. It produces a score between 0 and 1 for every publicly disclosed vulnerability (CVE), updated daily. EPSS has the EPSS Special Interest Group at FIRST and scores are generated by Empirical Security.
What is EPSS not?
EPSS is not a complete risk score. EPSS does not measure how much damage successful exploitation would cause, or whether it affects your environment. It does not account for any context for specific instances, any compensating controls, or any factor specific to an organization's environment. A complete risk calculation requires combining the EPSS probability of exploitation activity with the environmental context and probable impact. EPSS does not have insight into the context to produce a complete risk score but supports risk-based calculations by providing the probability of exploitation.
Who maintains EPSS?
EPSS has the EPSS Special Interest Group (SIG) at FIRST which discusses implementation, use cases and direction for ongoing development. All of the data, data science, infrastructure and support for the daily scores are provided by Empirical Security and published freely to the public. The SIG meets regularly and is open to practitioners, researchers, and data partners. See the Research page for the academic papers underlying the methodology.
Is EPSS free to use?
Yes. EPSS scores are published freely via CSV download and API with no registration required. Attribution is requested when EPSS data is used in publications or products. See Get the Data for access details and attribution guidance.
Reading the score
What does the EPSS probability score mean?
The score ranges from 0 to 1 (or 0% to 100%) and is an estimate of the likelihood that any one of our data partners (and their sensors) will detect, record and share evidence of exploitation activity associated with a vulnerability.
For example, a score of 0.05 means a 5% estimated probability and a score of 0.95 means a 95% estimated probability (of observed exploitation activity in the next 30 days). Put another way, among many vulnerabilities with EPSS scores around 0.05, we would expect exploitation activity to be observed for about 5% of them, or 5 out of 100, or 1 out of every 20 over the next 30 days. Similarly, among many vulnerabilities with EPSS scores around 0.95, we would expect exploitation activity to be observed for about 95% of them, or 95 out of 100, or 19 out of every 20 vulnerabilities. See How It Works for a full discussion of probability calibration.
What is the percentile, and how is it different from the probability?
The probability is an absolute measure; the percentile is a relative ranking.
The percentile ranks a vulnerability against all currently scored vulnerabilities. A vulnerability at the 90th percentile has a higher EPSS score than 90% of all scored vulnerabilities. Because the distribution of EPSS scores is heavily skewed toward zero (since most vulnerabilities have no observed exploitation activity) a probability of 0.10 (10%) currently sits around the 95th percentile. The probability tells you the absolute likelihood of exploitation; the percentile tells you where this vulnerability stands relative to the population.
Should I use the probability or the percentile?
It's important to understand that the percentile is just a transformation of the probability and the two measures serve different purposes.
EPSS probability is the model's direct and primary output. It is a value from 0 to 1 estimating the likelihood that exploitation activity for a CVE will be observed in the wild over the next 30 days. Because it is a probability it has specific properties and can be used in downstream quantitative work: expected counts, portfolio-level exposure estimates, threshold analysis, cost-benefit comparisons, and calibration checks among others.
Internalizing EPSS probabilities can be challenging. Exploitation has a low base rate (see "Why do most EPSS scores cluster near zero"), which means that most of the EPSS probabilities look small in absolute terms. This presents an intuitive challenge for people because research has shown that we are not naturally good at judging small probabilities¹. A 5% probability may sound low, but we are observing a base-rate around 2-3%. A 5% probability, when put into context, is ranked in the top 10% of all published vulnerabilities and represents a relatively likely high exploitation forecast (well above the expected base-rate of exploitation). That is why EPSS provides both values: probability tells you the estimated chance of observed exploitation, while percentile tells you how that probability compares with other CVEs.
¹ see Kahneman and Tversky's work on Prospect Theory
Why do most EPSS scores cluster near zero?
EPSS Scores cluster near zero because most vulnerabilities are never exploited. EPSS scores are estimated from and thus reflect that base rate. The CISA KEV catalog lists roughly 0.5% of published CVEs. In any 30-day window, through all of our data partners, EPSS is observed roughly 2.5-3% of published CVEs with exploitation activity. A model predicting exploitation over a 30-day horizon should assign low scores to the large majority of vulnerabilities, because for the large majority, no exploitation will occur (or more realistically are very unlikely to occur).
An estimated probability near zero is a prediction, not a data gap. It states that given the information across the thousands of data points EPSS is collecting, it is unlikely that we will observe exploitation activity for this particular vulnerability in the next 30 days. We can validate how well calibrated the estimated probabilities are by creating a calibration plot to show how accurate the predictions are across the range of predictions.
A rather small fraction of vulnerabilities carries almost all exploitation activity, so a small fraction should carry the high scores. Think of a scenario where we had a time machine and could go back 30 days with the exact set of 10,000 CVEs (of the 350,000 published CVEs) that would see exploitation activity in the next 30 days. If we scored them honestly and perfectly, we would assign 100% likely to the 10,000 then 97% of the CVEs would be 0%. This is the reality that EPSS is calibrated against.
Why did my score change overnight?
This is a very intentional design feature of EPSS. EPSS is a dynamic score that reacts to new information about the vulnerability, the community and even attacker behavior. Scores change because new information was collected and the state of our knowledge shifted, not because the model changed (although we do periodically update the model). Each day, EPSS recomputes everything we know about every vulnerability and runs the EPSS model against the current reality. A score that changes overnight means new signals arrived: exploit code became publicly available, signatures were published, chatter spiked across monitored domains or a new detailed analysis was published (or in some cases, existing information was removed). The scores always reflect our best estimation for the next 30 days given our current set of observations.
How is EPSS different from CVSS?
CVSS and EPSS measure different things. According to the documentation, CVSS measures severity, but severity is never defined. Scores are derived from a collection of experts comparing sets of vector strings and identifying the more-badder one without any empirical validation against any real world outcomes. Additionally, when most people discuss CVSS they are generally referring to the base ("CVSS-B") score and vector string. The CVSS v4.0 FAQ states directly that "CVSS-B Base scores are not risk." Without a clear definition of what "severity" is in CVSS or exactly what CVSS is measuring it is difficult to compare and contrast CVSS to EPSS. EPSS uses all individual CVSS metrics as input features (scores are ignored). The model learns what weight each actually carries from observed exploitation data rather than from expert consensus. The exploitability signal that CVSS encodes through judgment is already present in EPSS, just re-weighted against real-world exploitation activity.
Multiplying EPSS by a CVSS score does not compute probability × severity and is never a good idea. EPSS is a calibrated probability and CVSS Base is an ordinal ranking produced by expert judgment with no empirical calibration against outcomes. Multiplying a calibrated probability by an ordinal ranking produces a number with no interpretable meaning: it is no longer a probability, and the CVSS component contributes nothing beyond distorting the original score in proportion to expert opinion.
How is EPSS different from CISA KEV?
CISA KEV lists vulnerabilities with confirmed exploitation in the wild, a record of history. EPSS is a forward-looking probability estimate for the next 30 days, a forecast. A low EPSS score on a KEV-listed vulnerability is not a contradiction; the two measure different things and both are useful, for different reasons. See Using EPSS for how to combine the two signals and why KEV should take precedence when present.
Can EPSS be used for compliance purposes?
Yes. Several risk-based frameworks such as NIST SP 800-30 and ISO 27005, require threat likelihood estimation as a component of risk assessment. Current implementations generally rest on expert judgment, static scoring, or undocumented heuristics. Auditors typically accept these on the basis of framework alignment and documentation, not demonstrated predictive validity.
EPSS methodology is based on standard, established modeling techniques. It produces calibrated probabilities trained on empirically observed exploitation data, validated against held-out vulnerabilities over held-out time periods, with continuous monitoring of model performance against outcomes. These are standard requirements for any predictive model in a regulated domain. EPSS is an application of existing and proven techniques and has publications and the performance data to back up the value.
AI is accelerating exploit development. Does this make EPSS less relevant?
The opposite. A faster, more dynamic threat landscape increases the value of a system that updates daily and decreases the value of one that does not. If AI tooling is shifting attacker behavior (that is compressing time to exploitation, redirecting attention toward new vulnerability classes and generally changing the signal landscape), the right response is a system built to observe and adapt to exactly those changes. EPSS is trained on exploitation activity and the leading indicators correlated with it. Detecting a shift in that system requires the same feedback mechanisms EPSS is built on. Watching what attackers are doing, and how that is changing, is the method.
Using EPSS in practice
As a practitioner, where do I start?
Get the data: pull the daily CSV or use the API to integrate EPSS scores into your vulnerability management workflow. Use the probability score as a prioritization input to your decision making process. If you are just starting out, you could begin by identifying vulnerabilities in your environment with EPSS scores above a threshold (that you define) and prioritizing those. Over time, you can use the coverage, effort, and efficiency framework to calibrate that threshold against your remediation capacity and add additional context as the program grows (See Using EPSS).
What threshold should I use?
There is no universal threshold. The right threshold depends on your remediation capacity, risk tolerance, and asset context. A threshold of 0.10 (10%) is commonly cited in the field but carries no special authority from EPSS. Use the coverage, effort, and efficiency framework: choose a threshold where you can sustain the remediation volume it produces and where the coverage of exploited vulnerabilities it delivers matches your program's risk tolerance. See Using EPSS for a worked discussion of how to calibrate thresholds against your environment.
What counts as a "critical" or "high" EPSS score?
EPSS does not define score bands with labels like "critical," "high," or "medium." Those labels encode a risk tolerance decision — how much exploitation likelihood warrants action — that depends on your organization's remediation capacity, asset exposure, and risk appetite. EPSS deliberately leaves that decision to the practitioner.
Imposing a universal label would mean substituting EPSS's judgment for yours on a question EPSS has no basis to answer. A score that warrants immediate action in a high-exposure, internet-facing environment may be appropriately deferred in a lower-risk one. The same probability means different things in different operational contexts.
Use the coverage, effort, and efficiency framework to choose a threshold that fits your program. See Using EPSS for a worked discussion of how to calibrate thresholds against your remediation capacity and risk tolerance.
How do I apply a population-level score to my specific environment?
EPSS scores reflect exploitation probability across the global observed population, not your specific environment. Converting a population-level score into an environment-specific decision means combining it with local context. See Using EPSS for the full framework: presence, reachability, and consequence.
Is EPSS a risk score?
EPSS is part of a risk calculation. Risk measurement and estimation typically considers threat likelihood against environmental context with probable impact(s). EPSS provides the threat likelihood component only: the probability of exploitation in the wild in the next 30 days. It does not estimate impact, does not know what assets your organization runs, and does not account for compensating controls. Using EPSS as a complete risk score omits the factors that determine whether exploitation of a given vulnerability would actually harm your organization.
Can I use EPSS to estimate exploitation exposure across a set of vulnerabilities, not just one?
Yes. Because EPSS produces calibrated probabilities, there are many different ways to combine a collection of EPSS scores to either measure all of the vulnerabilities on a single asset or within some environment or by the owner(s) of a group of assets. See Using EPSS for a discussion of probability aggregation.
Common confusions
The score for this vulnerability seems wrong. Why?
EPSS reflects statistical patterns across thousands of vulnerabilities. For any individual vulnerability, the score represents what the model predicts given its observable features — not a lookup of past exploitation records for that specific vulnerability. If your threat intelligence or environmental context differs from the global patterns the model learned, the score may not match your expectations. That is not a flaw; it reflects the difference between population-level prediction and environment-specific assessment. Layer EPSS with local context rather than treating it as the final word.
A vulnerability has a critical CVSS score but a low EPSS score. What does that mean?
CVSS and EPSS measure different things and are empirically uncorrelated. High severity scores are slightly better than random at predicting exploitation activity. A critical CVSS score means a security practitioner is likely to consider the vulnerability bad. A low EPSS score means exploitation is unlikely given current signals. Both assessments can be correct simultaneously.
My vulnerability is on CISA KEV but has a low EPSS score. Which should I follow?
Follow KEV. See Using EPSS for the full reasoning.
Everyone knows this vulnerability is being exploited. Why doesn't it score at 100%?
EPSS is generating the daily scores without knowing if the vulnerability was recently exploited. It estimates the probability that exploitation will be observed in the next 30 days based on vulnerability features and current threat signals, not on a lookup of confirmed past exploitation. A score of 1.0 would mean certain exploitation in every future 30-day period, which is not empirically supportable for any vulnerability. If direct evidence of active exploitation exists, that evidence should supersede EPSS. EPSS works best in the range where direct exploitation evidence is absent: it differentiates among vulnerabilities that appear equivalent based on static scoring. See How It Works for a discussion of how exploitation activity feeds into training versus daily scoring.
Does recent exploitation activity change the score?
No, intentionally. Exploitation activity observed today does not directly change tomorrow's score. Exploitation data informs model training, not daily scoring. If recent exploitation directly drove scores, EPSS would unintentionally leak exploitation activity we do not have permission (or the license) to publish. The result is an epistemically honest model that does not assume we are seeing all of the exploitation activity. The goal is to identify vulnerabilities likely to be exploited before that evidence exists. Score changes from day to day reflect changes in threat intelligence signals such as exploit code availability, discussions, posts and chatter, reference volume and others, but not recent exploitation activity.
Access and data
Where do I get EPSS scores?
Via daily CSV download or the EPSS API. Both are free with no registration required. See Get the Data for endpoints, query parameters, response formats, and integration examples.
How do I get historical EPSS scores?
Historical daily score files are available in the archive. See Get the Data for the archive structure, date range, and access details.
How often are scores generated?
Daily. New scores are published each day covering every scored vulnerability, typically within a minute or two after 13:30 UTC daily.
Can EPSS score vulnerabilities without a CVE ID?
Work is underway to extend scoring to vulnerabilities with reserved but not yet published CVE IDs. Scoring vulnerabilities with no CVE ID at all is a longer-term direction. If you have a specific use case for this, reach out at epss-chairs@first.org.
Trust and operations
How can I trust EPSS?
EPSS is validated against empirical outcomes. The model trains on historical data and evaluates against held-out vulnerabilities over held-out time periods, meaning performance measurement covers cases the model never saw during training. The coverage, efficiency, and effort curves published on this site show measured performance with CVSS shown as a common baseline. The methodology is documented in peer-reviewed research. See Research for the published papers and full performance data.
How often is the model updated?
Model updates are driven by evidence of performance degradation, not a fixed calendar. EPSS continuously monitors the performance of scores published 30 days ago against the exploitation activity observed in the 30 days that followed. Sustained drift toward the random baseline triggers a retraining cycle. In practice, retraining has occurred approximately annually. In the CSV, the first line is a comment (starting with "#") and denotes the model the scores were produced under.
How much of the process is automated?
Daily scoring is fully automated. Feature collection, model execution, and score publication run without manual intervention. Model training and evaluation involve human oversight. Integrating new data sources is also a manual task but once the model is trained and data sources are integrated, EPSS is fully automated and runs without any human input or effort.
Can I look at the underlying data, model, or code?
The methodology is documented in the published papers and on the How It Works page. Several data partners share exploitation telemetry under agreements that prohibit redistribution, so the training data cannot be released. The operational pipeline (data collection, feature generation, model training, scoring infrastructure) is not published. Maintaining that as an open-source artifact would be a sustained engineering commitment that falls outside the scope of what EPSS is: a free public scoring service, not a research platform. The transparency that matters for evaluating EPSS is available: inputs are described, architecture is documented, and performance is measured against held-out data and published. If you have questions about the methodology, reach out at epss-chairs@first.org.
EPSS is maintained by the EPSS Special Interest Group at FIRST. Scores are generated by Empirical Security and published freely to the community.
