The Gap Between Getting the Advisory and Knowing You're Affected
You subscribe to CISA alerts. The advisory lands in your inbox: "CVSS 9.8 — affected versions of [PLC product] prior to V7.2.1." Critical vulnerability. Remote code execution via the web interface.
Now what?
If you're in IT, you query your endpoint management tool, get a list of every machine running the affected version, and start patching. If you're in OT, you probably don't have that capability. ICS firmware version tracking is the missing piece between advisory awareness and actual exposure assessment.
You have some number of these PLCs deployed. Installed over years, at different firmware versions, by different commissioning teams. Some may have been updated. Some definitely haven't. You have no centralised system that tells you which firmware version each one is running.
This is the advisory matching problem in OT.
Why It's Harder in OT Than IT
In IT, agents solve this. SCCM, Intune, CrowdStrike — they all report software versions back to a central database. You know, in real time, what's running on every managed endpoint.
OT devices don't run agents. A ControlLogix chassis doesn't call home with its firmware version. A Siemens S7-1500 doesn't register itself with an inventory database. The only way to know the firmware version on an OT device is to ask it directly — by connecting to it with the engineering software or by reading it from the device's properties page.
There's also no common protocol for firmware version reporting across vendors. Each PLC family has its own way of exposing this information, through its own engineering software, with its own version number format.
And then there's the operational reality: you can't always connect to every controller on demand. Some PLCs are only accessible during planned maintenance windows. Some are in remote locations. Some are running processes that make a failed connection attempt unacceptably risky.
What the CSAF version_range Field Enables
CSAF 2.0 — the machine-readable advisory format published by CISA and major ICS vendors — includes structured version range data. An advisory in CSAF format doesn't just say "prior to V7.2" in natural language. It encodes the affected version range in a structured field with specific operator syntax: vers:generic/>=5.0|<7.2.1.
This matters because it enables automated matching. If you have a database of your deployed firmware versions, you can run them against CSAF version_range data and get a list of confirmed exposures without reading advisory text manually.
The catch is the "if you have a database of your deployed firmware versions" part. That's still the hard piece. But the advisory side of the problem is solved — the data is there, structured, for vendors that publish CSAF. The asset data side needs work.
Practical Approaches to Firmware Tracking
Commissioning records as baseline. Every properly commissioned OT system should have a Factory Acceptance Test (FAT) or Site Acceptance Test (SAT) document that records the firmware version of every device at time of installation. This is your baseline. Even if it's five years old, it tells you the version each device started at.
Periodic manual audit. For sites where a real-time query isn't feasible, a scheduled annual or semi-annual firmware audit is realistic. Connect to each controller with the engineering software, record the firmware version, update the inventory. Not glamorous, but it works.
Engineering software project files. Studio 5000 project files, TIA Portal project files, and their equivalents for other vendors store controller properties including target firmware version. These don't tell you what's actually running on the physical controller, but they're a useful cross-reference — if the project file targets V7.0 and was last uploaded in 2021, and no firmware updates have been applied since, you have a reasonable estimate.
Network-passive discovery. Tools like Claroty and Dragos can often extract firmware version from device communications — some protocols exchange version information during handshake. This gives you passive firmware visibility without interrogating devices directly.
The SBOM Angle
ICS firmware version tracking is about to get more complex — in a useful direction. Software Bill of Materials (SBOM) for OT firmware means that when a vendor publishes an SBOM for their PLC firmware, you can see not just the firmware version but the underlying software components: which RTOS, which communication stack, which third-party libraries, at which versions.
That matters because OT devices are routinely affected by vulnerabilities in third-party components — OpenSSL, FreeRTOS, embedded TCP/IP stacks — before the PLC vendor has published their own advisory. If you have SBOM data for your deployed firmware versions, you can assess exposure to these upstream vulnerabilities without waiting for the vendor to publish.
SBOM adoption in OT is early. A handful of vendors have started publishing them. Regulatory pressure from NIS2 and US Executive Order guidance is pushing this forward. But the groundwork — knowing your firmware versions — needs to happen before SBOM data can be useful to you.
The Honest State of Play
Most OT sites have partial firmware version data. Some controllers are well-documented, some are mysteries. Closing that gap doesn't require expensive tooling. It requires a decision to do the manual work, plus a spreadsheet you actually maintain.
The goal is that when the next CVSS 9.8 advisory lands, the answer to "are we affected?" takes hours, not weeks.
---
If you want advisory monitoring without the manual work, OTWarden monitors CISA, Siemens ProductCERT, Rockwell, Schneider, ABB, BSI, and more — filtered to your equipment watchlist. Start a free 14-day trial — no card required.