Every plant IT and OT security team has the same folder problem: a growing pile of CISA ICS advisories, most scored 9.8 or higher, and no realistic way to patch all of them on the same day, week, or even quarter. CISA’s move toward more consistent flagging of Known Exploited Vulnerabilities (KEV) status within ICS advisories — leaning harder on exploitation evidence rather than raw CVSS math — is a good and overdue shift. But it doesn’t solve your workload problem by itself. It just gives you a better input. What you do with that input is still on you.
The core mistake plants make is treating CVSS severity as a proxy for urgency. It isn’t, and it never was. CVSS base score measures theoretical worst-case impact assuming an attacker has access and a working exploit. It says nothing about whether either of those conditions is remotely plausible in your environment. A 9.8 on a PLC’s web management interface is a very different animal depending on whether that interface sits on a flat network reachable from the corporate VLAN, or whether it’s air-gapped behind a firewall with no route from anything except an engineering workstation that’s itself locked down. Same CVE, wildly different real-world risk.
Why CVSS-only triage breaks down on the plant floor
CVSS was built for IT systems where patch cycles are measured in days and downtime is cheap. Manufacturing doesn’t work that way. A patch to a PLC firmware or an HMI runtime often requires a scheduled outage, revalidation of the control logic, and sometimes a vendor field service visit. You cannot treat that the same way you’d treat a Tuesday patch push to a fleet of laptops. When every advisory gets stamped “critical,” the practical effect is that nothing gets prioritized — teams either patch reactively after something breaks, or they burn out trying to chase every CVE with equal urgency and end up behind on all of them.
CISA’s increasing emphasis on KEV status is useful precisely because it separates “theoretically bad” from “actively being exploited somewhere, by someone, right now.” That’s a meaningfully different signal. But KEV inclusion is necessary information, not sufficient. A vulnerability can be in KEV and still be unreachable in your specific architecture. The framework below is how to combine that federal signal with what you actually know about your own plant.
A three-factor rubric: KEV status, reachability, and compensating controls
The rubric is simple by design, because a scoring system nobody can apply under deadline pressure is worse than no system at all. Score each advisory on three axes, then combine them into a priority tier.
1. KEV and exploitation evidence
Check whether the CVE is in CISA’s KEV catalog, referenced in the advisory as having known exploitation, or tied to public proof-of-concept code. This is a binary-ish signal with a middle tier: actively exploited, PoC exists but no confirmed exploitation, and no known exploit activity at all. Weight this heavily — it’s the closest thing to ground truth you get from the outside world, and it’s exactly the data point CISA’s 2026 tagging effort is trying to make more visible and consistent across advisories.
2. Purdue level reachability
This is where most of the real risk reduction happens, and it’s the axis vendors and generic vulnerability scanners can’t score for you because they don’t know your network. Ask plainly: can an attacker actually get a packet to this device from a plausible entry point? A vulnerability on a Level 0/1 field device that’s only reachable from a Level 2 supervisory network, which itself has no route to Level 3 or the corporate network, is a fundamentally lower-urgency item than the same CVE on a device with a routable path from an IT-facing segment. Map every asset with a live advisory against your actual Purdue segmentation — not the segmentation in the network diagram from three years ago, the real one, verified against current firewall rules and VLAN configs. If you haven’t validated your zone boundaries recently, that gap itself is the finding you should act on first.
3. Compensating controls already in place
Does the asset sit behind an industrial firewall with deep packet inspection tuned to the relevant protocol? Is there network-based intrusion detection watching that segment? Is remote access to it gated by jump host and MFA rather than direct VPN? Is the exploitable service (a web UI, an unauthenticated protocol) actually disabled or restricted, even if the underlying vulnerable code is present? Compensating controls don’t erase a vulnerability, but they materially change the odds of it being exercised, and that’s exactly what risk-based prioritization is supposed to weigh.
Turning three axes into a tier
Combine the three into a small number of tiers rather than a false-precision numeric score — auditors and plant managers alike respond better to a defensible tier structure than a single number that looks scientific but hides the judgment calls inside it.
- Tier 1 — patch now, outage justified: confirmed KEV/active exploitation, reachable from a routable path, weak or absent compensating controls.
- Tier 2 — scheduled patch, next maintenance window: KEV or PoC exists, but reachability is limited or strong compensating controls are present.
- Tier 3 — monitor and compensate: no known exploitation, low reachability, controls already substantially mitigate exposure. Document the reasoning and revisit on a fixed cadence, not never.
The documentation matters as much as the tiering. When an auditor or a leadership team asks why a 9.8 CVE sat unpatched for months, “we assessed it as unreachable given current segmentation, with compensating controls X and Y in place, re-evaluated quarterly” is a defensible answer. “We were going to get to it” is not.
What this means for how you read advisories going forward
As CISA standardizes exploitation tagging across ICS advisories, expect the volume of advisories to keep climbing — more vendors reporting, more researchers finding issues in increasingly instrumented OT equipment — while the fraction with confirmed real-world exploitation stays comparatively small. That’s actually good news for triage, if you build the muscle to use it. The plants that will struggle are the ones still running vulnerability management as a compliance checkbox, patching in CVSS order without ever asking whether the vulnerable component is reachable at all. The plants that will do fine are the ones who’ve already done the unglamorous work: accurate asset inventories, validated network segmentation, and a rubric like this one written down before the next advisory lands, not improvised in a panic after it does.
None of this replaces patching. It replaces patching everything with the same urgency, which was never actually a strategy — it was just how teams coped with too much noise and not enough context. Build the context once, apply the rubric consistently, and the next 9.8 advisory becomes a five-minute triage decision instead of a fire drill.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
