Patch queues become detached from real attacker activity. A low EPSS score can still hide active exploitation, public proof-of-concept code and exposed services that attackers can automate immediately. Teams then spend scarce remediation effort on predicted risk while the most reachable systems remain open to unauthenticated abuse.
Why EPSS-only prioritisation drifts away from real exploitation
EPSS is useful for estimating which vulnerabilities are more likely to be exploited, but it is still a prediction model, not a live view of attacker activity. Once teams treat it as the primary queueing signal, they can miss the difference between statistical likelihood and evidence that an issue is already being used against exposed systems.
That gap matters because remediation capacity is finite. If the queue is driven mainly by predicted probability, low-scored issues with current exploitation pressure can be left open while higher-scored but less reachable issues consume attention. For vulnerability management teams, the right question is not only “what is likely?” but also “what is being abused right now?”
What changes when live telemetry is missing
Live exploit telemetry adds context that scoring alone cannot provide: active exploitation in the wild, proof-of-concept availability, public scanning, and observable targeting of exposed services. Those signals change urgency because they tell you whether an issue is already part of attacker tradecraft rather than merely a future candidate for abuse.
Without that context, prioritisation can become detached from exposure. A vulnerability on an internet-facing system with unauthenticated reachability may deserve faster action than a more probable but harder-to-reach issue, especially when adversaries can automate discovery and exploitation at scale. This is why the Vulnerability Management Guide treats EPSS as one input among several, not as a substitute for reachability, KEV status or remediation workflow design.
Teams also need to distinguish between vulnerability volume and vulnerability urgency. A large backlog can make EPSS feel efficient because it provides a neat ranking, but a ranked list is only useful if it is continuously reconciled against exploit intelligence, asset criticality and service exposure.
Why exploit intelligence should override prediction when the signals conflict
When exploit telemetry and EPSS disagree, live evidence should usually win. If a vulnerability is being actively exploited, that is a stronger operational signal than a model score that reflects historical patterns across many environments. The difference is practical, not academic: attackers do not need a high prediction score to attack what is reachable and already weaponised.
This is especially true for widely exposed services, where unauthenticated abuse can begin as soon as working exploit code appears. The Zero-Day and Exploited Vulnerabilities Guide focuses on exactly this problem: when exploitation is current, response should shift from theoretical ranking to emergency mitigation, verification and hunt activity.
EPSS still has value for scale, but it should be used as a triage accelerator, not as a gate that blocks attention to confirmed exploitation. If you only fund the top of the probability list, you risk creating a blind spot around “low score, high harm” issues that are already attracting attacker automation.
Where prioritisation should change in practice
Teams get better outcomes when they combine scoring with exposure and evidence of abuse. That means feeding vulnerability data, asset exposure, web-facing reachability and exploitation observations into the same decision loop so the queue reflects both probability and immediacy.
The Application Security Posture Management (ASPM) Guide is relevant here because correlation and deduplication only help if the resulting backlog still preserves reachability and business context. If a finding is duplicated across tools but appears on an exposed service with exploit activity, it should rise, not disappear into a de-duplicated aggregate score.
In practice, the strongest remediation queues tend to be the ones that can answer three questions together: can it be reached, is it being abused, and what is the blast radius if it is compromised? That combination is far more actionable than a score taken in isolation.
Risk and Threat Considerations
Relying on EPSS alone creates a control gap because it can underweight the exact conditions attackers exploit first: public reachability, available exploit code and unauthenticated access paths. That turns remediation into a probability exercise while real-world abuse continues against the systems that are easiest to touch.
Failure mechanism: Prediction-driven queues optimise for estimated exploit likelihood, but they do not reliably surface active exploitation, so exposed assets with live attack pressure remain open longer than they should.
Impact: Teams spend scarce patching capacity on the wrong population, increasing the chance of straightforward compromise, rapid automation-based abuse and avoidable incident response work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | EPSS vs live exploit telemetry is a prioritization problem in vulnerability management. |
| Recommendation — Prioritise exposed, actively exploited vulnerabilities ahead of predicted-only risk. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | The topic is about how vulnerability risk is assessed and prioritised. |
| PR.IP-12 — A vulnerability management plan is developed and implemented | The question concerns how patch queues should be driven and maintained. | |
| DE.CM-08 — Vulnerability scans are performed to find vulnerabilities | Scans and exposure data inform the queue that EPSS alone cannot replace. | |
| Recommendation — Use vulnerability evidence and exploit signals to rank remediation urgency. Build a remediation workflow that incorporates live exploitation intelligence. Combine scanning outputs with telemetry to avoid relying on prediction alone. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Exposed services and unauthenticated abuse often hinge on insecure exposure states. |
| Recommendation — Harden exposed services that become easy targets when exploitation is active. | ||
Practitioner Guidance
What to verify: Confirm that your prioritisation process checks for active exploitation signals before finalising the patch queue. If a vulnerability has public proof-of-concept code or is on an internet-facing service, do not let a low EPSS score suppress escalation.
Decision rule: If EPSS and live telemetry conflict, treat live exploitation, KEV inclusion and observed scanning as the stronger operational signal. Use prediction to sort the backlog, not to override evidence of current abuse.
What practitioners underestimate: The biggest error is assuming low-score issues are safe to defer when they are actually the easiest to automate. In vulnerability operations, reachability and current attacker behaviour usually matter more than the elegance of the model.
Practitioner takeaway: EPSS is a useful predictor, but only live exploit telemetry tells you whether a vulnerability has already crossed from theoretical risk into active exposure.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on periodic log reviews instead of live telemetry?
- What breaks when teams rely on seat counts instead of agent telemetry?
- What breaks when security teams rely only on static findings instead of exploit proof?
- What breaks when identity teams rely on theory-heavy training instead of live environment practice?