If you run vulnerability management for an OT environment, you’ve probably noticed the rhythm has changed. CISA’s Known Exploited Vulnerabilities catalog used to feel like an IT compliance artifact that occasionally brushed up against industrial control systems. It doesn’t feel that way anymore. ICS advisories are landing more frequently, KEV additions increasingly name PLCs, HMIs, industrial VPN appliances, and engineering workstation software, and the required remediation dates are tight — often measured in days for federal civilian agencies, and treated by many auditors and cyber-insurance underwriters as the de facto industry clock even for private manufacturers who aren’t directly bound by Binding Operational Directive 22-01.
That last part is the trap. KEV deadlines were written for federal agencies. Nothing in the catalog legally forces a discrete manufacturer to patch a robot controller by a certain date. But “not legally required” and “safe to ignore” are very different things, and plenty of plant IT and security teams are discovering that their insurers, their customers’ supplier-security questionnaires, and their own corporate risk committees have quietly adopted KEV timelines as the expected standard anyway. So the pressure is real even where the mandate isn’t.
Meanwhile the plant floor hasn’t changed at all. You still can’t reboot a PLC mid-shift. You still have a change-control board, a validated recipe, a safety case, and a production schedule that doesn’t care what CISA published this week. The job isn’t to pick a side between “patch now” and “wait for the window.” The job is to build a triage process that makes the right call, fast, and leaves a paper trail an auditor will actually accept.
Why KEV and OT patch cycles were never going to line up naturally
KEV is built on a simple, defensible logic: these vulnerabilities are being actively exploited somewhere, right now, so remediate them before you’re next. That logic works cleanly for a fleet of externally facing web servers you can patch and redeploy in an afternoon. It works much less cleanly for a Level 1 or Level 2 device sitting on a production line, governed by ISA-95 layering and ISA-88 batch logic, where a “patch” might mean a firmware update that requires vendor revalidation, a control-loop retune, or a full IQ/OQ cycle before you’re allowed to put it back in service.
This is the structural mismatch every OT security program has to manage: KEV timelines are written in calendar days, and industrial change control is written in maintenance windows, shutdown schedules, and safety sign-offs. A plant that treats every KEV entry as an automatic “patch now” order will eventually cause an unplanned stop, a scrapped batch, or a safety incident — which is a worse outcome than an unpatched vulnerability with compensating controls in place.
A triage framework that holds up under both operational and audit scrutiny
The practical answer is a documented triage tier, applied consistently, that separates “this can’t wait” from “this rides the normal cadence.” I’d build it around four questions, asked in this order:
- Is the affected asset actually reachable from an exploit path? A KEV-listed vulnerability in an engineering workstation that’s air-gapped, behind a properly configured IEC 62443 zone/conduit architecture, and never touches the internet is a different risk than the same CVE on a device with a routable path from the corporate network or a remote-access VPN. Network segmentation evidence — firewall rules, VLAN diagrams, asset inventory from your OT visibility tooling — is your first and most important triage input.
- Does the vulnerability affect safety or production integrity, or just availability of a non-critical function? A remote-code-execution flaw in an HMI that also runs SIS-adjacent logic is not the same tier as a denial-of-service bug in a historian’s reporting module.
- Is there a compensating control you can stand up today without touching the control system? Firewall rule changes, disabling an unused service, tightening remote-access MFA, or isolating a conduit can often neutralize the exploit path without ever logging into the PLC. This is frequently the single most useful move: it buys you legitimate, documentable time until the next window.
- What does the vendor actually say? Check whether the OEM has confirmed exploitability on your specific firmware version, and whether they’ve published a validated patch or only a general advisory. Applying an unvalidated patch to a controller is its own risk category.
When it truly can’t wait
Some advisories genuinely justify breaking the maintenance schedule: internet-facing OT assets with a KEV entry and no available compensating control, confirmed active exploitation against your specific vendor/model combination, or anything touching a safety instrumented system with no isolation option. In those cases, invoke your emergency change process — every mature change-control program should already have one — get the abbreviated risk sign-off, and patch out of cycle. This should be rare. If it’s happening every month, your segmentation architecture needs work, not your patch process.
When it can ride the window
Everything else — which, in a well-segmented plant, is most KEV entries — gets a compensating control applied immediately and a scheduled remediation slotted into the next appropriate maintenance window: next planned downtime, next PM cycle, next validated firmware release from the OEM. The point isn’t “wait and hope.” It’s “reduce the exploitable risk now, remediate properly on a schedule that doesn’t blow up production.”
Document the decision, not just the patch
The single biggest gap in most plants’ KEV response is that they document the patch and forget to document the decision not to patch immediately. An auditor doesn’t just want to see that a CVE eventually got remediated. They want to see a dated risk assessment showing you knew about the advisory, evaluated exposure, applied a compensating control, and scheduled formal remediation on a defined timeline. Build a lightweight record for every KEV entry that touches your OT asset inventory: CVE and CISA advisory reference, affected asset(s) from your inventory, exposure assessment, compensating control applied and when, target remediation window, and sign-off authority. Keep it in whatever GRC or CMMS system you already use for change control — don’t invent a parallel process nobody will maintain.
This record does double duty. It satisfies the auditor asking about your vulnerability management program under frameworks like NIST 800-82 or IEC 62443-2-1, and it protects you internally when someone asks, six months later, why a KEV-listed CVE sat unpatched for a quarter. The answer “we assessed it, isolated it, and remediated it on the next planned outage” is a defensible security decision. Silence on the topic is not.
What to actually change this year
If CISA’s cadence keeps tightening — and there’s no real signal it’s slowing down — the plants that handle it well won’t be the ones that patch fastest. They’ll be the ones with an accurate OT asset inventory, real network segmentation they can point to, an emergency change path that’s actually been tested, and a triage habit that turns every new advisory into a same-day decision instead of a fire drill. Build that now, while the volume is merely steady, not later, when it’s constant.
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.
