Read enough CISA ICS advisories in a row and you’ll notice the language has changed. It used to be mostly CVE-and-CVSS: a stack overflow here, a hardcoded credential there, a score, a vendor patch link. Increasingly, the root cause line reads differently — “the product uses default credentials by design,” or “the vendor’s architecture does not support authentication on this protocol,” language that traces straight back to CISA’s Secure by Design pledge and the push to get that philosophy written into federal procurement requirements. That’s not a cosmetic shift. It means a growing share of what shows up in your advisory feed isn’t a patchable bug at all. It’s a design decision the vendor made years ago that CISA is now naming out loud.
That distinction matters enormously for how a plant should respond, and most patch management processes weren’t built to tell the difference. If your process treats every advisory as a ticket that says “patch by X,” you’re going to either burn unplanned downtime on things that don’t warrant it, or worse, wave off something that genuinely does. Neither is defensible when an auditor or an insurer asks you to show your work.
Why “secure by design failure” changes the math
A traditional CVE — a buffer overflow in an HMI’s web server, say — has a patch. You apply it, you verify, you’re done. A secure-by-design finding is different in kind. If an advisory says a PLC’s engineering protocol has no authentication at all, there’s often no patch coming that fixes that in the field; the vendor may offer a firmware update that adds an authentication option, but it might require re-engineering how the device talks to your MES or SCADA layer, and older hardware revisions may not support it at all. These findings tend to describe systemic exposure rather than a single exploitable flaw, which means the fix is architectural, not a checksum you push out during a maintenance window.
Practically, this means your triage question isn’t just “is there a patch and how bad is the CVE.” It’s “is this a bug we can close, or a design limitation we now have to manage indefinitely with compensating controls.” Those are different workflows, different budget conversations, and different audit artifacts.
A decision framework that isn’t “patch everything, now”
Start by sorting every new advisory into one of three buckets before you argue about timing.
Bucket one: exploitability requires network reach you don’t have
Check whether exploitation requires direct network access to the device, adjacent-segment access, or physical/serial access. A remote-code-execution finding in an HMI’s exposed web interface is a different animal on a flat plant network than it is on a device sitting behind a properly configured industrial DMZ with no route from IT, no internet egress, and access restricted to an engineering workstation on the same segment. If your zone and conduit model (ISA-95/IEC 62443 terms, and worth using in your documentation) genuinely blocks the attack path CISA describes, you have a real basis for deferring the patch to the next planned maintenance window — provided you can prove the segmentation, not just assert it.
Bucket two: it’s a design gap with no patch, only mitigations
If the advisory is flagging a secure-by-design failure — no authentication, cleartext protocols, lack of input validation baked into the architecture — stop looking for a patch to apply and start building a compensating-control record instead. That typically means some combination of network segmentation, application allow-listing on the HMI or engineering workstation, and monitoring tuned to detect the specific behavior the advisory describes (unexpected write commands to a PLC, unusual engineering-software traffic, protocol anomalies). Document what you put in place, why it addresses the specific exposure named in the advisory, and who signed off. This is the bucket that’s growing fastest, and it’s the one your existing patch process probably has no lane for.
Bucket three: it genuinely can’t wait
Some findings do warrant an unplanned outage: active exploitation in the wild noted by CISA, a device with no viable compensating control (internet-facing, unsegmented, safety-relevant), or a CVE affecting a function your process actually depends on for correct operation, not just security posture. These are rare relative to advisory volume, but they’re real, and the cost of misclassifying one into bucket two is the scenario every plant manager actually loses sleep over.
Documentation is the product, not an afterthought
Insurance underwriters and auditors increasingly want to see a decision trail, not just a patched/unpatched status. For every advisory you defer, keep a record that states: the CVE or advisory ID, the specific compensating control applied, the reasoning for why that control addresses the named attack path, who approved the deferral, and the date it’s scheduled for reassessment. That last field matters — a compensating control isn’t a permanent substitute for remediation, it’s a bridge, and treating it as indefinite is the kind of thing that looks bad in hindsight after an incident.
Tie this back to your MES patch advisories too, since the same logic applies there. An MES vulnerability tied to a reporting module with no connection to the control network doesn’t carry the same urgency as one in a service that brokers commands down to line PLCs. Evaluate MES CVEs against your actual system architecture and data flows, not against the CVSS score in isolation.
What this means for how you staff the job
None of this works as a side task for whoever’s free on Tuesday. Triaging advisories against your real network topology requires someone who understands both the control system architecture and the vendor’s disclosure language — increasingly a job description that blends controls engineering with OT security literacy. If you don’t have that person in-house, at minimum build the three-bucket habit into your existing change-management process and involve your integrator or MES vendor’s security contact when a secure-by-design finding shows up against something they configured. The volume of advisories isn’t going down, and reflexively shutting down for every one of them is not a sustainable security strategy — it’s a way to train your organization to stop taking advisories seriously at all.
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.
