Every plant with an OT security program has some version of the same spreadsheet: a running list of CISA ICS advisories, a column for CVSS score, a column for “reviewed,” and a column that’s usually blank because nobody got back to it. That workflow made a kind of sense five years ago, when ICS advisories trickled out at a manageable pace and most of them concerned obscure protocol stacks nobody in the plant had ever heard of. It does not make sense anymore.
CISA and the sector-specific CERTs have been publishing ICS advisories at a noticeably higher volume and with noticeably more specificity — vendor, product line, firmware version, exploitability detail — than they did a few years back. More of those advisories are landing tied to CVEs on the Known Exploited Vulnerabilities catalog, which means they’re not theoretical: someone, somewhere, is actively using the flaw. And a growing share of the KEV-tagged entries touch the boring, ubiquitous hardware that actually runs plants — PLCs, HMIs, engineering workstation software, industrial VPN appliances — rather than exotic SCADA historians three vendors removed from your line.
That shift matters for a reason that has nothing to do with hackers: contracts. Cyber insurance policies increasingly carry patch-response clauses tied to KEV listings or advisory severity. Customer security addenda, especially in automotive, aerospace, and defense supply chains, are starting to specify remediation windows. If your plant’s actual practice is “we’ll get to it,” you are now out of compliance with paper you signed, whether or not anything ever gets exploited.
The spreadsheet-and-a-shrug problem
The core failure in most plants isn’t lack of awareness. Controls engineers read the advisories, or at least the subject lines. The failure is that there’s no decision framework connecting an advisory to an action with a deadline. Everything gets triaged the same way: forwarded to IT, discussed at the next monthly meeting, tabled until the next planned shutdown. A critical remote-code-execution flaw in a PLC facing an untrusted network segment gets the same lazy treatment as a low-severity denial-of-service bug in a protocol nobody’s exposed.
That’s backwards. Not every advisory deserves the same urgency, and treating them uniformly is exactly why response times stay stuck in multi-week limbo. What you need is a triage that takes maybe an hour per advisory instead of a meeting per quarter, and produces one of three outcomes within roughly three business days: patch now, apply a compensating control, or formally accept the risk with a documented rationale and review date.
A triage framework built on two axes
Score every new advisory against two things you already know: Purdue level and exploitability. You don’t need a new tool for this — a decision matrix and your existing asset inventory will do.
Where does the affected device sit?
An advisory affecting a Level 0/1 device — the PLC or drive doing the actual control — that’s reachable only from a segmented Level 2 network behaves very differently than the same CVE in a device sitting on a flat network with a path to Level 3 or higher. Purdue level alone doesn’t tell you risk, but it tells you blast radius and, critically, it tells you what a compensating control can realistically achieve. You can often firewall your way around exposure at Level 2/3. You usually cannot firewall your way around exposure when the vulnerable function sits directly in the control loop and the HMI operator needs day-to-day access to it.
How exploitable is it, really?
KEV-tagged is the loudest signal — it means active exploitation is confirmed, not hypothetical. After that, weight in: does exploitation require local network access or is it internet-reachable in typical deployments; does it require authentication; is there public proof-of-concept code; and does your actual deployment expose the vulnerable service at all (a lot of advisories describe a default configuration your integrator disabled years ago). CVSS base score is a poor stand-in for this — it’s designed for IT context and routinely over- or under-states real OT risk. Read the advisory’s exploitability narrative, not just the number.
Cross those two axes and you get four rough buckets:
- KEV-tagged, low Purdue level, reachable — patch now, or take the asset offline. This is the bucket insurance clauses and customer contracts are actually written for.
- KEV-tagged but well-segmented — compensating control immediately, patch at next window.
- Not KEV-tagged, high severity score, low Purdue level — compensating control, scheduled patch, reassess if it gets added to KEV later.
- Not KEV-tagged, well-segmented, low real-world exposure — formally accept, document why, set a review date.
The output for every advisory, without exception, should be a dated entry in a decision log: which bucket, who decided, what action, by when. That log is what you hand an auditor, an insurer, or a customer security team when they ask how you handle advisories. “We reviewed it and decided to wait” is a fine answer if it’s written down with a rationale. It’s a bad answer when it only exists as institutional memory.
The compensating-control template for the PLC that can’t come down
This is the scenario that breaks most triage processes: the affected PLC is running a line that can’t stop until the next planned shutdown, which might be weeks or months out. You need a compensating control that’s real, not a compliance fig leaf. A workable template looks like this:
- Isolate the exposure path. If the CVE requires network access to a specific port or service, restrict it at the switch or firewall to only the engineering workstations that legitimately need it — not “the plant network,” a named list of IPs.
- Increase monitoring specificity. Add or tune an IDS/IPS signature or SIEM alert rule specifically for traffic patterns matching the exploit, not just generic anomaly detection. If you can’t detect exploitation attempts, you can’t claim the compensating control is working.
- Restrict engineering access. If the vulnerability lives in engineering software or firmware upload paths, lock down who can push configuration changes during the exposure window, and log every session.
- Set a hard patch date tied to the shutdown schedule. Not “eventually” — the actual planned outage date, in the decision log, with an owner.
- Re-verify before closing it out. When the patch finally happens, confirm the compensating controls get removed or downgraded — permanent “temporary” firewall rules are how OT networks accumulate technical debt nobody remembers the reason for.
None of this requires new headcount or a six-figure tool purchase. It requires treating advisory response as an operational process with owners and deadlines, the same way you’d treat a safety incident report or a quality deviation. CISA isn’t going to slow down the advisory pace, and KEV additions touching OT hardware aren’t a passing trend — they reflect where attackers have actually found value. Plants that build a real triage discipline now will meet contract and insurance deadlines as a byproduct of normal operations. Plants still running the spreadsheet-and-a-shrug method will keep discovering, advisory by advisory, that “we’ll get to it” isn’t actually a policy.
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.
