OT visibility fails when inventory stops at make and model

At a glance

What this is: This is Dragos’s argument that OT visibility is incomplete when it stops at inventory and sensor coverage, because meaningful risk also lives in firmware, configuration, credentials, and software supply chain exposure.

Why it matters: For IAM and security teams, the practical lesson is that control gaps in identity, access, and configuration can sit outside traditional OT monitoring, so governance must extend across the full xOT environment.

Context

Visibility in xOT is not the same as having a device list. In operational environments, the real governance gap is that teams often know what exists but not how it is configured, who can modify it, or where the hidden dependencies sit across IT and OT.

That gap matters because control effectiveness depends on depth and reach. When identity, access, firmware, and supply chain details are missing, organisations are relying on partial control evidence rather than actual security assurance.

The article’s broader point is that xOT visibility now has to cover both assets and the software that drives them, which makes this a lifecycle and governance problem as much as a monitoring problem.

Key questions

Q: What breaks when OT asset inventory is incomplete?

A: Incomplete OT asset inventory breaks segmentation, vulnerability prioritisation, and incident response because security teams cannot reliably tell which devices exist, where they are, or what they connect to. In practice, that means legacy systems, vendor access paths, and unmanaged devices can remain outside policy boundaries and become lateral movement routes.

Q: Why do hidden credentials and access paths increase xOT risk?

A: Because process impact is often created by who can change devices, not just which devices exist. Embedded credentials, service accounts, and remote admin paths can alter operating state without touching classic sensor layers, so identity governance becomes part of operational assurance rather than a separate administrative concern.

Q: What signs show OT visibility is still incomplete?

A: Common signs include unknown assets, stale spreadsheets, missing firmware data, and a gap between what the network team sees and what the process owners can explain. If a team cannot answer who can touch a PLC, what changed on it, and whether the software chain is trusted, visibility is still partial.

Q: How should teams connect exposure management with supply chain assurance?

A: They should treat software and firmware risk as part of the same visibility programme as asset discovery. That means correlating SBOM data, binary analysis, and provenance checks with runtime asset intelligence so weaknesses are found before deployment and prioritised alongside live operational exposure.

Technical breakdown

Why make-and-model inventory is not OT visibility

A device inventory tells you what exists, but not how risky it is. In OT and xOT environments, two identical PLCs can have different firmware, different configuration drift, different access paths, and different operator credentials, which means they carry different exposure even when the hardware looks the same. Real visibility has to include state, privilege, and change history, not just classification. That is why asset discovery alone cannot answer the questions defenders actually need to manage process risk.

Practical implication: pair asset discovery with configuration, credential, and change tracking so inventory data becomes usable exposure intelligence.

How exposure expands from control room to xOT environment

Traditional OT thinking assumed a bounded control room with clear separations from IT. Modern xOT environments break that model because data, remote access, IoT devices, and hybrid infrastructure all influence operational outcomes. The attack surface now includes paths that never touch a classic OT sensor, which means visibility has to cross organisational and technology boundaries. If defenders only watch the plant floor, they miss the upstream systems that create operational risk.

Practical implication: build a visibility model that spans IT, cloud, connected devices, and OT rather than treating the control room as the whole environment.

Why supply chain and firmware analysis belong in visibility programmes

Software and firmware are part of the operational attack surface before deployment, not just after compromise. Build artefacts can carry vulnerable dependencies, unsafe provenance, or unwanted functionality long before a device reaches production, and network monitoring will not reveal those issues. That is why visibility in xOT now extends into binary analysis, SBOMs, and contributor provenance. In practice, this shifts governance left from runtime monitoring to pre-deployment assurance.

Practical implication: include firmware and software supply chain checks in OT governance so hidden weaknesses are found before they reach production.

NHI Mgmt Group analysis

Visibility debt is now an OT governance problem, not an inventory problem. Organisations that still treat discovery as a spreadsheet exercise are carrying blind spots in configuration, privilege, and software provenance. That is especially relevant where xOT systems blend physical process control with IT-connected dependencies, because the operational risk is created by what is missing from the governance model, not just what is missing from the asset list. Practitioners should treat visibility as a control domain, not a reporting output.

Identity and access detail are part of operational visibility. In environments where credentials, local access, and configuration changes can alter process behaviour, the boundary between OT monitoring and identity governance disappears. That is where NHI governance becomes relevant, because service accounts, embedded credentials, and machine access paths can become invisible control dependencies. Teams should manage those identities as part of exposure governance, not as a separate admin problem.

Software supply chain assurance is now a visibility requirement. Firmware and compiled code can carry risk that no sensor will see at runtime, which makes pre-deployment analysis a necessary complement to network and endpoint coverage. This widens the security programme from detection to assurance and ties OT risk management to build provenance, SBOM discipline, and source integrity. Practitioners should close the gap before the asset ships, not after it is already operating.

Full court exposure management is the right named concept for xOT, because the control objective is to see depth, width, and lifecycle risk as one problem. That means asset state, identity context, and software provenance all need to feed a single prioritisation model. For defenders, the takeaway is clear: if a control does not surface hidden exposure before impact, it is not yet visibility in the operational sense.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: Attack Surface Management Guide

What this signals

Full court exposure management: xOT programmes now need a single view that combines device discovery, access context, and software provenance, because the control failure is rarely limited to one layer. When visibility is fragmented, organisations can still pass an inventory check while missing the conditions that actually drive operational compromise.

Visibility programmes should increasingly be judged by whether they answer three questions at once: what the asset is, who can alter it, and what code or configuration it is running. That framing aligns OT governance with the realities of hybrid operations and reduces the chance that security teams mistake a directory for a control model.

For practitioners

• Expand asset discovery into exposure management Track firmware version, patch level, configuration drift, and operator access alongside make and model so asset records support risk decisions.
• Map xOT identities and credentials Inventory service accounts, embedded credentials, and administrative touchpoints that can alter PLCs, HMIs, and connected devices.
• Add software and firmware assurance Use SBOMs, binary analysis, and provenance checks to identify unsafe dependencies and hidden code paths before deployment.
• Unify IT, cloud, and OT visibility Correlate telemetry from across hybrid infrastructure so remote access, connected devices, and process assets are assessed together.

Key takeaways

• OT visibility fails when teams stop at inventory and network diagrams, because the real exposure is also in firmware, access, and configuration.
• The strongest evidence of the gap is that many programmes still cannot see service accounts or other machine access paths clearly enough to govern them.
• Practitioners should unify asset discovery, identity context, and software supply chain assurance so they find operational risk before it reaches production.

Key terms

• xOT: xOT is the broader operational technology environment that includes any connected system whose compromise can affect physical processes or high-impact operations. It extends beyond classic industrial controls to cameras, radios, badge readers, and other devices that may not appear on a traditional OT inventory but still carry material risk.
• Exposure management: Exposure management is the practice of identifying which assets are reachable by attackers and reducing that reach before exploitation occurs. For collaboration systems like SharePoint, it is not enough to know that a patch exists, because public accessibility changes the speed and likelihood of attack.
• Firmware Provenance: Firmware provenance is the ability to trace a deployed device image back to the exact source components, build steps, and signing process that produced it. It gives teams evidence that a patch was actually built, validated, and delivered rather than merely accepted upstream.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader security and resilience programmes.