You can't patch a running line. Here's what OT vulnerability management actually looks like.

CISA's Known Exploited Vulnerabilities catalog adds ICS-related entries regularly. Each one represents a vulnerability that has been observed being actively exploited in the wild — not theoretical, not proof-of-concept, but used in real attacks. For an IT team, the response is straightforward: patch within the deadline or accept the risk with documentation. For an OT team, the response is constrained by something the catalog does not model: the device cannot be taken offline without stopping production.

Claroty's ICS vulnerability data puts 76% of critical CVEs in the category of requiring downtime to remediate. That is not a flaw in the data. It is an accurate reflection of how industrial firmware works: the patch is embedded in a firmware update, the firmware update requires the device to restart, and the device restart stops the process it controls. In a pharmaceutical batch, a food processing line, or an energy generation unit, that restart has production and safety consequences that the patch deadline does not account for.

The alternative to patch-everything is triage. It requires three inputs: a complete asset inventory, an exploitation likelihood assessment for each vulnerability in that inventory, and a maintenance calendar. The asset inventory tells you which CVEs apply to your environment. The exploitation likelihood tells you which of those CVEs are likely to be used against you in the near term — KEV status, public proof-of-concept availability, and whether the vulnerability is reachable from an attacker's likely entry point all factor in. The maintenance calendar tells you when you can act.

The output is a prioritized list: patch these in the next window, mitigate these with compensating controls, monitor these and revisit next quarter. The compensating controls are the important part. A vulnerability on a PLC that cannot be patched until a planned shutdown in six months is not unaddressed — it is addressed with network controls that reduce its reachability, monitoring that would detect exploitation, and a patch scheduled for the next window. That is a defensible security posture. Ignoring it because the patch is impossible is not.

The most effective compensating control for an unpatched ICS vulnerability is network isolation: if the vulnerable device cannot be reached from the path an attacker would use, the vulnerability is not exploitable in practice. This is why segmentation and vulnerability management are not separate workstreams in OT — the segment boundary is often the patch. A PLC running vulnerable firmware behind a properly configured firewall that blocks the relevant protocol from untrusted sources is in a materially better position than the same PLC on a flat network with a pending patch ticket.

The second most effective control is detection. If you cannot prevent exploitation, you need to detect it quickly enough to contain it before the blast radius grows. That means knowing what normal traffic looks like on the OT network, having alerts for anomalies on the vulnerable system, and having a response procedure that can isolate the affected zone without stopping adjacent processes. Patch management in OT is a risk management discipline, not a ticket-closing exercise. The metric is not closure rate. It is time to contain if the vulnerability is exploited.