You cannot manage a vulnerability in a system whose existence you do not know. A current asset inventory is therefore one of the most underestimated, yet most fundamental building blocks of an OT security programme — and an explicit requirement within IEC 62443-2-1.
What belongs in an OT asset inventory?
A useful inventory contains more than just an IP address and a name. For each asset, at least the following is relevant:
- Type and function (RTU, IED, station controller, engineering workstation, industrial switch).
- Vendor, product model and firmware or software version.
- Physical and logical location (which substation, which zone).
- Supported protocols and open ports.
- Person responsible for maintenance and patch policy.
- Lifecycle status: actively supported, end-of-life announced, or already end-of-life.
Why this is harder than in IT
In an IT environment an agent can be installed on every endpoint to inventory automatically. In OT that is often not possible or desirable: a lot of equipment has limited computing power, does not support extra software, or may not be actively queried during operation for safety reasons. Inventory in OT therefore often combines passive network observation, documentation from engineering projects and manual verification during maintenance windows.
Practical approach
- Start with existing documentation. Engineering drawings, single-line diagrams and project handovers often already contain much of the required information.
- Supplement with passive network observation. An OT-aware monitoring system can identify equipment, protocols and communication patterns without actively querying.
- Verify during planned maintenance. Use maintenance windows to carry out physical checks and update documentation.
- Link the inventory to vulnerability information. Once it is known which products and versions are in use, this can be linked to CVEs, KEV entries and ICS advisories to determine relevance.
- Repeat periodically. An asset inventory is never "done"; plan periodic updates, especially after changes or expansions.
Practical example
A grid operator discovers, via passive monitoring, an industrial switch in a substation that did not appear in the original engineering documentation — probably added during a later expansion without a full update of the documentation. Because the asset inventory is linked to the vulnerability database, this specific model turns out to be subject to a critical vulnerability for which a patch is now available.
Common mistake
Carrying out a one-off inventory at the start of a project and not updating it afterwards. After a few years the documentation no longer matches the actual situation, precisely when it is needed most: during an incident.