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

When low EPSS should not be treated as a “wait” signal

EPSS is useful for ranking likely exploitation, but it is not a reason to ignore stronger operational signals. When exposure is increasing, public exploit code appears, or the vulnerability is showing up in high-confidence external sources, the right first move is to test whether the issue is already becoming actionable in your environment.

That triage mindset matters because vulnerability management is really a timing problem as much as a scoring problem. A low probabilistic score can lag behind real-world attacker interest, so teams should look at what is changing around the CVE, not only at the score itself.

If you need a reference point for prioritisation logic, FIRST EPSS exists to estimate likelihood, while CISA’s Known Exploited Vulnerabilities Catalog is the stronger indicator that exploitation has already crossed into confirmed activity.

What “rising exploitability” usually means in practice

Exploitability signals often arrive before a vulnerability is broadly reflected in predictive scoring. Public proof-of-concept code, vendor advisories that narrow the blast radius, mentions in incident-response chatter, and inclusion in trusted exploit intelligence all suggest that the issue deserves re-evaluation immediately.

The practical question is whether the vulnerability is moving from theoretical to operational. Exposure context, such as internet-facing services, reachable management interfaces, or assets that sit near sensitive data and authentication paths, often matters more than the initial score when teams are deciding whether to escalate.

That is why teams should compare the CVE against authoritative context like the NIST National Vulnerability Database for affected products and against vendor advisories for product-specific exposure guidance. If exploitability is rising, those sources help determine whether the issue is actually reachable and whether compensating controls already exist.

What the first triage decision should settle

The first decision is not “is the score high enough?” It is “does the evidence now justify treating this as operationally real?” That means confirming whether the asset is exposed, whether public exploit code exists, and whether the vulnerability is appearing in high-confidence sources that indicate active or imminent use.

When those signals converge, the right response is to pull the issue into expedited review even if EPSS remains low. That may change remediation priority, validation depth, and stakeholder escalation, especially when the asset is externally reachable or tied to privileged workflows.

For teams needing a repeatable source of truth, the CVE Program provides the identifier and record structure that should be used to anchor internal triage, while the exploitation evidence should come from the stronger external signals around it.

Risk and Threat Considerations

Low EPSS can create a false sense of safety when exploit development is accelerating. The risk is that teams defer action until the predictive score catches up, by which point public tooling, exploit chaining, or active attacker interest may already have reduced the response window.

Failure mechanism: The control fails when prioritisation depends too heavily on a probabilistic score and too little on exposure, exploit availability, and corroborating intelligence. In that condition, a vulnerable asset can remain reachable long enough for exploitation to become routine rather than exceptional.

Impact: Exposure persists on systems that were incorrectly deprioritised, increasing the chance of compromise, emergency patching, and broader remediation pressure across similar assets.

Practitioner Guidance

What to prioritise: Start with an immediate exposure review, then check for public exploit code and corroborating high-confidence signals. If the asset is internet-facing or supports privileged access, treat that as a reason to escalate even when EPSS is still low.

Decision rule: If at least two of the three signals align, exposed asset, exploit code, or trusted external confirmation, move the CVE into accelerated triage rather than waiting for the score to change. If only EPSS is low and no other evidence is emerging, continue normal prioritisation.

What to verify: Confirm whether the affected service is reachable, whether compensating controls materially reduce exploitability, and whether the vulnerability appears in sources your team already uses for emergency action. The best outcome is a fast yes or no on operational reality, not a debate about score interpretation.

Practitioner takeaway: Use EPSS as one input, but let exposure and corroborating exploit evidence decide whether the vulnerability has become urgent.

Related resources from NHI Mgmt Group

• What should teams do first when a vulnerability was classified as low exploitability?
• What should teams do first when a JWT library vulnerability is disclosed but the exploitability looks uncertain?
• What should security teams do first when AI finds a code vulnerability but cannot prove exploitability?
• Why are NHIs a critical concern for security teams?