An EPSS score history can jump because the model was replaced, not because the vulnerability changed. FIRST says each model version shifted scores on the day it started publishing. If your chart crosses one of those dates, treat the step as a methodology break and compare only within a version.
What the version dates are
The EPSS data page lists the version history and the first publishing date of each. Here is the table, taken from that page.
| Version | Started publishing | How to spot it in the file |
|---|---|---|
| v1 | 2021-04-14 | No comment line at the top |
| v2 (v2022.01.01) | 2022-02-04 | Header comment with model version and date |
| v3 (v2023.03.01) | 2023-03-07 | Header comment |
| v4 (v2025.03.14) | 2025-03-17 | Header comment |
| v5 (v2026.06.15) | 2026-06-15 | Header comment |
The page notes that daily files from v2 onward start with a line beginning with a hash sign that names the model and publish date. That is the cheapest way to detect a boundary: read the first line of each daily file before you parse the rest.
Why a retrain shifts scores
EPSS is a calibrated probability. When the model is retrained, the features, the training window and the calibration are refit, so the same CVE can land at a different probability the next morning even if nothing happened in the world. FIRST's FAQ says retraining is driven by evidence of performance drift, and that in practice it has happened about once a year. So expect a step roughly annually, not a smooth drift.
Do not confuse this with the daily movement you see inside one version. Within a version the model is fixed, and scores move because new inputs arrive, such as exploit code or discussion. A retrain is a different cause with a different pattern: many CVEs shift at once on one date.
How to protect your analysis
- Pull the daily files from the public archive, which goes back to 2021-04-14.
- Record the model version from the header line next to each date in your table.
- Draw a vertical marker on any chart at each version start date.
- When you compare two dates, compare within the same version. If you must cross a boundary, say so in the caption.
- For alert rules such as "score rose by more than a set amount", suppress the alert on version start dates, or you will page someone for a methodology change.
A cheap sanity check helps. On a version start date, look at how many CVEs moved by a large amount. If it is a large share of the whole file, you are looking at a model change.
What this means for thresholds
If you set a fixed threshold, such as a probability you act on, a retrain can move the number of CVEs above it. Your queue can grow or shrink with no change in your estate. FIRST says there is no universal threshold and recommends tuning against your remediation capacity, so re-check the count above your line after each version change and adjust if your capacity has not changed. The percentile is relative to the whole scored population, so it can be steadier across a version boundary than a raw probability, but verify that on your own data instead of assuming it.
Safeguard's reachability analysis, SBOM and dependency scanning show which CVEs are present and reachable in your code, which keeps your queue grounded when an external score shifts. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a finding and look at which signals sit beside it, then note which of them are external scores that can shift under you.
Quick check
How often does the EPSS model change?
FIRST says updates are triggered by evidence of performance drift rather than a calendar, and that in practice retraining has happened about once a year. The data page lists five versions, the latest starting 2026-06-15.
Is a score jump after a version date a real change in risk?
Not on its own. It is a change in method. Check whether many CVEs moved on the same date. If so, compare within a version and do not alert on the step.
Sources
Last reviewed: 19 October 2026.
