OT Vulnerability Management: Prioritizing CVEs You Cannot Always Patch

01Key takeaways

1. 01

   OT vulnerability management is triage first and patching second; the goal is to rank risk you can act on, not to close every CVE.

2. 02

   CVSS severity is a starting input, not a priority. Combine it with CISA KEV (known exploitation) and EPSS (predicted exploitation) before you schedule work.

3. 03

   VEX and SBOM correlation cut the noise by telling you which catalogued CVEs are actually present and exploitable in a given device, instead of treating every component flaw as live.

4. 04

   Most OT vulnerabilities will be carried unpatched for long periods, so compensating controls such as segmentation, monitoring and reduced reachability do the real risk reduction.

5. 05

   This article handles prioritization; deciding whether and how to deploy a fix is patch management, a separate workflow you should cross-link, not merge.

02What OT vulnerability management actually is

OT vulnerability management is the ongoing process of identifying known vulnerabilities in industrial assets, judging the risk each one poses in your specific environment, and deciding what to do about it. In practice the deciding step dominates, because the volume of disclosed CVEs far exceeds the number of fixes any plant can safely apply in a year.

It is useful to separate two questions that are often blurred. The first is which vulnerabilities matter most right now. The second is how to treat a given vulnerability once you decide it matters. This article is about the first question: prioritization and triage. The second question, including whether to patch, when to schedule it, and how to test it without breaking production, is the subject of OT patch management and should be cross-linked rather than duplicated here.

Short version: OT vulnerability management ranks risk; OT patch management acts on the ranking. Keeping them distinct prevents teams from treating a CVE list as a to-do list.

03Why triage matters more in OT than in IT

In enterprise IT, the default answer to a vulnerability is to patch on a cycle. In OT that default frequently does not apply. Devices may require vendor-validated firmware, downtime may be measured in lost production rather than minutes, and some controllers cannot be rebooted outside a planned outage that comes once or twice a year.

The result is a large and growing backlog of unpatched but documented vulnerabilities. Because you cannot clear that backlog quickly, the order in which you treat items becomes the dominant risk decision. Spending a rare maintenance window on a high-CVSS flaw that is unreachable and never exploited, while ignoring a moderate flaw that is on the CISA KEV catalog and exposed to your business network, is a worse outcome than no patching at all.

Threat framing helps keep the triage honest. MITRE ATT&CK for ICS describes how adversaries move toward impact in industrial environments, from initial access and remote services to manipulation of control. A vulnerability that shortens one of those paths deserves more attention than one that does not, regardless of its headline score.

04The four signals: CVSS, KEV, EPSS and consequence

A defensible priority order in OT blends four signals. No single one is sufficient, and using only the first is the most common mistake in the field.

CVSS v4.0 (severity)

The intrinsic worst-case severity of a flaw. The Base group is constant; Threat and Environmental groups let you adjust for exploitation status and your own deployment, producing CVSS-BT or CVSS-BTE scores rather than relying on Base alone.

CISA KEV (confirmed exploitation)

The Known Exploited Vulnerabilities catalog lists CVEs with reliable evidence of exploitation in the wild and clear remediation guidance. Presence on KEV is a strong reason to move an item up the queue.

EPSS (predicted exploitation)

The Exploit Prediction Scoring System estimates the probability a CVE will be exploited in the next 30 days, as a value from 0 to 1. EPSS version 4 launched in 2025. It helps rank the many CVEs that are not yet on KEV.

Consequence (your context)

What the affected asset does for safety, availability and production, and what an attacker gains by reaching it. A flaw on a safety-instrumented function or a reachable engineering workstation outranks the same flaw on an isolated, low-impact device.

A workable rule of thumb: treat anything on KEV that exists in your environment as priority work, use EPSS to triage the long tail that is not yet weaponized, and let CVSS describe severity rather than dictate order. Then weight everything by consequence, because OT risk is ultimately physical.

05Cutting the noise with VEX and SBOM correlation

A single industrial device can contain hundreds of software components, each carrying its own history of CVEs. A naive scanner will report many of these as findings even when the vulnerable code is not present in the shipped build, not reachable, or already mitigated by the vendor. That noise buries the items that matter.

A Software Bill of Materials (SBOM) lists the components inside a product, and a Vulnerability Exploitability eXchange (VEX) document states, per CVE, whether the product is actually affected. VEX status values are not affected, affected, fixed and under investigation, with a justification required when a vendor declares a product not affected. Correlating scanner output against SBOM and VEX lets you discard the components that are present-but-not-exploitable and focus on the ones that are.

VEX answers the question SBOM alone cannot: is this catalogued CVE actually exploitable in this device? Used together, they often remove a large share of findings before triage even begins, which is why they belong early in the workflow.

06A practical triage workflow

Triage works best as a repeatable pipeline rather than an ad hoc judgment call each time a bulletin lands. The steps below assume you already have an asset inventory, because you cannot prioritize vulnerabilities on assets you have not identified.

