Most OT asset inventories are built to answer an audit question: “what’s out there?” That’s the wrong design goal. The question that actually matters arrives at 4pm on a Thursday when a new ICS advisory lands with a CVE now sitting in CISA’s Known Exploited Vulnerabilities catalog, and someone in security operations needs to know, by end of day, whether three PLCs running the same affected firmware need the same response. If your inventory can’t answer that question directly, it’s a document, not a tool.
CISA’s continued push toward structured, machine-readable OT asset data — extending guidance that’s been building for several years now and accelerating as KEV entries increasingly include industrial control system CVEs — is really a push toward exactly this capability. The agency isn’t asking plants to build prettier spreadsheets. It’s asking them to build data that a triage process can query automatically, the same way IT vulnerability management has worked for years with CMDB-driven risk scoring. OT has been slower to get there, for reasons that are mostly legitimate: asset diversity, safety constraints, and vendor patch cycles that don’t map cleanly onto IT’s monthly cadence. But “it’s hard” isn’t a reason to keep running triage by tribal memory and a shared Excel file.
The gap isn’t data collection. It’s data structure.
Plenty of plants have decent asset visibility now, thanks to passive network monitoring tools that fingerprint devices, protocols, and firmware versions without needing agents on legacy equipment. The gap is that this data usually lives in a tool built for detection, not decision support, and it rarely gets fused with the context that actually drives a patch/isolate/accept-risk call. An asset record that lists “Rockwell ControlLogix, firmware 32.011” is necessary but nowhere near sufficient. You need a data model with enough dimensions that when a CVE hits, the record itself tells you what to do — or at least narrows it to a defensible short list.
At minimum, each asset record needs to carry:
- Protocol exposure — what it talks (EtherNet/IP, Modbus TCP, OPC UA, proprietary serial-to-Ethernet gateways) and, critically, what segment it talks on.
- Network reachability — is it reachable from the IT/OT boundary, from a jump host only, from the internet via a poorly-documented remote access tool, or is it genuinely air-gapped. Most “air-gapped” claims don’t survive a real network trace.
- Safety function — does this device participate in a SIS, an interlock, or anything with a SIL rating. This single field should have veto power over patch timelines.
- Vendor patch cadence and support status — does the vendor ship patches at all for this model, how often, and is it still under support. A lot of ICS advisories affect end-of-life hardware where “patch” isn’t actually an option on the table.
- Existing compensating controls — is there already a firewall rule, an allow-list, a monitoring rule, or a physical control that reduces exploitability today, independent of whether the CVE ever gets patched.
- Production criticality and change-window feasibility — what does downtime cost this line, and when is the next planned outage where a patch could even be applied without a special exception.
That’s the model CISA’s structured-inventory guidance is nudging toward, even if it doesn’t say it in these exact terms: fields that map directly onto risk decisions, not just fields that describe hardware. IEC 62443’s zone-and-conduit thinking is a useful skeleton for the exposure and reachability fields specifically — if you already have zones defined, you’re most of the way to the reachability field for free.
The same CVE, three assets, three right answers
Here’s where the framework earns its keep. Imagine an advisory drops for a vulnerability in a widely deployed HMI/SCADA software package, now added to KEV, remote-code-execution class, no authentication required. Three plants — or three lines in the same plant — run the affected version.
Asset one sits on a segmented OT VLAN, no direct route to the IT network, reachable only from an engineering workstation that itself requires jump-host access with logged sessions. It doesn’t touch a safety function. Vendor has a patch available, and there’s a maintenance window in about a week. Correct answer: patch on schedule. The exposure is already low, so there’s no urgency to break a maintenance window for an emergency change — but there’s also no reason to leave it unpatched once the window opens.
Asset two is functionally identical hardware and software, but it’s on a flat network segment that also carries traffic from a remote-access tool used by a third-party integrator, and it’s reachable, in practice, from a broader corporate segment because of a firewall rule nobody’s revisited. No safety function, vendor patch exists, but the next scheduled outage is a while off. Correct answer: isolate now, patch later. Tighten the firewall rule, kill or heavily restrict the remote-access path, and treat the patch as the durable fix rather than the emergency one. The compensating control buys the time the maintenance schedule doesn’t have.
Asset three is the same software version but running on end-of-life hardware the vendor no longer patches, and it’s wired into an interlock that’s part of a documented safety function. Correct answer here is neither “patch” nor a quick network isolation — it’s a formal risk acceptance with compensating controls layered on: strict access control, enhanced monitoring for exploitation attempts, and a plan (with an actual budget line and timeline) to replace the hardware, because “accept risk” on a safety-relevant asset is a decision that needs to be documented, time-bound, and revisited, not a permanent shrug.
Same CVE. Same KEV entry. Three different, defensible answers — and the only reason you can generate them in hours instead of weeks is that the data needed to reason through exposure, safety impact, patchability, and existing controls was already sitting in structured fields instead of scattered across someone’s memory of “oh yeah, that line’s on its own switch.”
What to actually do with this before the next advisory
Start by auditing whether your current inventory — however good the device discovery is — actually carries the six fields above in queryable form, not free-text notes. If it doesn’t, that’s the project, not “buy another scanning tool.” Second, get your safety and process engineering teams to formally sign off on which assets carry safety-function flags; this isn’t a call security should make alone, and it shouldn’t be guessed at. Third, build the triage logic as an actual decision tree or scoring rubric ahead of time — reachability plus safety function plus patch availability plus criticality — so that when KEV adds an ICS CVE, someone can run the query and get a first-pass answer before the incident call even starts. CISA’s structured-data push gives you the format. The decision model on top of it is still yours to build, and it’s the part that actually determines whether the next advisory is a controlled afternoon or a scrambled week.
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.
