EPSS Score: What It Predicts, How It's Calculated, and What It Misses

An EPSS score is the most widely misread number in vulnerability management. Teams treat it as a measure of danger. It is not. It is a weather forecast for one specific CVE, valid for about a month, describing the world rather than your product.

That distinction sounds academic until a regulator asks you to explain a triage decision you made eighteen months ago.

This is what the score actually measures, how the model produces it, how it compares to CVSS and the CISA KEV catalog, and the three things it cannot tell you about the firmware you shipped.

What Is an EPSS Score?

An EPSS score is a probability between 0 and 1 that a given CVE will have exploitation activity observed against it somewhere in the world during the next 30 days. It is published daily by the Forum of Incident Response and Security Teams (FIRST), free of charge, for every published CVE. A score of 0.82 means the model estimates an 82% chance of observed exploitation activity in that window.

Note what is absent from that definition: impact.

EPSS does not score severity, blast radius, or consequence. It scores likelihood and nothing else. A vulnerability that would hand an attacker root on a dialysis machine and a vulnerability that leaks a version banner can carry identical EPSS scores, because the model is answering a question about attacker behavior, not about damage.

One more piece of precision that matters more than it appears to. FIRST defines exploitation activity as evidence that exploitation was attempted, not that it succeeded against a vulnerable target. The data comes from honeypots, IDS and IPS sensors, and host-based detection contributed by data partners. A high EPSS score tells you attackers are probing. It does not tell you they are winning.

For product security teams at device manufacturers, that gap between attempted and successful is where most of the real work lives.

EPSS exists because of a volume problem. Organizations fix a fraction of their open vulnerabilities each month, and only a small minority of published CVEs ever attract exploitation activity at all. Sorting by severity treats a critical-rated flaw that nobody has ever attempted and a moderate-rated flaw with public exploit code as equivalent work. They are not.

One coverage limit to plan around: EPSS scores CVEs. Findings without a CVE identifier get no score, which for firmware analysis covers a meaningful share of what turns up, including hardcoded credentials, weak cryptographic configuration, and exposed debug interfaces. Any prioritization scheme built purely on EPSS will silently rank those at zero.

How Is an EPSS Score Calculated?

FIRST runs a five-step loop, refreshed daily: collect vulnerability information, collect evidence of daily exploitation activity, train a model on the relationship between the two, measure its performance, then publish fresh estimates for every published CVE.

The inputs fall into two buckets.

Vulnerability information includes CVE and NVD metadata, the CWE classification, the CVSS vector, references and their sources, the age of the vulnerability, whether exploit code exists in Exploit-DB or Metasploit, and whether proof-of-concept code has been published to sites like GitHub.

Exploitation activity is the ground truth signal: telemetry from data partners showing attempts observed in the wild, with precise timestamps.

Timing is not a detail in this design, it is the design. FIRST is deliberate about recording when every event occurred, because the model needs to measure what happened to exploitation activity before and after a Metasploit module landed or a proof of concept was published. This is also why CISA KEV and Google Project Zero are treated as vulnerability information rather than exploitation activity. Appearing on a list is a single past event, and EPSS is always looking at the next 30 days.

The model itself is a gradient-boosted decision tree trained on 12 months of historical data. Version 4 works from roughly 1,500 features.

Version 4 has been live since March 2025. It is worth checking what your sources are citing, because several of the most-linked EPSS explainers still describe the v3 model, and at least one still states that the most recent update happened in March 2023.

Scores are published two ways: a public API and a daily CSV covering every scored CVE, both free from FIRST. Most vulnerability management and product security platforms ingest the feed, so the score usually arrives attached to the finding.

A newly published CVE will not have a score immediately, and the first scores it receives are the least informed the model will ever be about it. Early estimates lean heavily on metadata such as the vendor, the CWE class, and the reference set, because no exploitation telemetry exists yet. That is exactly the window in which a disclosure lands on your desk and a triage decision is due, which is worth remembering before treating day-one scores as settled.

Probability vs. Percentile: Reading the Two Numbers

