If you run vulnerability management for an OT environment, you already know the ritual. A new ICS advisory drops, CVSS says 9.8, and somebody in security operations opens a ticket demanding the affected HMI get patched by end of week — never mind that the HMI in question sits on an isolated cell network behind two firewalls and hasn’t touched the internet since it was commissioned. Meanwhile a 6.5-scored advisory on a PLC firmware update sits untouched, even though that PLC talks to a safety-adjacent interlock and lives on a network segment with a documented (if undocumented-to-security) remote access path for a vendor.
That mismatch isn’t a one-off. It’s the predictable result of using a scoring system built for IT asset risk to make decisions about OT consequence. CISA has spent the last couple of years quietly fixing this, and by 2026 the shift is hard to ignore: a growing share of ICS advisories now carry Stakeholder-Specific Vulnerability Categorization (SSVC) decision guidance alongside — or instead of — a flat CVSS baseline. If your plant is still triaging purely by CVSS number, you’re leaving CISA’s better tool on the table.
Why CVSS was always the wrong primary lens for OT
CVSS was built to answer “how severe is this vulnerability in the abstract,” based on attack vector, complexity, privileges required, and impact to confidentiality, integrity, and availability. It says nothing about whether the vulnerable component is reachable, whether it’s actively being exploited, or what happens on the plant floor if it’s compromised. A vulnerability that lets an attacker crash a service is scored the same whether that service runs a marketing website or a burner management system.
SSVC, developed originally by CISA and Carnegie Mellon’s Software Engineering Institute, asks a different question: given what we know about exploitation and exposure, and given what this asset actually does, what decision should the operator make right now? It’s a decision tree, not a severity score, and it ends in one of a small number of actions: Track, Track*, Attend, or Act. That’s a fundamentally different output than a number between 0 and 10 — it’s built to be actionable rather than descriptive.
The four questions that actually matter on your floor
SSVC’s decision points map cleanly onto how a competent plant engineer already thinks about risk, even if they’ve never heard the acronym. The four that matter most for ICS triage are:
- Exploitation status — Is there evidence of active exploitation in the wild, a public proof-of-concept, or none? This is the single biggest driver of urgency and it’s exactly the thing CVSS ignores entirely.
- Exposure — Is the affected system internet-facing, reachable from a corporate network, or genuinely isolated on an air-gapped or tightly segmented OT VLAN? Exposure isn’t binary in most real plants — it’s a spectrum shaped by jump hosts, vendor remote access, and IT/OT convergence points that never made it into the network diagram.
- Mission/business impact — If this component is compromised or taken offline, does a line stop, does a plant stop, or does nothing visible happen at all? This is where asset criticality mapping — the unglamorous spreadsheet work most OT security programs underinvest in — pays off.
- Safety impact — Could exploitation plausibly contribute to a safety event: loss of a protective function, a hazardous release, an uncontrolled process excursion? This is the decision point CVSS has no vocabulary for at all, and it’s the one that should override almost everything else when it’s in play.
Run any advisory through those four questions and you get a materially different priority order than raw severity gives you. A critical CVSS score on an air-gapped, non-safety historian is very plausibly a Track — log it, watch for changes in exploitation status, move on. A medium-scored CVSS bug in firmware running on an internet-reachable RTU tied to a safety interlock is an Act, full stop, regardless of what the base score says.
What CISA changing its own advisories actually means for you
CISA folding SSVC guidance into its ICS advisory program doesn’t mean the agency is doing your risk assessment for you — it can’t, because it doesn’t know your network topology, your compensating controls, or which of your assets are safety-adjacent. What it does mean is that CISA is now publishing the exploitation and general-impact inputs you need — the parts of the decision tree that require threat intelligence and vendor coordination most plants can’t generate themselves. The exposure, mission-impact, and safety-impact decision points are still yours to fill in, and that’s the work that actually determines your queue order.
That division of labor is the right one. CISA is well positioned to tell you whether a vulnerability is being actively exploited or has a public exploit available. Only you know whether the affected controller sits on a flat network with your ERP system or behind a properly configured data diode.
A practical way to re-score your backlog
Most plants have a backlog of open ICS advisories that were triaged, if at all, by CVSS score at intake and then never revisited. Re-scoring that backlog with SSVC logic is a finite, worthwhile project, not a program overhaul. A workable approach:
- Pull your open advisories and strip the CVSS score from the front of the ticket. Don’t let it anchor the conversation. Keep it as metadata, not as the sort key.
- Tag exposure honestly, not aspirationally. If you don’t actually know whether an asset is reachable from a jump host or a vendor VPN, that’s an exposure-mapping gap to fix before it’s a triage input — assume worse exposure until verified.
- Build (or dust off) your safety-adjacent asset list. This should already exist from your hazard and operability work or IEC 61511/61508 safety lifecycle documentation. If it doesn’t map cleanly to your OT asset inventory, that gap is arguably more urgent than any single CVE.
- Re-sort the backlog into Track / Track* / Attend / Act buckets rather than a numeric ranking. The bucket, not the score, should drive patch scheduling, isolation decisions, or risk acceptance sign-off.
- Revisit exploitation status periodically, not just at intake. A Track item can become an Act item the day a public exploit shows up, independent of anything else changing.
None of this eliminates judgment calls, and SSVC won’t save you from a bad asset inventory or an undocumented remote access path — garbage exposure data in still produces garbage prioritization out. But it does stop the single most common failure mode in OT vulnerability management: letting a vendor’s abstract severity score override what your own engineers already know about the plant. If CISA is doing the work of surfacing exploitation evidence for you, the least a plant can do is stop discarding it in favor of a number that was never built to answer the question you’re actually asking.
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.
