Executive Summary

 

Most vulnerability remediation programmes still prioritise patching based on CVSS severity ratings. However, severity alone does not indicate which vulnerabilities attackers are most likely to exploit.

 

CVSS measures theoretical impact under defined conditions. EPSS estimates real-world exploitation probability.[1][2]

 

As annual CVE volume continues to rise, organisations face a prioritisation overload problem: a growing number of vulnerabilities are classified as High or Critical, while remediation capacity remains limited.[3]

 

The result is a structural mismatch. Security teams spend effort patching vulnerabilities unlikely to be exploited, while adversaries focus on a much smaller subset of actively targeted flaws.

 

Effective vulnerability management requires combining

🔸 CVSS severity

🔸 EPSS exploitation probability

🔸 CISA KEV intelligence

🔸 asset criticality

🔸 exposure context

 

Threat Overview: Where CVSS Alone Falls Short

 

CVSS (Common Vulnerability Scoring System) provides standardised severity ratings from 0–10.

 

It is designed to answer:

🔸 If exploited successfully, how severe could impact be?

 

This differs fundamentally from:

🔸 How likely is exploitation in the real world?

 

A CVSS base score does not automatically change when:

🔸 proof-of-concept exploit code is released,

🔸 ransomware groups adopt a vulnerability,

🔸 exploitation campaigns begin at scale.[4]

 

This creates a major operational limitation.

 

A CVE scored Medium may become actively exploited within days, while many Critical vulnerabilities never experience meaningful attacker interest. In 2024, the National Vulnerability Database recorded more than 40,000 published CVEs, continuing the multi-year acceleration trend.[3]. For most teams, patching every High/Critical CVE within compliance windows is no longer realistic.

 

EPSS - Exploitation Probability as a Prioritisation Signal

 

EPSS (Exploit Prediction Scoring System), maintained by FIRST, estimates the likelihood that a CVE will be exploited within 30 days.[1]

 

Scores range from:

🔸 0.0 = very low probability

🔸 1.0 = very high probability

 

Unlike CVSS, EPSS updates daily.

 

The model evaluates over 1,100 signals, including:

🔸 exploit publication activity

🔸 attacker behaviour patterns

🔸 vulnerability age

🔸 software prevalence

🔸 historical exploitation data.[2]

 

EPSS answers:

🔸 Which vulnerabilities should we expect attackers to target next?

 

EPSS provides value for:

🔸 remediation triage

🔸 patch SLA tuning

🔸 threat-led prioritisation queues

 

Efficiency vs Coverage: Understanding the Trade-Off

 

EPSS improves prioritisation by helping teams focus remediation effort on vulnerabilities that are more likely to be exploited, however, this introduces an important operational trade-off between efficiency and coverage.

 

🔸Efficiency = how much of your remediation effort is spent on vulnerabilities that attackers actually exploit

🔸Coverage = how many of the eventually exploited vulnerabilities you successfully remediate

 

In operational terms:

🔸Higher EPSS thresholds
     → fewer vulnerabilities are prioritised
     → remediation effort becomes more focused
     → but some exploitable vulnerabilities may be missed

🔸Lower EPSS thresholds
     → more vulnerabilities are included
     → greater chance of covering all exploitable issues
     → but with increased remediation workload

 

This reflects a real-world constraint:  "security teams cannot remediate everything, they must decide where to focus limited capacity".

 

 There is no universal “correct” EPSS threshold. Effective use depends on:

🔸 organisational risk tolerance
🔸 available remediation capacity
🔸 criticality of affected systems

 

For example:

🔸organisations with limited patch capacity may prioritise only the highest EPSS vulnerabilities

🔸organisations protecting critical infrastructure may accept lower thresholds to maximise coverage

 

Key point:  EPSS does not eliminate prioritisation decisions, it makes those decisions more informed by attacker behaviour.

 

 

How Prioritisation Failures Enable Exploitation

 

The following examples illustrate how prioritisation failures translate into real-world exploitation outcomes.

Case Study 1 : Citrix Bleed (CVE-2023-4966)

Citrix Bleed affected NetScaler ADC and Gateway devices and became widely exploited following disclosure. CISA added CVE-2023-4966 to the Known Exploited Vulnerabilities catalogue after confirmed in-the-wild abuse.[5]

 

Initial CVSS scoring indicated severity, but urgency escalated because:

🔸 exploitation rapidly appeared in ransomware operations,

🔸 session token theft enabled credential bypass,

🔸 exposed internet-facing systems became immediate targets.[5][6]

 

Many organisations delayed remediation because:

🔸 patch queues were saturated with other High CVSS vulnerabilities,

