The Inventory Problem in OT
Ask most OT engineers whether they have an accurate asset inventory and you'll get one of two answers. Either "yes, in theory" — meaning there's a spreadsheet from 2019 that was accurate when it was made — or a wry smile and "sort of."
This isn't a failure of effort. OT environments evolve over 15, 20, 30 years of operation in ways that IT environments don't. Equipment gets added during shutdowns, replaced piecemeal, upgraded one chassis at a time, or patched in as part of a late-night breakdown fix with whatever was in the spares store. The commissioning documentation from the original system integrator doesn't get updated when someone swaps an AB MicroLogix for a CompactLogix three years later because the original went end-of-life.
What you end up with is a physical plant that doesn't match the P&IDs, a network diagram that doesn't match the actual cable runs, and an asset inventory that's partially correct for the components that haven't changed.
For OT asset inventory purposes, this is the starting condition you're working from.
Why OT Asset Inventory Matters for Vulnerability Management
You cannot apply a CISA advisory to your environment if you don't know which version of firmware your PLCs are running. The advisory says "ControlLogix v32.013 and earlier" — but you have 200 ControlLogix chassis spread across three facilities, installed over 15 years, some upgraded and some not. Which ones are affected?
Without an OT asset inventory that includes product models and firmware versions, vulnerability advisories are theoretical. You can't prioritise, you can't remediate, and you can't tell your security manager or your auditor which systems are patched. The inventory is the prerequisite to everything else in OT vulnerability management.
Passive Discovery vs Active Discovery
The tooling debate in OT asset discovery usually comes down to passive vs active scanning.
Passive discovery tools — Claroty, Dragos, Nozomi, and others — sit on a network TAP or span port and listen to traffic. They build an asset inventory by observing communications. No packets are sent to the PLCs. For most OT environments, this is the right approach. Active network scanning can disrupt OT devices. Sending unexpected packets to a 20-year-old PLC can cause it to fault. The cautious default is: never scan OT devices actively without first confirming with the vendor that their product tolerates it.
Passive discovery has its own limitations. It only finds devices that are talking. A standby PLC with no active communications won't appear. Field instruments that only communicate during specific process states might appear intermittently. The inventory you get is better than nothing, but it's not complete.
The Practical Starting Point: Don't Wait for the Perfect Tool
You don't need a Claroty deployment to start your OT asset inventory. You need three things: commissioning documentation, an honest manual audit, and a spreadsheet.
Commissioning documentation is whatever was produced when the system was installed — system integration drawings, I/O lists, network diagrams, PLC configuration exports. This is your starting dataset. Even if it's 10 years old, it gives you the asset list and approximate firmware versions at the time of installation.
Manual audit means walking the floor with the commissioning docs and checking what's actually there. Compare the tag list to the physical hardware. Note where the physical reality doesn't match the documentation. This takes time and requires access during a suitable operational window, but for a medium-sized facility it's achievable in a few days with the right people.
CSAF version matching is a newer capability worth using. CISA and major vendors publish advisories in CSAF 2.0 format, which includes structured affected version ranges. If you have a firmware version for a specific product, you can match it against CSAF data to find out which historical advisories apply to that version. This is how you close the gap between "we have an inventory" and "we know which advisories affect our inventory."
What to Capture in the Inventory
At minimum: manufacturer, product family, model number, firmware/software version, location (facility, panel, loop), and network address if applicable. If you're managing it in a spreadsheet, those columns are sufficient to start advisory matching.
The version field is the most important and the hardest. PLCs store their firmware version in the project file or in the controller properties visible through the engineering software. Factory talk, Studio 5000, Simatic Manager, TIA Portal — all of these let you read controller properties including firmware version. If you're doing a manual audit, connect to each controller with the engineering software and record the firmware version directly.
The SBOM Angle
Software Bill of Materials (SBOM) is a concept that's starting to arrive in OT — the idea that PLC firmware has underlying software components (RTOS, communication stacks, third-party libraries) that themselves carry CVEs. Vendors are slowly starting to publish SBOMs for their products. When they do, your firmware version inventory becomes even more valuable — you can match your deployed versions against SBOMs to find indirect exposures.
This is still emerging in OT. But it's another reason to get your OT asset inventory in shape now, before the tooling catches up.
---
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.