FIRST publishes two numbers per CVE, and conflating them produces bad triage.

The probability is the model's estimate: 0 to 1, exploitation activity in the next 30 days. The percentile is a ranking: the share of all scored CVEs that have a lower EPSS score than this one.

Percentile says nothing about severity. A CVE in the 95th percentile is not "more severe than 95% of vulnerabilities." It has a higher exploitation probability than 95% of them, which is a different claim entirely.

The distinction bites because the distribution is heavily bottom-weighted. Most CVEs score near zero. That compression means a respectable-looking percentile can sit on top of a very small absolute probability, and a team sorting by percentile alone will promote vulnerabilities the model considers unlikely.

Three real examples show the range:

• CVE-2021-44228 (Log4Shell): CVSS 10, EPSS 0.974, 99.9th percentile. Severe and near-certain to be attacked. Both signals agree.
• CVE-2020-13956 (Apache HttpClient): CVSS 5.3, EPSS 0.22, 96th percentile. Middling severity, roughly one-in-five odds of exploitation activity. The CVSS score alone would have buried it.
• CVE-2019-17531: CVSS 9.8, EPSS 0.008, 80th percentile. Critical severity, effectively no predicted exploitation. This is the quadrant where teams burn their remediation budget.

Read both numbers, and record both. The score you acted on will not be the score anyone sees later.

EPSS vs. CVSS: What Each One Actually Measures

CVSS and EPSS get framed as rivals. They answer different questions and a serious program uses three signals, not two.

One correction to the standard shorthand. CVSS is often described as a static score, and that is only true of the Base metrics. CVSS also defines Threat and Environmental metric groups that adjust the score for exploit maturity and for the deployment context, and almost nobody populates them. The staleness of most CVSS scores is a workflow problem, not a property of the standard.

Crossing the two produces four quadrants, and only three of them are interesting.

High severity with high likelihood is the obvious priority. Low severity with low likelihood is the obvious deferral. The two mixed quadrants are where the judgment happens. High CVSS with low EPSS is the largest and most expensive group, the critical-rated vulnerabilities that attackers have shown no interest in. Low CVSS with high EPSS is the smallest and most frequently missed, moderate-rated flaws with public exploit code that a severity-only policy never surfaces.

KEV overrides the grid entirely. Confirmed exploitation is not a probability question, and a listed CVE that is present in your product does not need a prediction to justify action.

The useful framing is multiplication rather than comparison. Severity tells you what is at stake. Likelihood tells you the odds. Neither is specific to your product, which is the constraint that shapes everything downstream.

Setting an EPSS Threshold: Effort, Efficiency, and Coverage

Search for guidance on EPSS thresholds and you will find confident recommendations to act above 0.5, or 0.75, calibrated to your risk appetite.

FIRST has never published a threshold, and says so directly: there is no universal "critical" or "high" that the community could agree on. Any vendor telling you which number to use is stating a preference and dressing it as a standard.

What FIRST does publish is the math to derive your own. Three metrics, measured against a chosen cutoff:

• Effort: the share of all vulnerabilities your strategy flags for action. This is your staffing bill.
• Efficiency (precision): the share of flagged vulnerabilities that actually saw exploitation. TP divided by (TP + FP).
• Coverage (recall): the share of exploited vulnerabilities that your strategy flagged. TP divided by (TP + FN).

Run those against the two most common strategies and the difference is stark. Prioritizing everything at CVSS 7 and above produces effort of 57.4%, coverage of 82.2%, and efficiency of 3.96%. Prioritizing at EPSS 0.1 and above produces effort of 2.7%, coverage of 63.2%, and efficiency of 65.2%.

Read that trade honestly. The EPSS strategy is sixteen times more efficient and demands a twentieth of the effort, and it misses more exploited vulnerabilities than the CVSS strategy does. You are buying a large reduction in wasted work with a real reduction in coverage.

Whether that is a good trade depends on a number you probably already know. Research by Cyentia and Kenna Security found most organizations remediate 10% to 15% of their open vulnerabilities per month. A strategy demanding 57.4% effort is not a strategy. It is a backlog with a scoring system attached.