🔸 static severity scoring did not distinguish immediate exploit urgency.

 

🔶 Operational lesson: CVSS indicated seriousness; exploitation intelligence defined urgency.

 

Case Study 2 :  Ivanti Connect Secure Exploitation (CVE-2023-46805 / CVE-2024-21887)

Ivanti edge appliances became a major exploitation target in early 2024.

 

CISA confirmed active exploitation in the wild, where attackers chained authentication bypass and command injection flaws to gain persistent access to perimeter devices.[7]

 

These vulnerabilities rapidly entered:

🔸 CISA KEV catalogues,

🔸 incident response escalations,

🔸 emergency remediation cycles.[5][7]

 

Organisations relying only on static CVSS prioritisation often responded too slowly because:

🔸 edge appliance exposure amplified attacker value,

🔸 exploitation accelerated before standard patch windows closed.

 

🔶 Operational lesson: Exposure context and exploitation probability must override static severity queues.

 

Operational Challenges for SOC and Security Teams

 

The detection challenge: Security teams that rely only on CVSS scores consistently encounter the same operational challenges, making it harder to accurately detect and respond to real threats:

 

🔸 Resource Allocation Distortion: Too many vulnerabilities appear equally urgent.

🔸 Exploitation Timing Blindness: CVSS does not reflect whether attackers are actively attacking a vulnerability.

🔸 Environmental Context Gaps: CVSS does not account for:

- internet exposure,

- crown-jewel assets,

- privilege adjacency.

🔸 Edge Device Risk Underestimation: Internet-facing infrastructure often becomes attacker priority regardless of CVSS rank.

 

 

Why Existing Controls Fail

Patch Velocity Constraints

Modern environments cannot safely apply patches at the speed vulnerability volume demands.

 

In 2024, more than 40,000 CVEs were published, with a significant proportion classified as High or Critical severity.[3]

 

However, patching is not a simple or instantaneous process. For production systems, remediation typically requires:

🔸 validating whether the vulnerability is present and exploitable in the environment

🔸 testing patches in staging environments to avoid service disruption

🔸 assessing impact on dependent applications and integrations

🔸 scheduling maintenance windows

🔸 deploying changes in a controlled rollout

🔸 performing post-deployment validation and rollback planning

 

For critical systems, services, and customer-facing platforms, untested patching introduces risk of outage, data corruption, or business disruption.

 

As a result, security and operations teams must triage and sequence remediation work rather than apply updates immediately across all systems.

 

This creates a fundamental constraint: remediation capacity is limited, while vulnerability volume continues to increase.

 

Critical Overload

When a large proportion of vulnerabilities are labelled High or Critical, severity-based prioritisation loses practical meaning.

 

If half or more of identified vulnerabilities require urgent remediation by policy, teams cannot realistically address all of them within required timeframes.

 

This leads to:

🔸 patch queues containing hundreds or thousands of “urgent” items

🔸 no clear distinction between actively exploited vulnerabilities and theoretical risks

🔸 delayed remediation for vulnerabilities that attackers are actually targeting

 

Without additional context such as exploitation likelihood or exposure, all High/Critical vulnerabilities appear equally important even when they are not.

 

Compliance Distortion

Many regulatory and compliance frameworks define remediation timelines based on CVSS severity thresholds.

 

While this provides standardisation, it also introduces unintended consequences:

🔸 teams prioritise vulnerabilities to meet audit requirements rather than reduce real-world risk

🔸 remediation decisions are driven by severity labels instead of attacker activity

🔸 vulnerabilities with low exploitation likelihood may be prioritised ahead of actively targeted flaws

 

This creates a misalignment between what organisations are measured on (compliance) and what attackers actually exploit (opportunity).

 

 

Risk Exposure Scenarios

 

Scenario 1 : Medium CVSS, High EPSS

A vulnerability is assigned a Medium CVSS score due to limited theoretical impact or required conditions for exploitation.

 

However, exploit code becomes publicly available, and threat actors begin actively targeting it causing its EPSS score to rise rapidly.

 

In practice, this often occurs in:

🔸 internet-facing applications

🔸 widely deployed software

🔸 authentication or session-handling components

 

Because it is not classified as High or Critical, the vulnerability is placed lower in the patch queue.

 

While remediation is delayed:

🔸 attackers scan for exposed systems

🔸 automated exploitation begins

🔸 initial access is established before patch deployment

 

Outcome: A vulnerability considered “moderate” in severity becomes a primary entry point for compromise.

What went wrong: Severity was prioritised over exploitation likelihood.