• Match new CVEs and ICS advisories against your asset inventory so you only triage what you actually run.
• Filter component findings through SBOM and VEX to drop items the vendor states are not exploitable in the product.
• Flag every remaining CVE that appears on the CISA KEV catalog as immediate-action candidates.
• Rank the rest by EPSS probability and CVSS-BT severity to order the non-exploited backlog.
• Weight the ordering by consequence: asset criticality, safety role, and reachability from less-trusted networks.
• Assign each item an outcome: patch in the next window, apply compensating controls now, or formally accept and document the risk.

The final step is where prioritization hands off to action. Items routed to patching enter the separate patch management process. Items that cannot be patched soon must get compensating controls, which is where most OT risk reduction actually happens.

07Compensating controls for what you cannot patch

Because much of the OT backlog will stay unpatched for months or years, the controls around a vulnerable asset matter more than the patch you are still waiting for. The aim is to reduce the chance that a known flaw is ever reachable or useful to an attacker, even while the underlying code stays vulnerable.

• Segment the asset into an IEC 62443 zone so the vulnerable function is not reachable from the business network or the internet.
• Restrict and monitor the conduits into that zone, removing standing remote access and inbound management paths.
• Add detection tuned to the vulnerability: alert on the protocol commands or remote-service behavior an exploit would require.
• Reduce reachability so an attacker who reaches the destination network still has no path back to the vulnerable device.
• Tighten identity and access for any engineering workstation or jump host that can touch the asset.

Compensating controls do not lower a CVSS score, but they change real risk by shrinking exposure and exploitability. A high-severity flaw on a device that no untrusted network can reach is a very different problem from the same flaw on an internet-facing system. Triage should explicitly credit these controls when deciding what can safely wait.

08Mapping triage to standards and compliance

Vulnerability prioritization is not freelance risk-guessing; it maps onto established frameworks that auditors and regulators recognize. Aligning your process with them makes risk-acceptance decisions defensible.

NIST SP 800-82

The Guide to OT Security frames risk management for control systems and supports prioritizing by impact to operations and safety rather than IT severity alone.

NIST SP 800-53 / RMF

Defines control families including risk assessment (RA) and configuration management, and recognizes documented compensating controls as a legitimate response when a primary control is not feasible.

ISA/IEC 62443

Provides the zones-and-conduits model and patch and vulnerability handling expectations for asset owners and product suppliers across the 62443 series.

CISA KEV guidance

CISA recommends all organizations, not only federal agencies, use the KEV catalog as a prioritization input and remediate listed vulnerabilities ahead of the broader backlog.

The practical benefit is traceability. When you defer a high-severity CVE because it is unreachable, on no exploitation list, and covered by segmentation, you can show the inputs and the standard that supports the decision. That is the difference between a risk you accepted and a risk you ignored.

09Common pitfalls in OT vulnerability management

Most failures in this discipline are process failures, not tooling gaps. The same patterns recur across industries.

• Treating CVSS base score as the priority order and ignoring KEV, EPSS and reachability.
• Scanning OT actively with IT tools and disrupting fragile devices, instead of using passive or vendor-approved methods.
• Drowning in component-level findings because SBOM and VEX are not used to filter non-exploitable CVEs.
• Letting the backlog grow without ever assigning compensating controls or a documented risk acceptance.
• Confusing prioritization with patching, so items are ranked but never actually scheduled or mitigated.
• Assuming an air gap exists when a forgotten conduit, vendor link or removable-media workflow quietly provides reachability.

The last point is worth stressing. Triage that assumes isolation is only as good as the isolation itself. If you credit a flaw as unreachable, that reachability claim has to be enforced and verified, not merely believed.

10Where one-way transfer and exposure reduction fit

Many OT vulnerabilities are dangerous only because an attacker has a path to reach them. A remote-code-execution flaw in a controller is far less useful to an adversary who has no route into the zone and no way to send commands back. That is why exposure reduction belongs in the same conversation as scoring and patching.

This is where reducing bidirectional reachability does real work for the unpatched backlog. If the only required data flow across a boundary is outbound, telemetry, logs or historian data leaving the plant, then a one-way transfer design removes the inbound path that most exploit chains depend on. A vulnerable device behind a publication-only boundary cannot be reached by the return traffic an attacker needs.

A data diode is one control among many, not a substitute for triage. But for boundaries that genuinely only need to publish data outward, an AIRGAPNET controlled connectivity pattern can turn a large set of inbound-reachable, unpatched CVEs into vulnerabilities with no live attack path, which changes how aggressively you need to chase those patches.

11Building a durable program

A mature OT vulnerability management program is steady-state, not a one-off cleanup. It starts from a trustworthy asset inventory, ingests advisories and CVE feeds, filters them through SBOM and VEX, ranks with KEV and EPSS, weights by consequence, and routes every item to patching, mitigation or documented acceptance.

Measure the program by how it handles the items it cannot fix, not only by how many it closes. Track how much of the backlog is covered by compensating controls, how many KEV-listed CVEs remain reachable, and how quickly a newly exploited flaw moves from disclosure to a decision. Those metrics describe real exposure better than a raw open-vulnerability count.

The honest end state is that you will always carry unpatched vulnerabilities in OT. The point of triage is to make sure the ones you carry are the ones an attacker can least reach and least use, and that every deferral is a decision you can explain.

FAQFrequently asked questions

SRCSources of record