Pick your threshold by deciding what coverage you can defend losing, then read the effort and efficiency that come with it. Write down the reasoning. Under the CRA, the threshold is not an internal preference. It is a documented risk decision you may have to explain.

Where EPSS Falls Short

Four limitations, and the first one is not widely known.

EPSS is blind to the past. In NIST Cybersecurity White Paper 41, published 19 May 2025, Peter Mell of NIST and Jonathan Spring of CISA document that EPSS was designed not to take prior exploitation as a model input. The consequence is inaccurate scores for vulnerabilities that have already been exploited. Their proposed Likely Exploited Vulnerabilities (LEV) metric exists specifically to correct this, by compounding a CVE's historical EPSS time series into a cumulative probability that it has been exploited at some point.

Scores spike and fall back. Direct observation of historical EPSS data shows scores can jump for one or two days and then return to a low baseline. If you triaged a CVE by pulling its score once, and you look again six months later, you may see a calm number attached to a vulnerability that was briefly on fire. Your documented decision looks better than the evidence supported. This is an argument for storing the score and the date, not just the verdict.

The empirical ceiling is lower than the marketing. In a study presented at ACM CCS 2025, Koscinski and colleagues examined 600 real-world vulnerabilities drawn from four months of Microsoft Patch Tuesday disclosures. Of the CVEs that later appeared in the CISA KEV catalog, fewer than 20% had ever been scored above 0.5 by EPSS at any point beforehand. Only 8.3% ever exceeded 0.9. And 275 of them, 22.4%, had no EPSS score at all prior to known exploitation.

The score is global by design. EPSS describes exploitation activity against a CVE somewhere in the world. It has no knowledge of whether the vulnerable component is in your build, whether the vulnerable function is reachable, or whether the affected interface is exposed on your device.

One factual correction while we are here, because it circulates widely: the EPSS model is not proprietary. FIRST publishes the model design, the peer-reviewed research behind each version, the performance measurements, and the daily scores themselves.

EPSS Under the CRA: A Prediction Is Not Evidence

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, is built on risk-based decisions rather than exhaustive remediation. Annex I Part II point 2 requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed. The Part I product requirements apply on the basis of the cybersecurity risk assessment in Article 13(2). And Part I point 2(a) requires products to be placed on the market without known exploitable vulnerabilities, not without known vulnerabilities.

Those three words carry the weight. The CRA does not prescribe an assessment methodology. It expects a defensible judgment, documented well enough that a regulator, auditor, or customer can follow your reasoning later.

Which makes the next distinction the one to get right.

From 11 September 2026, Article 14 requires manufacturers to report any actively exploited vulnerability in their product. Actively exploited means there is reliable evidence that a malicious actor has exploited it in a system without authorization. That is a backward-looking evidentiary test.

EPSS is a forward-looking prediction. The two are not interchangeable:

• An EPSS score of 0.97 is not evidence of active exploitation, and does not trigger a filing obligation.
• An EPSS score of 0.01 is not a defense if reliable evidence of exploitation exists.

The reporting cascade runs on a tight clock: an early warning to ENISA and the coordinating CSIRT within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available. Reports go through the ENISA Single Reporting Platform established under Article 16. Under Article 69(3), the obligation covers products already made available on the EU market, not just new releases. Article 64 sets penalties at up to €15 million or 2.5% of worldwide annual turnover.

EPSS earns its place in that program as a prioritization input for what to fix first. It is not the trigger. For how this plays out in a live triage decision, see our walkthrough on EPSS and CRA triage.

The Variable EPSS Cannot See: Reachability in What You Shipped

Take a CVE with an EPSS score of 0.9 in a library that your firmware links but never calls. Or one in a component your build configuration compiles out entirely. The score is accurate. The vulnerability is unreachable in your product.

Remediating it does not make the device safer. It consumes engineering time that a genuinely reachable issue needed.

This is the structural limit of every global scoring system. CVSS scores the vulnerability. EPSS scores the vulnerability. Neither has ever seen your build.

