Ask any industrial operator to show you their complete list of OT assets — every PLC, RTU, HMI, intelligent field device, and network switch connected to their control systems — and most will hesitate. Some will produce a spreadsheet last updated three years ago. A few will not know where to begin. Almost none will be able to demonstrate that what is on paper matches what is actually running on the network.
This is not a technology failure. It is a governance and risk management failure — and it leaves every other security control built on a foundation that has not been verified. You cannot patch equipment you do not know exists. You cannot segment a network you have not mapped. You cannot prioritise vulnerabilities without understanding which assets are critical to safety, production, and business continuity. The inventory is not one control among many — it is the precondition for all of them.
The Visibility Paradox
The modern industrial environment is a complex hybrid of legacy controllers that have been running for twenty years, smart sensors installed last quarter, engineering workstations connected to both OT and IT networks, and cloud-connected gateways added to support remote monitoring. Each layer was added incrementally, often by different teams, different vendors, and under different management regimes. Nobody sat down to draw the complete picture — and now nobody has it.
This creates what practitioners call the "visibility paradox": organisations invest in sophisticated monitoring and detection tools, but the tools cannot protect what they do not know about. A passive network monitor discovers traffic on a subnet and flags an unknown device — but the security team does not know whether it is an old HMI that was never decommissioned, a vendor laptop left connected after a maintenance job, or a compromised system. Without the inventory baseline, every unknown device is a potential threat and a potential false alarm simultaneously.
Many organisations discover equipment during their first proper asset inventory exercise that nobody on the current team knew was connected. These are not exceptions — they are the rule.
Why OT Asset Inventory Is Harder Than IT
IT asset management is a mature discipline with well-established tools. CMDB platforms, network scanners, and endpoint management agents make it possible to maintain a reasonably accurate inventory of servers, laptops, and network equipment.
OT environments do not offer the same conveniences. Three challenges make the problem significantly harder.
Legacy systems with no discovery support. A PLC from the 1990s running a critical pump or compressor has no agent, no SNMP interface, and no network-accessible management plane. It simply executes its ladder logic. Discovering it requires either passive traffic analysis — watching for its Modbus or PROFINET packets on the network — or manual inspection with a scan tool that understands industrial protocols. Active scanning with standard IT tools (nmap, Nessus) is dangerous in OT environments: unexpected ICMP or TCP packets can crash older controllers that were never designed to handle unsolicited network traffic.
Proprietary protocols and vendor fragmentation. A single production facility may run a Siemens SIMATIC DCS, Rockwell ControlLogix PLCs, Yokogawa field transmitters communicating over HART, Beckhoff EtherCAT motion controllers, and a mix of Modbus TCP and DNP3 devices for utilities monitoring. Each protocol has different discovery mechanics. No single off-the-shelf IT tool understands all of them. Specialist OT asset discovery tools (Claroty, Nozomi, Dragos, Cisco Cyber Vision) are designed to handle this fragmentation through passive protocol-aware fingerprinting.
Dynamic environments at slow pace. OT networks change slowly compared to IT — but they do change. A device is added during a shutdown and never recorded. A firmware update changes a device's fingerprint. A vendor replaces a failed HMI with a newer model during an emergency call-out. Each unrecorded change erodes the accuracy of the inventory until the record no longer reflects reality.
The Foundation of All Other Security Controls
Every OT security framework — IEC 62443, the NIST Cybersecurity Framework, the NCSC's OT guidance, and NIS2 implementing measures — identifies asset inventory as a foundational requirement. The logic is direct: risk management requires knowing what you are managing.
| Security Control | Why It Depends on Asset Inventory |
|---|---|
| Vulnerability Management | You cannot assess CVEs for assets you do not know exist. Unidentified assets are unpatched assets. |
| Network Segmentation | Segmentation zones must be defined around known assets. Unknown devices create uncontrolled traffic paths between zones. |
| Patch Management | Patch schedules require knowing firmware versions. Unknown devices with known vulnerabilities create silent exposure. |
| Incident Response | During an incident, responders need to know what "normal" looks like. Without a baseline inventory, anomalies cannot be identified. |
| Access Control | You cannot apply least-privilege access policies to assets that are not in any system of record. |
| NIS2 Compliance | Article 21 requires documented risk management measures. An inventory is the prerequisite for all documented risk assessments. |
Passive Discovery: The Right First Tool
The most practical starting point for most operators is passive network monitoring: deploy a sensor (physical or virtual) on a SPAN port of the OT network switch, and let it listen. Specialist tools like Claroty xDome, Nozomi Networks Guardian, and Dragos Platform collectors will automatically fingerprint devices as they communicate — identifying vendor, model, firmware version, and communication patterns without sending a single packet to the OT network.
This approach is safe, non-disruptive, and typically reveals the full scope of the problem within days. In a medium-complexity production environment, passive discovery commonly identifies 40–70% more devices than were in the existing documentation.
Passive discovery alone won't give you a complete picture. A standby controller that isn't actively communicating won't appear. Neither will a backup HMI, or an engineering workstation that was powered off during maintenance. To fill those gaps, I'd query DCS and SCADA configuration databases directly — they often hold device lists that nobody thinks to export. Physical walkdowns matter too, especially in older plant areas where legacy equipment predates the network and never shows up on any scan. And cross-referencing with the CMMS is worth the effort: maintenance management systems often have equipment records that go back further than the OT network itself, and they sometimes contain assets that appear nowhere else.
Defining Criticality: More Than a List
A raw list of assets — vendor, model, IP address, firmware — is necessary but not sufficient. To make the inventory actionable for risk management, each asset needs a criticality classification that captures its operational and safety significance.
A practical three-tier approach works well for most operators:
| Tier | Definition | Examples | Implication |
|---|---|---|---|
| Tier 1 — Critical | Failure causes safety hazard or major production loss | Safety Instrumented Systems, primary DCS controllers, main historian | Highest patch priority; must have offline backup; incident response playbook required |
| Tier 2 — Important | Failure causes significant disruption but no safety hazard | Secondary PLCs, HMI workstations, field control panels | Standard patch cycle; monitored continuously; restoration procedures documented |
| Tier 3 — Supporting | Failure causes minor disruption; redundancy typically available | Network switches, engineering laptops, remote I/O modules | Regular inventory check; patched in normal maintenance windows |
A common mistake: Operators classify devices based on how difficult they are to patch rather than their safety and production criticality. This inverts the logic — the most critical devices deserve the most attention, not the least, even when patching them is operationally complex.
Mapping Data Flows: From Inventory to Baseline
Once assets are discovered and classified, the next step is understanding how they communicate. Data flow mapping answers the question: which devices talk to which other devices, using what protocols, and at what frequency?
This matters for two reasons. First, it enables network segmentation decisions — you can only draw meaningful zone boundaries if you understand the traffic that must cross them. Second, it establishes the behavioral baseline that anomaly detection depends on. When a PLC that normally communicates only with its HMI and historian suddenly starts sending packets to an engineering workstation at 2am, that deviation is only detectable if you know what normal looks like.
The Living Document Problem
The most common failure mode for OT asset inventories is not building one — it is building one and then not maintaining it. A spreadsheet created during a security assessment and filed away becomes obsolete within months. Devices are added, replaced, and reconfigured. Firmware is updated. Vendors install temporary access equipment that never gets removed. Within a year, the inventory may be less accurate than no inventory at all — because it creates false confidence.
An effective inventory is maintained continuously, not episodically. The practical mechanisms for keeping it current: passive monitoring with alerts the moment a new device appears on the network, which triggers a classification and approval workflow before the device is accepted into the inventory. Any planned change to the OT network should update the inventory as part of the change control process — not as an afterthought. Quarterly reviews of Tier 1 and Tier 2 assets specifically: firmware version, communication patterns, access credentials. Annual physical walkdowns to check that what's in the system matches what's on the plant floor. And a decommissioning procedure where assets removed from service are marked inactive rather than deleted — that audit trail matters when a regulator asks you to show the history.
From Spreadsheet to Situational Awareness
The maturity journey for OT asset inventory runs through four recognisable stages. Most industrial operators are in Stage 1 or early Stage 2. Moving to Stage 3 is the goal for any organisation with serious OT security obligations.
Getting from Stage 1 to Stage 3 is achievable within six to nine months for most single-site operators, and within twelve to eighteen months for complex multi-site environments. The technology exists and is mature. The real work is governance: establishing who owns the process, what the workflow is for new device approvals, and how changes are recorded.
A Starting Checklist
For operators who need to get moving now, these are the minimum steps to establish a credible foundation:
Deploy a passive OT network sensor — even a trial with a commercial tool will show you what you actually have versus what you thought you had, and that gap is usually instructive. Export device lists from your DCS, SCADA, and CMMS and cross-reference them with passive discovery results. Assign one named person as the inventory owner; without that accountability it tends to drift. Classify your twenty most critical assets by safety and production impact before you try to classify everything — getting those right first matters more than having a complete but undifferentiated list. Document all current vendor remote access paths. In my experience this step surfaces more surprises than any other. Set up alerts for any new device appearing on the OT network. And schedule a quarterly review before you have the perfect system in place — the review discipline is more valuable than waiting for perfect tooling.
The goal is not a perfect database before you do anything else. It is getting visibility — the first, essential step that makes every subsequent security action more effective and more credible.