CVE and EPSS in OT Environments: Which Vulnerabilities to Fix When You Can't Patch Everything

The prioritization problem in OT

In a manufacturing OT environment, the number of known vulnerabilities affecting production systems can be considerable. PLCs, HMIs, industrial switches, SCADA servers, legacy systems: each one accumulates CVEs over time. It is not unusual for a mid-sized OT inventory to show hundreds of open vulnerabilities, some of them years old.

The problem is not finding the vulnerabilities: it is deciding what to do first, knowing that you cannot do everything. And in OT this limitation is structural, not a matter of insufficient resources.

Patching a PLC or a SCADA system typically requires a planned plant shutdown, process regression testing, coordination with the vendor, and maintenance windows that will open weeks or months from now. In some cases (end-of-support systems, contracts that prohibit software changes, hardware that does not support updated firmware versions) the patch does not exist or is not applicable. You therefore need a prioritization logic that is practical, not just theoretical.

CVSS: useful but insufficient

The Common Vulnerability Scoring System (CVSS) is the de facto standard for quantifying the severity of a vulnerability. A CVSS score ranges from 0 to 10, where 9 to 10 is critical, 7 to 8.9 is high, and 4 to 6.9 is medium. The formula considers factors such as the attack vector (remote or local), complexity, required privileges, and impact on confidentiality, integrity, and availability.

CVSS is useful because it standardizes severity and allows different vulnerabilities to be compared on a common scale. But it has a fundamental limitation: it measures the theoretical severity of a vulnerability, not the probability that it will be exploited in practice.

A vulnerability with a CVSS of 9.8 is theoretically very serious. But if it affects a niche protocol used in very few installations worldwide, if no public exploit exists, and if no threat group is actively using it, in practice the real risk can be much lower than a vulnerability with a CVSS of 7.2 that has a mature exploit available on GitHub and that ransomware groups are already using in their campaigns.

Managing prioritization based on CVSS alone leads to a systematic error: there is a tendency to over-prioritize theoretically serious but rarely exploited vulnerabilities, and to under-prioritize moderate vulnerabilities with a high probability of active exploitation.

EPSS: what it measures and how it works

The Exploit Prediction Scoring System (EPSS) is a model developed by FIRST (Forum of Incident Response and Security Teams) to estimate the probability that a vulnerability will be exploited in the wild within the 30 days following the assessment.

The model is based on observed data: exploit reports in OSINT sources, activity in threat intelligence feeds, proof-of-concept publications, discussions in underground forums, and activity from search engines for exposed devices. The result is a probability expressed between 0 and 1 (or as a percentage).

Empirical data shows a very skewed distribution: the vast majority of published CVEs are never actively exploited in observed campaigns. A relatively small share concentrates nearly all real exploit activity. EPSS makes it possible to identify which part of this distribution a specific vulnerability falls into.

It is important to understand what EPSS is not: it is not a measure of impact if the vulnerability is exploited, it does not consider the specific context of the organization, and it can change significantly over time if new information (a published exploit, an observed campaign) alters the estimate. It should be used as an input in a triage process, not as an oracle.

How to combine CVSS and EPSS in OT

The most effective prioritization logic in OT combines the two dimensions in a four-quadrant matrix:

High CVSS + high EPSS: top priority. The vulnerability is serious and is being actively exploited. It calls for immediate compensating controls if the patch is not applicable.

High CVSS + low EPSS: medium priority. The vulnerability is theoretically serious but is not being actively exploited. It should be scheduled for the next available maintenance window, but it does not justify emergency measures.

Low CVSS + high EPSS: medium-high priority, often underestimated. This is the dangerous quadrant: the vulnerability looks moderate when you look only at CVSS, but there is concrete exploit activity. In OT this profile requires attention because the compensating controls can be less intuitive.

Low CVSS + low EPSS: low priority. To be handled within the normal patch management cycle as opportunities arise.

Concrete examples in the OT context

Case 1: CVE with CVSS 9.8, EPSS 0.8%

Imagine a critical vulnerability in a legacy industrial communication protocol, with a remote attack vector and no authentication. The CVSS is very high. But the protocol in question is used only in very specific installations, the exploit requires detailed knowledge of the implementation, and there is no evidence of use in observed campaigns. EPSS is below 1%.

In an OT environment where the patch requires a three-day shutdown, this profile does not necessarily justify an emergency intervention. The existing network segmentation and the absence of direct exposure may already mitigate the risk to an acceptable degree. It should be planned, not handled as a crisis.

Case 2: CVE with CVSS 7.2, EPSS 45%

A high-severity vulnerability in a software component widely deployed in SCADA systems. It is not critical in absolute terms, but a working exploit has been publicly available for weeks, it is easy to use, and threat intelligence feeds record active scanning activity against exposed installations. EPSS is at 45%.

In OT, this profile calls for immediate action, even though patching is difficult. The compensating controls (isolating the system at the network level, blocking the specific attack vector at the firewall level, increasing monitoring) should be implemented before the next available maintenance window.

Triage logic for OT environments

Once priorities are defined, you need a decision-making framework for every identified vulnerability. The questions to ask in sequence:

1. Is this system reachable from the outside or from untrusted networks? Segmentation drastically reduces the probability of exploitation. A fully isolated system with a high-EPSS CVE has a far lower real risk than an exposed system with the same CVE.

2. Is the specific attack vector feasible in my context? A vulnerability that requires prior authentication on a system with strong authentication is less critical than one that requires no credentials.

3. Is there a patch that can be applied today? If yes: schedule it in the first available window, with priority proportional to the CVSS/EPSS combination. If no: move on to compensating controls.

4. Which compensating controls are available? Typical options in OT include: additional network isolation, blocking the vulnerable protocol at the firewall level, increased monitoring of traffic to the system, disabling unnecessary features, and notifying operators.

5. Is the residual risk after compensating controls acceptable? This assessment requires the operational context: how critical is the process the system governs? What would the consequences of an incident be?

Limitations and precautions when using EPSS

EPSS is an excellent tool, but applying it mechanically without context leads to errors. Some precautions specific to the OT context:

EPSS reflects activity observed in the IT world: the monitored exploit campaigns mostly concern IT systems. An OT-specific vulnerability may have a low EPSS simply because the OT threat intelligence ecosystem is less mature, not because the risk is low.

The specialized ICS-CERT and CISA KEV feeds are complementary: CISA's Known Exploited Vulnerabilities Catalog lists vulnerabilities with confirmed evidence of active exploitation, including some that are OT-specific. It should be consulted alongside EPSS, not as an alternative.

The score changes over time: a CVE with a low EPSS today can become a high-EPSS CVE tomorrow if an exploit is published or a campaign begins. Triage is not a one-time operation: it requires periodic reassessment, at least monthly for critical systems.

OT vulnerability prioritization is not a problem that can be solved with automatic formulas. CVSS and EPSS together provide a rational basis for decisions, but the operational context (the criticality of the process, the existing segmentation, the ease of applying compensating controls) must always factor into the final assessment.

The MON5 angle

The CVSS/EPSS matrix described in this article is at the heart of the MON5 ANALYZE phase: the platform correlates the vulnerabilities detected on assets with the EPSS score and, above all, with the real exposure of each device. A vulnerable PLC that is segregated in a well-defined IEC 62443 zone receives a different priority than the same PLC reachable from the IT network.

The prerequisite is an accurate inventory with the firmware versions actually in production, which MON5 builds passively in the DISCOVER phase. If your list of open CVEs has become unmanageable, an OT assessment reduces it to a list of priorities you can act on.

Analysis and commentary by MON5 based on public-domain research and data from the OT/ICS sector.