How EPSS helps: A rising EPSS score flags the vulnerability as operationally urgent, even when CVSS does not.

 

 

Scenario 2 : High CVSS, Low EPSS

A vulnerability receives a High CVSS score due to significant theoretical impact, such as privilege escalation or remote code execution.

 

However, exploitation requires:

🔸 local access

🔸 complex preconditions

🔸 uncommon configurations

 

As a result, the likelihood of real-world exploitation remains low, reflected in a low EPSS score.

 

Despite this, CVSS-based policies force prioritisation:

🔸 patching is scheduled urgently

🔸 engineering resources are allocated

🔸 change windows are consumed

 

This often delays remediation of other vulnerabilities that are:

🔸 easier to exploit

🔸 actively targeted

🔸 externally exposed

 

Outcome: Security effort is consumed addressing low-probability risk while higher-probability attack paths remain open.

What went wrong: Theoretical impact was treated as immediate risk.

How EPSS helps: EPSS allows teams to deprioritise low-likelihood vulnerabilities without ignoring them, freeing capacity for higher-risk issues.

 

Scenario 3 :  Zero-Day Active Exploitation

A previously unknown vulnerability is exploited in the wild before:

🔸 a CVE is formally published

🔸 a CVSS score is assigned

🔸 EPSS models accumulate sufficient data

 

This commonly occurs in:

🔸 edge devices (VPNs, firewalls, gateways)

🔸 widely deployed enterprise software

🔸 identity and access infrastructure

 

Organisations relying only on vulnerability scanning and CVSS-based prioritisation have no visibility of the risk.

 

Detection typically occurs only after:

🔸 suspicious activity is observed

🔸 threat intelligence alerts are issued

🔸 CISA adds the vulnerability to the KEV catalogue

 

Outcome: Attackers gain early access during the window between exploitation and formal vulnerability classification.

What went wrong: No integration with real-time threat intelligence.

How EPSS fits: EPSS is not designed for zero-day detection, but complements KEV and threat intelligence once exploitation patterns emerge.

 

Key Takeaway

Across all scenarios, the failure is consistent, prioritisation decisions are made using static severity rather than dynamic attacker behaviour.

 

Effective vulnerability management requires combining:

🔸 CVSS (impact)

🔸 EPSS (likelihood)

🔸 KEV and threat intelligence (confirmed exploitation)

🔸 exposure context (where the vulnerability exists)

 

Without this combination, teams systematically:

🔸 over-prioritise theoretical risk

🔸 under-prioritise active threats

 

Why Security Tools Don’t Solve Prioritisation

 

Modern security programmes deploy multiple tools to identify and monitor risk, including vulnerability scanners, SIEM platforms, EDR solutions, and periodic testing such as penetration tests or audits  however, these tools provide partial visibility, not prioritisation.  Each answers a different question but none in isolation, answers:

🔸 Which vulnerabilities should we fix first based on real attacker behaviour?

 

 

Vulnerability Scanners (VA Tools)

Vulnerability scanners identify known CVEs across systems and typically rank them by CVSS severity.

 

They are effective at:

🔸 discovering vulnerabilities at scale

🔸 providing asset-level visibility

🔸 supporting compliance reporting

 

However, they do not:

🔸 indicate whether a vulnerability is actively being exploited

🔸 distinguish between theoretical and likely attack paths

🔸 account for real-time threat activity

 

Limitation: They generate large volumes of findings, but offer limited guidance on which ones represent immediate operational risk.

 

SIEM Platforms

SIEM systems aggregate logs and detect suspicious activity across environments.

 

They are effective at:

🔸 identifying indicators of compromise

🔸 correlating events across systems

🔸 supporting incident investigation

 

However, they operate primarily:after attacker activity has begun

 

Limitation: SIEM detects exploitation attempts or breaches in progress, but does not help prioritise vulnerabilities before they are exploited.

 

 

EDR / XDR Solutions

Endpoint detection tools monitor system behaviour and detect malicious activity on endpoints.

 

They are effective at:

🔸 detecting post-exploitation behaviour

🔸 identifying malware and lateral movement

🔸 enabling response actions

 

However:

🔸 exploitation of unpatched vulnerabilities may appear as legitimate application behaviour initially

🔸 detection often occurs only after compromise has begun

 

Limitation: EDR reduces impact, but does not prevent prioritisation failures.

 

Penetration Testing and Audits

Penetration tests and security audits provide point-in-time assessments of security posture.

 

They are effective at:

🔸 identifying exploitable weaknesses

🔸 validating security controls

🔸 demonstrating real-world attack paths

 

However:

🔸 they are periodic, not continuous

