How does Likely Exploited Vulnerabilities (LEV) work?

Likely Exploited Vulnerabilities (LEV) is a prioritisation approach that ranks vulnerabilities by the likelihood they are already being exploited in the wild. Teams use it to focus patching and compensating controls on issues with active abuse signals, rather than treating all exposure as equal. It works best when combined with asset context and threat intelligence.

How LEV turns vulnerability queues into a prioritisation signal

LEV is not trying to score every flaw equally. It is a triage method that treats evidence of real-world exploitation as a stronger signal than theoretical exposure, so the queue moves toward vulnerabilities that are more likely to be used against you now. That makes it most useful when patch capacity is limited and the backlog is large.

The practical value is that LEV shifts the question from “what exists?” to “what is most likely to be hit first?” That is why it works best when you combine it with asset criticality, internet exposure, and threat intelligence, rather than using it as a standalone ranking rule.

LEV also sits naturally beside Vulnerability Management Guide, because the method only helps when it is embedded in an actual remediation workflow with scan coverage, exception handling, and validation of fix completion.

What signals LEV uses, and what it does not

LEV is driven by indicators that a vulnerability is already being abused in the wild, such as active exploitation reporting, credible threat-intelligence sightings, or inclusion in exploited-vulnerability tracking. It does not depend on a flaw being severe in the abstract, and it does not require you to wait for a vendor score to decide what to fix first.

That distinction matters because severity and exploit likelihood are different questions. A high-severity issue may be low priority if there is no sign of exploitation and limited reach, while a lower-severity issue can become urgent if attackers are already using it at scale or if it sits on a highly exposed asset.

LEV is therefore a prioritisation layer, not a vulnerability description. It tells teams where to focus attention first, but it does not replace patch validation, compensating controls, or asset-scoped remediation decisions.

How teams apply LEV in practice

Teams usually apply LEV by sorting vulnerable findings into a response order that combines exploitation likelihood with business context. A flaw on a public-facing, high-value system will usually rise above the same flaw on a segmented lab host, even if both share the same technical issue.

In mature programmes, LEV is paired with action thresholds. An exploited flaw may trigger emergency patching, temporary isolation, WAF or IPS rules, tighter monitoring, or a documented exception only when patching cannot happen immediately.

LEV also benefits from external reference points such as CISA Known Exploited Vulnerabilities Catalog and FIRST EPSS, because those sources help separate “likely to be exploited” from “merely present in the environment.”

Risk and Threat Considerations

LEV reduces exposure only if the organisation can act on the signal quickly. The main risk is false reassurance, where teams assume a low-LEV item is safe to defer indefinitely, or over-focus on a single exploited flaw while ignoring a broader attack path created by weak segmentation, poor asset inventory, or missing compensating controls.

Failure mechanism: Attackers gain time advantage when exploited vulnerabilities remain unpatched, especially on reachable assets or internet-facing services. LEV can also be distorted by incomplete telemetry, so an organisation may miss exploitation signals on systems it does not monitor well.

Impact: The result is avoidable compromise, faster attacker dwell time, and a remediation queue that no longer reflects current threat reality. In the worst case, the team patches what is easiest to see instead of what is most likely to be used next.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	LEV is a vulnerability prioritisation method that depends on continuous finding-to-remediation handling.
Recommendation — Prioritise exploited vulnerabilities first and track remediation to closure.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	LEV changes how vulnerability risk is prioritised based on exploitation likelihood.
	ID.RA-05 — Threats, Vulnerabilities, and Risks are Used to Understand Risk	LEV relies on threat intelligence and exploitation evidence to rank vulnerabilities.
Recommendation — Incorporate exploitation likelihood into your vulnerability risk strategy. Combine exploit intelligence with asset context when ranking vulnerabilities.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	LEV is used in vulnerability management workflows that require monitoring and prioritisation.
Recommendation — Use vulnerability monitoring outputs to drive exploit-likelihood triage.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Exploit-driven prioritisation often overlaps with secret exposure and active abuse risk.
Recommendation — Prioritise leaked secrets that are already being exploited or exposed.

Practitioner Guidance

What to verify: Treat LEV as useful only when it is backed by decent asset context. If the vulnerability is not mapped to ownership, internet exposure, and patch status, the ranking may be directionally right but operationally weak.

Decision rule: If a finding has credible exploitation evidence, move it ahead of non-exploited issues unless a stronger business-critical dependency exists. If patching must wait, apply a compensating control and record the exception with an expiry date.

What practitioners underestimate: LEV is strongest when it changes action, not when it changes reporting. A dashboard score that does not alter remediation order, mitigation, or escalation is only a metric, not a control.

Practitioner takeaway: Use LEV to compress decision time on the vulnerabilities that matter most right now, but always anchor the ranking in real asset exposure and a concrete remediation path.