EPSS v5 is the current version of the Exploit Prediction Scoring System model maintained by FIRST, and it replaced v4 as the source of the published daily scores. FIRST’s data page states that EPSS v5 (v2026.06.15) “started publishing 2026-06-15.” A team using EPSS does not need to change how it pulls the data, but it should record the model version next to every stored score and re-check any threshold or historical comparison that crosses that date.
What EPSS measures
FIRST’s EPSS FAQ defines EPSS as “a data-driven model that estimates the probability a vulnerability will be exploited in the wild within the next 30 days.” Each scored CVE gets a value between 0 and 1, published daily, plus a percentile that ranks it against every other scored CVE.
The FAQ is precise about what is being predicted: the score 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.” It is a forecast of observed exploitation activity somewhere, not a statement about your environment. The FAQ says so directly: “EPSS is not a complete risk score.”
Version history
FIRST’s data page lists the model versions and the dates each began producing published scores:
- EPSS v1: “scores begin 2021-04-14”
- EPSS v2 (v2022.01.01): “started publishing 2022-02-04”
- EPSS v3 (v2023.03.01): “started publishing 2023-03-07”
- EPSS v4 (v2025.03.14): “started publishing 2025-03-17”
- EPSS v5 (v2026.06.15): “started publishing 2026-06-15”
From v2 onward, the daily files include a header comment line “stating the model version and publish date.” On cadence, the FAQ says model updates “are driven by evidence of performance degradation, not a fixed calendar,” and that “retraining has occurred approximately annually.”
What changed in v5
FIRST’s announcement is the authority on what changed, and it is brief. It lists the following changes:
- “General refresh (the performance slowly degrades over time)”
- “Updated exploit code detection on Github”
- “Improved calibration step”
- adding known-exploitation data from a third-party catalog (FIRST names the provider in its release)
- Added “Github Popularity Metrics,” which the announcement credits to outside research
- “Other minor tweaks, twists and turns”
For consumers, the announcement says: “If you are relying on EPSS Scores, nothing (except some scores) will change.” New scores “will be published in place of the previous algorithm’s output,” and “No change is required for any downstream consumers to get the updated scores!”
FIRST does not publish, on those pages, a feature-by-feature comparison or performance figures for v5 against v4. Anything beyond the list above is outside what FIRST has stated, and this article does not add to it.
How scores shift between versions
“Nothing (except some scores) will change” is the operational point. The data feed is the same; the numbers in it are not. The data page warns that “each model version produced a score shift on the date it started publishing,” and that “a time series that crosses one of these boundaries reflects a change in methodology, not a change in the vulnerability itself.”
A CVE whose score jumped between 2026-06-14 and 2026-06-15 may have gained no new exploit code, no new discussion, and no new evidence; the model may be the only thing that changed. If your records keep only the number, you cannot tell that apart from a real change in threat signals.
Day-to-day movement within one version is a different matter. The FAQ explains that “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).” Both kinds of change are legitimate; they need to be distinguishable in your records. Store three fields with every EPSS value: the probability, the score date, and the model version from the file header.
Probability versus percentile
The FAQ puts it simply: “The probability is an absolute measure; the percentile is a relative ranking.” Because most CVEs are never exploited, scores cluster near zero, and small probabilities rank high. The FAQ’s example: “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.”
The probability is the model’s primary output and can be used in quantitative work such as expected counts. The percentile depends on the whole scored population, so it moves when other CVEs’ scores move, including when the model version changes. Lead with the probability and show the percentile beside it as context.
Combining EPSS with KEV and asset context
EPSS forecasts; CISA’s Known Exploited Vulnerabilities catalog records. A CVE enters KEV when “There is reliable evidence that the vulnerability has been actively exploited in the wild,” among other criteria, and CISA advises that “Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework.” The EPSS FAQ is explicit about precedence: “If direct evidence of active exploitation exists, that evidence should supersede EPSS.” A low EPSS score on a KEV-listed CVE is not a contradiction; the two answer different questions.
Neither signal knows your assets. The FAQ notes EPSS “does not estimate impact, does not know what assets your organization runs, and does not account for compensating controls.” Reachability, business criticality and what actually runs on the host decide whether a finding on that asset moves up the queue. How to resolve conflicts between these signals is covered in When KEV, EPSS and asset context disagree.
Common mistakes
Treating EPSS as severity. EPSS estimates likelihood of observed exploitation activity, not the damage exploitation would cause. A low score on an internet-facing authentication service can still warrant fast action.
Thresholding without refresh. The FAQ is plain: “There is no universal threshold,” and a threshold of 0.10 “carries no special authority from EPSS.” A cutoff applied to scores pulled once and never refreshed is a decision made on stale data, and after 2026-06-15 possibly on a retired model.
Comparing scores across versions. A quarterly report that compares a v4 score from March with a v5 score from September is measuring two models. Either restrict the comparison to one version or label the boundary.
In practice
- Store the EPSS probability, percentile, score date and model version with each finding’s history; read the version from the file header rather than assuming it.
- Mark 2026-06-15 on any EPSS trend chart or metric, and do not attribute shifts across that date to changes in the vulnerability.
- Revisit EPSS thresholds against v5 scores and your actual remediation capacity, since FIRST sets no universal cutoff.
- Let a KEV match take precedence over the EPSS forecast, then apply asset context before setting urgency, and record why when a finding is resolved or risk accepted.
Sectie’s Exposure & Vulnerability Management product refreshes EPSS and CISA KEV data and shows them as reasons next to each priority.