For connected device manufacturers, the gap is wider than it is in cloud environments, for a reason that has nothing to do with tooling maturity. Firmware routinely contains components introduced by a contract manufacturer, an SDK vendor, or a chipset supplier. The build manifest, when one exists, describes what was meant to be included. The binary describes what shipped. Those two disagree more often than anyone is comfortable with, and if you do not hold the source, the manifest is the only story you have.

Binary analysis closes that gap by reading the artifact itself. We analyze the compiled firmware to establish which components are actually present, then apply reachability analysis to determine whether the vulnerable function can be reached along a call path, without needing the original source code.

That produces the third variable. Severity, likelihood, and presence in the shipped artifact. Two of those come free from public feeds. The third is the one that makes a triage decision specific to your product, and it is the one a regulator will ask about.

A Triage Sequence That Holds Up in an Audit

Most teams apply EPSS first because it is the easiest signal to obtain. Apply it late instead, and the queue gets shorter at every step before it.

1. Establish what shipped. Component inventory derived from the binary for the specific firmware version in the field. Annex I Part II point 1 requires an SBOM covering at minimum the top-level dependencies, and top-level is the floor, not the ceiling.
2. Filter by presence. Drop CVEs for components that are not in this build. This is usually the largest single reduction.
3. Check reachability. For components that are present, determine whether the vulnerable function sits on a reachable call path. Record the determination and the evidence.
4. Apply KEV. Confirmed exploitation outranks predicted exploitation. If a reachable CVE is in the KEV catalog, it moves to the top.
5. Apply EPSS, and consider LEV. Rank the remaining reachable findings by exploitation probability. Where a decision is consequential, check the EPSS history rather than a single day's value.
6. Layer severity and exposure last. CVSS, network reachability of the affected interface, and deployment context break the remaining ties.

Two record-keeping habits make the difference between a decision and a defensible decision. Store the EPSS score with its date, because the value will move and the reasoning has to be reconstructable. And document the negatives: a CVE you set aside as unreachable needs the evidence attached, since "we assessed it as not applicable" without support is the weakest sentence in any audit response.

If you want to see what risk-based vulnerability decisions look like against your own firmware, request a CRA consultation and we will walk your team through it.

FAQ

What is a good EPSS score?

There is no official threshold. FIRST has deliberately never published one, because the right cutoff is a statement of risk tolerance rather than a technical fact. Derive yours from effort, efficiency, and coverage: an EPSS cutoff of 0.1 flags roughly 2.7% of vulnerabilities and catches about 63% of exploited ones. Lower the cutoff for more coverage at higher cost.

Is a high EPSS score the same as being on the CISA KEV list?

No, and the difference is directional. KEV is a record of confirmed past exploitation. EPSS is a prediction about the next 30 days. A CVE can carry a high EPSS score without ever reaching KEV, and research presented at ACM CCS 2025 found that 22.4% of CVEs later added to KEV had no EPSS score at all beforehand.

How often do EPSS scores change?

Daily. FIRST regenerates estimates for every published CVE each day as new telemetry arrives. Scores can also spike sharply for one or two days and then fall back to baseline, so a single point-in-time reading is a weak basis for a decision you may need to defend later.

Can EPSS replace CVSS?

No. They measure different things. CVSS estimates severity if a vulnerability is exploited; EPSS estimates the likelihood of exploitation activity. Neither knows whether the vulnerable code is present or reachable in your product. Use them together, and add reachability for the product-specific answer.

Does a high EPSS score mean I have to report under the CRA?

No. Article 14 requires reporting of actively exploited vulnerabilities, meaning reliable evidence that a malicious actor has exploited the vulnerability in a system without authorization. EPSS is a prediction, not evidence. A score of 0.97 does not trigger the obligation, and a low score does not excuse it when evidence of exploitation exists.

Where do I get EPSS scores?

FIRST publishes them free at first.org/epss through a public API and a daily CSV download covering every scored CVE. Most vulnerability management and product security platforms ingest the feed automatically, so scores usually arrive alongside findings rather than requiring a separate lookup.