EPSS is a lagging signal, not an early warning for CVE risk

At a glance

What this is: Nucleus found that EPSS often behaves as a lagging indicator of confirmed exploitation rather than a reliable early-warning signal for CVE risk.

Why it matters: For vulnerability and exposure management teams, that means EPSS should inform prioritisation only after upstream exploitability signals are already in play, not as a standalone trigger.

By the numbers:

• Nucleus research covered 22 of the 122 CVEs added to the CISA KEV catalog between October 2025 and March 2026.
• The median EPSS movement was 121 times larger after KEV listing than before.
• The KEV+2 mark alone accounts for 54% of all absolute EPSS change across six months of KEV additions.
• The first three days after KEV listing account for 89% of all post-KEV movement.

Context

EPSS is a vulnerability prioritisation signal, not a guarantee of imminent exploitation. Security teams often want a single score that helps them cut through CVE volume, but a probabilistic model can still arrive after the risk has already become operationally real.

The governance problem is timing: if a team treats EPSS as an early-warning control, it may defer remediation until the ecosystem has already confirmed exploitation. For vulnerability management, the identity angle is indirect but real in the NHI sense because exposed services, API endpoints, and machine-accessible assets are often the first things attacked once a CVE becomes usable.

Nucleus frames this as a signal-quality problem rather than a scoring problem. That is typical of modern vulnerability operations, where teams have plenty of data but still struggle to decide which signal deserves first action.

Key questions

Q: Why is EPSS not a reliable early-warning signal for CVE risk?

A: EPSS is a predictive ranking model, but it often rises after the exploitability picture is already visible through other signals such as PoC release, weaponisation, and KEV listing. That makes it useful for prioritisation, not for first detection. Teams should treat it as one input in a layered decision process, not as the trigger that starts remediation.

Q: What should vulnerability teams do first when EPSS is low but exploitability signals are rising?

A: Start with an immediate triage review of the asset’s exposure, whether public exploit code exists, and whether the CVE appears in other high-confidence sources such as KEV or vendor advisories. Low EPSS should not delay action if upstream evidence is already converging. The first decision is whether the issue is becoming operationally real, not whether the score has caught up.

Q: What breaks when vulnerability prioritisation relies on exploitability scores alone?

A: Prioritisation breaks when scores are treated as confirmation rather than signals. AI can accelerate proof-of-concept generation, so a vulnerability may become actionable faster than a manual review can keep up. Teams then over-escalate noise, under-weight real exposure, and lose the ability to distinguish urgent fixes from theoretical ones.

Q: How do you know if vulnerability prioritisation is working?

A: You should see fewer blocking tickets, faster remediation on exploitable issues, and better alignment between security work and business risk. If developers are constantly interrupted by findings that never matter, the model is still severity-led. A good programme can explain why some issues are deferred without losing auditability.

Technical breakdown

Why EPSS can lag confirmed exploitation

EPSS is a predictive model that estimates the likelihood of exploitation, typically within a 30-day window, based on observed data patterns. The key limitation is that prediction does not equal anticipation. If the underlying telemetry only becomes strong once public proof-of-concept code, media attention, exploit development, and vendor advisories converge, the score can rise after exploitation is already underway. In that sense, EPSS is often sensitive to ecosystem attention rather than to the first actionable sign of attackability. That makes it useful as one input to prioritisation, but weak as a standalone trigger for proactive remediation.

Practical implication: Treat EPSS as a ranking input, not the first signal that authorises patching work.

Why KEV and EPSS often move at different times

CISA’s Known Exploited Vulnerabilities catalog marks public confirmation of active exploitation, which is a later lifecycle point than initial attacker interest. Nucleus’ finding that EPSS moves most strongly after KEV listing shows the model is frequently reacting to a risk already validated elsewhere. The 72-hour concentration of movement after listing suggests the score is catching up to the market conversation, not leading it. For vulnerability teams, that difference matters because a score can be statistically accurate and still operationally late. The model answers how likely exploitation is, not when defenders should first assume exposure has become urgent.

Practical implication: Build prioritisation around upstream exploitability evidence, then use EPSS to refine queue order.

What an exploitability intelligence gap looks like in practice

The exploitability intelligence gap is the window between when a CVE becomes realistically exploitable and when downstream scoring systems fully reflect that change. During that gap, defenders may wait for a numeric threshold while attackers act on public proof-of-concept code, weaponisation activity, or broad community attention. HPE OneView is the exception that proves the rule because multiple signals aligned before KEV inclusion, which pushed EPSS up early. Most vulnerabilities do not enjoy that attention profile. The operational lesson is that teams need a layered prioritisation stack that fuses exploitability indicators, not a single scalar score.