🔸 they cover limited scope at a specific moment in time

🔸 they do not scale to the full vulnerability landscape

 

Limitation: They highlight risk, but do not provide ongoing prioritisation across thousands of vulnerabilities. Its a point in time 'opinion' that could be invalidated minutes after findings are recorded, also note, security professionals treat vulnerabilities discovered this way with a completely different remediation approach ignoring SLAs.

 

The Core Problem

Each of these tools answers a different question:

🔸 Vulnerability scanners → What vulnerabilities exist?

🔸 SIEM / EDR → Is something malicious happening now?

🔸 Pen testing → What could be exploited in this environment?

 

None of them answers: What are attackers most likely to exploit next across our entire environment?

 

Closing the Gap

Effective vulnerability prioritisation requires combining multiple signals:

🔸 CVSS → impact severity

🔸 EPSS → exploitation likelihood

🔸 KEV → confirmed active exploitation

🔸 Exposure context → where the vulnerability exists (e.g. internet-facing, critical systems)

 

This combination enables teams to move from:

 

"visibility of risk" to "prioritisation of real-world attack paths"

 

 

How to Integrate EPSS into Vulnerability Workflows

 

The following recommendations directly address the gaps identified in exploitation-aware prioritisation. Each action aligns to a specific stage in the vulnerability management lifecycle where EPSS should influence decision-making.

 

1️⃣ Integrate EPSS at Intake and Triage

 

Addresses: Initial CVE assessment performed using CVSS only

 

Action:

🔸 Ingest EPSS scores alongside vulnerability scan results
🔸 Enrich CVE data automatically during intake
🔸 Flag vulnerabilities above defined EPSS thresholds at point of entry

 

Outcome: High-probability vulnerabilities are identified early and enter the remediation queue with appropriate priority.

 

 

2️⃣ Implement Dual-Scoring Prioritisation

 

Addresses: Static prioritisation based on CVSS thresholds

 

Action:

🔸 Combine: CVSS (impact severity) + EPSS (exploitation likelihood)[1][2]
🔸 Define prioritisation rules that elevate vulnerabilities with high EPSS scores, regardless of CVSS rating

 

Outcome: Remediation effort aligns more closely with real-world attacker behaviour rather than theoretical severity.

 

 

3️⃣ Enable Continuous Re-Prioritisation

 

Addresses: No adjustment when exploitation likelihood changes

 

Action:

🔸 Monitor EPSS score updates daily
🔸 Trigger reclassification when:

- EPSS crosses defined thresholds

- significant score increases occur over short periods

🔸 Integrate alerts into vulnerability management or SIEM workflows

 

Outcome: Vulnerabilities are re-prioritised as threat conditions evolve, reducing exposure to emerging exploitation.

 

 

4️⃣ Introduce Fast-Track Remediation for High-Risk Vulnerabilities

 

Addresses: Standard patch cycles applied regardless of exploitation risk

 

Action:

🔸 Define accelerated SLAs for:

- high EPSS vulnerabilities

- KEV-listed vulnerabilities

- internet-facing assets

🔸 Enable out-of-band patching or compensating controls where required

 

Outcome: Actively targeted vulnerabilities are remediated faster than standard patch cycles allow.

 

 

5️⃣ Require EPSS Review in Risk Acceptance Decisions

 

Addresses: Exceptions granted without considering exploitation likelihood

Action:

🔸 Include EPSS score and percentile in risk acceptance workflows
🔸 Require justification for accepting vulnerabilities with elevated EPSS scores
🔸 Document exploitation risk alongside business impact

 

Outcome: Risk acceptance decisions reflect both impact and likelihood, reducing blind acceptance of exploitable vulnerabilities.

 

 

6️⃣ Correlate EPSS with KEV and Threat Intelligence

 

Addresses: Disconnected use of exploitation signals

Action:

🔸 Cross-reference vulnerabilities against:

- CISA KEV catalogue

- EPSS scores

🔸 Prioritise vulnerabilities where:

- EPSS is high (emerging risk)

- KEV confirms active exploitation

 

Outcome: Teams gain both predictive and confirmed exploitation visibility, improving prioritisation accuracy.

 

7️⃣ Apply Exposure-Based Weighting

 

Addresses: Lack of prioritisation based on where vulnerabilities exist

 

Action: Adjust prioritisation based on asset exposure:

🔸 internet-facing systems
🔸 externally accessible services
🔸 identity and authentication systems
🔸 edge infrastructure (VPNs, gateways, firewalls)

 

Outcome: Reflects real attacker targeting behaviour, where accessible systems are prioritised first.

 

