How do organisations know whether OT asset inventory is good enough?

Inventory is good enough only when it ties devices to communication paths, owners, and enforcement points, not just to IP addresses. If teams cannot explain what a device talks to, who is responsible for it, and how it is isolated, the inventory is incomplete for security purposes. Visibility must support action, not just reporting.

Why This Matters for Security Teams

OT inventory is not a spreadsheet exercise. Security teams need an asset picture that supports containment, maintenance, segmentation, and incident response. A list of device names or IP addresses does not tell operators where lateral movement could occur, which assets are safety-critical, or which communications are normal versus suspicious. That is why guidance such as the NIST Cybersecurity Framework 2.0 places emphasis on governance, asset understanding, and risk treatment rather than passive discovery alone.

The practical question is whether the inventory can drive decisions. Can a team isolate a controller without breaking production? Can it identify the owner for a remote sensor or unmanaged workstation? Can it tell whether a newly discovered device is authorised, redundant, or exposed through a vendor path? If the answer is no, the inventory may be useful for reporting but not for defence. OT environments also complicate this because legacy protocols, flat networks, and uptime constraints often mask incomplete data.

In practice, many security teams discover inventory gaps only after a maintenance event, unplanned outage, or intrusion has already forced them to ask where a device lives and what it depends on.

How It Works in Practice

A good-enough OT inventory combines discovery, context, and enforcement. Discovery identifies what exists. Context explains what it does. Enforcement shows how the organisation can control it. That usually means linking each asset to a function, owner, location, firmware or software version, protocol exposure, and trust zone. For OT, communication mapping matters as much as naming. A device may be known, but if its peer relationships and control dependencies are unknown, the inventory still leaves security blind spots.

Teams commonly build this through a mix of passive network monitoring, engineering records, CMDB data, vendor maintenance schedules, and manual validation from plant and operations staff. Passive methods are preferred in many OT settings because active scanning can disrupt fragile devices. However, passive-only approaches often miss intermittently connected assets, serial-to-IP gateways, shadow systems, and temporary vendor access paths. Current practice suggests reconciling technical findings against operational ownership and safety impact, not treating any single source as authoritative.

• Identify every asset class, including PLCs, HMIs, historians, engineering workstations, gateways, and remote access tooling.
• Map each asset to a business or safety owner, not only a technical administrator.
• Record communications, dependencies, and permitted protocols so isolation is feasible.
• Mark enforcement points such as firewalls, jump servers, allowlists, and remote access controls.
• Review whether the inventory supports detection, patching, and segmentation decisions.

For operational resilience, this also means understanding how an asset is used during start-up, shutdown, and maintenance windows. An inventory can look complete while still missing the temporary paths that appear during work orders or vendor support sessions, which is why network telemetry and change records should be compared routinely. In OT environments with mixed legacy and modern systems, these controls tend to break down when passive monitoring is the only source of truth because hidden dependencies and undocumented maintenance access remain invisible.

Common Variations and Edge Cases

Tighter inventory requirements often increase operational overhead, requiring organisations to balance security precision against plant uptime and engineering effort. There is no universal standard for what “complete enough” means in OT, so the threshold should be tied to risk and use case rather than to raw asset counts. For a small, stable site, a well-maintained inventory plus network zoning may be sufficient. For a high-consequence facility, the bar is higher because response time, safety impact, and vendor exposure all raise the cost of uncertainty.

Edge cases usually involve assets that are hard to classify: transient engineering laptops, shared workstations, serial-converter boxes, portable diagnostic tools, and externally managed devices. These often sit outside normal discovery and ownership workflows. Another common gap is passive assets that rarely speak unless something is wrong, such as backup systems or dormant controllers. Best practice is evolving on how much metadata should be mandatory, but at minimum teams should be able to answer who owns the asset, what it talks to, and what happens if it is removed or isolated.

Where OT environments include remote service access, the inventory should also reflect the identity and access path used by vendors. That is especially important when segmentation, break-glass access, or privileged credentials are involved, because the enforcement point is part of the asset picture, not an afterthought. In highly dynamic plants, this guidance breaks down when change control is weak and device state changes faster than records are updated.

Related resources from NHI Mgmt Group

• How do organisations know whether SaaS usage data is good enough for governance decisions?
• How do identity teams know whether their application inventory is good enough?
• How do organisations know whether mobile asset controls are actually working?
• How should organisations decide whether OT PAM controls are mature enough?