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 is not sufficient for a complete inventory. Devices that are not communicating at the time of the scan — a standby controller, a backup HMI, an engineering workstation powered off during maintenance — will not appear. A comprehensive approach combines passive discovery with:
- Active querying of engineering systems — DCS and SCADA configuration databases often hold device lists that can be exported and cross-referenced
- Physical walkdowns — especially in areas with legacy equipment not visible on the network at all
- Integration with CMMS — maintenance management systems often have equipment records that predate the OT network
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 are:
- Passive monitoring with alerts when new devices appear on the network — these trigger a classification and approval workflow before the device is accepted
- Change management integration — any planned modification to the OT network updates the inventory as part of the change control process
- Quarterly review of all Tier 1 and Tier 2 assets — verify firmware version, communication patterns, and access credentials
- Annual physical walkdown — confirm that what is in the system matches what is on the plant floor
- Decommissioning procedure — assets removed from service are formally marked inactive, not simply deleted, to preserve the audit trail
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 period with a commercial tool will show you what you have
- Export device lists from your DCS, SCADA, and CMMS — cross-reference with passive discovery results
- Assign an owner to the inventory — one named person responsible for its accuracy
- Classify your top 20 most critical assets by safety and production impact
- Document all current vendor remote access paths — this often surfaces the biggest surprises
- Set up alerts for any new device appearing on the OT network
- Schedule a quarterly review cadence before you have the perfect system in place
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.