8️⃣ Build Adaptive SLA Tiers

 

Addresses: Static remediation timelines based only on CVSS severity

 

Action: Implement risk-based SLAs combining EPSS, KEV, and exposure:

 

 

Outcome: Aligns remediation timelines with real-world attack likelihood and impact.

 

 Implementation Summary

 

Implementation Note

 

EPSS does not replace CVSS or threat intelligence. It provides an additional signal, exploitation likelihood, that must be combined with:

🔸 asset criticality
🔸 exposure (e.g. internet-facing systems)
🔸 business context

 

There is no universal EPSS threshold. Organisations should calibrate thresholds based on risk tolerance and remediation capacity.[2]

 

Key Takeaway

Effective vulnerability prioritisation requires integrating EPSS at multiple decision points not as a standalone score, but as part of a continuous, risk-based workflow.

 

 

Summary

 

The volume of disclosed vulnerabilities continues to rise faster than remediation capacity.[3] This makes severity-led patching increasingly ineffective.

EPSS introduces exploitation forecasting into vulnerability management, shifting patching from:

 

❌ severity-led compliance activity  

to  

✅ risk-led operational defence  

 

CVSS remains essential, but it answers only one part of the risk question: impact severity.

 

EPSS adds the missing dimension - likelihood of attacker action.

 

Modern vulnerability programmes should treat CVSS as impact context, not patch priority alone. The most effective models combine:

🔸  CVSS

🔸 EPSS

🔸 KEV

🔸 threat intelligence

🔸 asset exposure

🔸 business criticality

 

This is the shift from theoretical severity management to real-world exploitation defence.

 

 

Strategic Context & Further Reading     🔗 Vulnerability Management Reality: Operational Risk & Exposure-Based Prioritization Why read this: Understand why traditional vulnerability management models fail at scale and how exposure-based prioritization changes remediation strategy.   🔗 Operational Threat Intelligence: Practical Guide for Security Teams Why read this: Learn how to integrate real-time threat intelligence into vulnerability prioritization and move from reactive patching to intelligence-led defense.

 

 

---

About This Report

 

Reading Time: Approximately 15 minutes

 

Attribution Note

This analysis is based on publicly available reporting and security research summaries. Some technical details may change as additional information becomes available.

 

Author Information

Timur Mehmet | Founder & Lead Editor

Timur is a veteran Information Security professional with a career spanning over three decades. Since the 1990s, he has led security initiatives across high-stakes sectors, including Finance, Telecommunications, Media, and Energy. Professional qualifications over the years have included CISSP, ISO27000 Auditor, ITIL and technologies such as Networking, Operating Systems, PKI, Firewalls. For more information including independent citations and credentials, visit our About page.

Contact: This email address is being protected from spambots. You need JavaScript enabled to view it.

 

Editorial Standards

This article adheres to Hackerstorm.com's commitment to accuracy, independence, and transparency:

• Fact-Checking: All statistics and claims are verified against primary sources and authoritative reports
• Source Transparency: Original research sources and citations are provided in the References section below
• No Conflicts of Interest: This analysis is independent and not sponsored by any vendor or organization
• Corrections Policy: We correct errors promptly and transparently. Report inaccuracies to This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Policy: Ethics, Non-Bias, Fact Checking and Corrections

Learn More: About Hackerstorm.com | FAQs

 

Source Transparency

 

Primary Standards and Methodology Sources

[1] FIRST.org - Exploit Prediction Scoring System (EPSS) Overview
https://www.first.org/epss/

[2] FIRST.org - EPSS Model Documentation
https://www.first.org/epss/model

[3] National Vulnerability Database (NVD) - Vulnerability Metrics and CVE Data
https://nvd.nist.gov/

[4] NIST NVD - CVSS Vulnerability Metrics Documentation
https://nvd.nist.gov/vuln-metrics/cvss

 

Active Exploitation Intelligence Sources

[5] CISA Known Exploited Vulnerabilities (KEV) Catalog
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

[6] Citrix Security Bulletin - CVE-2023-4966 (Citrix Bleed) Advisory
https://support.citrix.com/article/CTX579459

[7] CISA Cybersecurity Advisory AA24-060B - Ivanti Connect Secure Exploitation
https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-060b

 

Supporting Threat Research

[8] FIRST EPSS Research Paper (ACM Digital Library)
https://dl.acm.org/doi/10.1145/3436242

[9] Volexity Threat Research - Ivanti Exploitation Analysis
https://www.volexity.com/

[10] Ivanti Security Advisory - CVE-2023-46805 / CVE-2024-21887
https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-and-Policy-Secure-Gateways?language=en_US