Practical implication: Use layered signal correlation so urgent vulnerabilities are not hidden behind a slow-moving score.

NHI Mgmt Group analysis

EPSS is better understood as a confirmation signal than an early-warning signal. Nucleus’ finding matters because security teams routinely use predictive scores as if they were trigger points for first response. That creates false confidence in a number that may only rise once exploitation has already entered the public record. For vulnerability governance, the practical conclusion is simple: model outputs should support prioritisation, not define it.

The real control failure is over-trust in single-signal decisioning. EPSS can be directionally useful while still arriving too late for the remediation decision that mattered most. When teams collapse exploitability, exposure, and confirmation into one score, they lose the ability to separate early evidence from downstream validation. The broader lesson for exposure management is that signal quality and signal timing are different governance problems.

Exploitability intelligence needs to be assembled, not awaited. The article shows why public PoC, weaponisation activity, vendor advisories, and community attention matter before a score threshold does. That is a programme design issue, not a tooling issue. Teams should treat vulnerability triage as a multi-input decision workflow, with human judgment still governing the first escalation.

Machine-accessible services face the sharpest consequence of this timing gap. Once a CVE becomes exploitable, internet-facing systems, API endpoints, and service credentials are often the fastest path to impact. In NHI terms, that means exposed machine identities and service-linked access paths become high-value targets before lagging prioritisation signals catch up. Practitioners should assume exploitability turns into identity-relevant risk very quickly.

From our research library:

• The median time to fully patch a vulnerability in CISA's Known Exploited Vulnerabilities catalog rose to 43 days, according to Verizon's 2026 Data Breach Investigations Report.

What this signals

Exploitability timing should become a governance metric, not just a scoring curiosity. If an organisation consistently waits for lagging indicators, its vulnerability programme is optimised for validation rather than prevention. That is a structural issue in exposure management, and it is especially dangerous for internet-facing assets and machine-accessible services.

Layered prioritisation is the only defensible response to signal lag. Teams should combine exploit intelligence, exposure context, and operational criticality so a slow score cannot stall an urgent patch decision. The practical goal is to make one late indicator unable to override several earlier ones.

For practitioners

• Combine EPSS with upstream exploitability signals Use public proof-of-concept availability, vendor advisories, weaponisation activity, and KEV status together rather than waiting on a score threshold alone.
• Create a two-stage triage model Separate initial risk detection from final prioritisation so the first review happens when evidence appears, not when the score peaks.
• Prioritise internet-facing and machine-accessible assets first Treat exposed services, APIs, and service-account-backed workloads as the highest-consequence targets when exploitability indicators begin to align.
• Review escalation thresholds for lagging indicators Set internal rules that force action when multiple upstream signals converge, even if EPSS has not yet crossed the usual cutoff.

Key takeaways

• EPSS can support vulnerability prioritisation, but this article shows it often reflects confirmed exploitation after the fact rather than warning teams in advance.
• The evidence pattern is concentrated after KEV listing, which means organisations that wait for score movement are likely to lose time in the window that matters most.
• The right control response is layered exploitability triage, where upstream signals and asset exposure drive first action and EPSS is used as supporting context.

Key terms

• EPSS: The Exploit Prediction Scoring System estimates the likelihood that a vulnerability will be exploited in the wild. It is useful for prioritisation because it reflects observed threat patterns, but it still needs local identity context such as privilege scope, secret exposure, and reachability.
• Exploited vulnerability catalog: An exploited vulnerability catalog is a curated list of flaws known to be used in real attacks. It matters because active exploitation changes priority. In practice, it helps security teams separate theoretical risk from issues that require urgent remediation and tighter operational oversight.
• Exploit Intelligence: Actionable information about which vulnerabilities are being actively targeted, how attackers are delivering them, and where exploitation is emerging. It turns vulnerability management from static inventory tracking into a dynamic response process that reflects live adversary behaviour.
• Vulnerability Management Prioritization: Vulnerability management prioritization is the operational method for deciding which vulnerabilities enter the remediation queue first. It turns a large and changing set of findings into a ranked plan based on risk, exposure, and impact. Effective programmes use context about assets and systems, not just scan scores, to guide action.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect access control, secrets management, and governance decisions across modern identity programmes.