OT Asset Visibility Guide: Discovery, Inventory and Monitoring

Most OT security programmes stall at the same point: nobody can say with confidence which controllers, HMIs, network devices and remote connections exist, what firmware they run and which process they affect. Without that, segmentation rules are guesses and advisories cannot be matched to devices. Building visibility in OT is harder than in IT because fragile devices can fail under scanning, serial and fieldbus networks hide assets from IP tools, and the people who know the plant are engineers rather than security staff. This guide covers discovery methods and their safety limits, protocol-aware inventory, the attributes worth capturing, taxonomies and criticality, integration with vulnerability and change management, keeping the inventory current, and how to measure progress. It is for OT security engineers, control engineers and asset owners in energy, water, manufacturing and other industrial sectors.

Key takeaways

• Passive first, active by exception. Protocol-aware passive monitoring is safe on any network; active queries can stop fragile controllers and need engineering approval, vendor-supported methods and a maintenance window.
• Capture what decisions need. The 2025 joint CISA guidance rates 14 attributes as high priority, from communication protocols and criticality to logging and user accounts.
• Criticality and zones make an inventory usable. A list of IP addresses does not tell you what to protect first; a taxonomy tied to process areas and ISA/IEC 62443 zones does.
• Visibility pays off through integration. Matching inventory to CISA's Known Exploited Vulnerabilities catalogue and vendor advisories, and tying every device change to change management, turns a spreadsheet into a control.
• Currency is the hard part. Require inventory updates for every device introduced or removed, including emergency changes, and alert on new or vanished devices.

What an OT asset inventory must answer

CISA and partner agencies define an asset inventory as "an organized, regularly updated list of an organization's systems, hardware, and software", and warn that "without an inventory, organizations do not know what they have and what should be secured and protected." NIST's energy sector asset management practice guide (SP 1800-23) puts it as "Having an accurate OT asset inventory is a critical component of an overall cybersecurity strategy." In practice, the inventory has to answer five questions quickly during normal work and during an incident:

• What is it? Vendor, model, role, firmware, operating system and serial number.
• Where is it? Site, process area, cabinet, Purdue level and ISA/IEC 62443 zone.
• What does it talk to? Protocols, ports, peers, conduits and remote access paths, including links to IT and the cloud.
• How much does it matter? Criticality to safety, production and regulatory obligations.
• Who owns and touches it? Engineering owner, integrator, vendor support route and the accounts that can change it.

MITRE ATT&CK for ICS (v20) offers a neutral vocabulary for device roles, with 18 asset types such as Programmable Logic Controller (A0003), Remote Terminal Unit (A0004), Intelligent Electronic Device (A0005), Data Historian (A0006), Safety Controller (A0010), Jump Host (A0012) and Data Gateway (A0009). Using these roles lets you map device types to the techniques that target them. For the wider OT architecture, see the OT Security Guide.

Discovery methods and their safety limits

The safety risk of active scanning is not theoretical. A University of Bristol study of ICS discovery tools (Samanis, Gardiner and Rashid, 2022) notes that active scanning "poses a risk of industrial process disruption" and "can put the control devices into stop mode", and reports that certain Nmap options drove a PLC into a failure state that needed a power cycle to recover. The joint Secure by Demand guidance for OT buyers (January 2025) asks manufacturers: "Can the product remain stable during security scans, such as vulnerability assessments or asset inventory tools?" Until the answer is yes and proven on a test bench, treat active techniques as a change.

• Approve: every active method needs sign-off from the engineering owner, a defined target list (never sweeps of a whole controller subnet) and a rollback plan for the process.
• Test: run the exact query, rate and tool version against a spare or test-bench device of the same model and firmware.
• Exclude: safety instrumented systems and protection relays unless the vendor explicitly supports the method.
• Register the scanner: discovery traffic looks like ATT&CK T0846 Remote System Discovery (and its sub-technique T0846.001 Port Scan). MITRE's detection guidance for T0846 recommends alerting only when the source is not authorised for discovery, so list your inventory tools as approved sources and alert on everything else.

Collection architecture and protocol-aware inventory

Passive visibility is only as good as its collection points. NIST SP 1800-23's reference design used sensors fed from SPAN ports and network taps, encapsulated serial communications in network protocols, and used a protocol converter to bring HART instrument data onto Ethernet.

• Placement: start at the switches that aggregate Level 2 supervisory traffic and Level 1 controller traffic, the industrial DMZ and remote access entry points. A sensor only at the IT and OT boundary misses east-west traffic between HMIs, engineering workstations and controllers.
• SPAN or tap: SPAN ports are quick to configure but can drop packets under load and depend on switch configuration staying correct; taps are passive hardware and do not drop, but installing one may need a short outage. Use taps on the highest-value links.
• Remote sites: substations, pump stations and well pads often have low bandwidth. Use local sensors that send metadata rather than full packets, or scheduled collection.
• Serial and fieldbus: devices behind gateways, protocol converters or RS-485 links never appear on Ethernet. Capture them from gateway configuration, project files or walkdowns.

Protocol awareness, meaning deep packet inspection of industrial protocols, is what separates OT visibility from generic network monitoring. In NIST's reference design, MAC addresses identified the manufacturer and decoded protocol fields gave model and serial number, which is how device fingerprinting works without touching the device. CISA's open source ICSNPP project, copyrighted by Battelle Energy Alliance (operator of Idaho National Laboratory), provides Zeek parsers for protocols including BACnet, EtherNet/IP and CIP, S7comm, OPC UA Binary, HART-IP, Omron FINS, PROFINET IO CM and synchrophasor traffic, with extensions for DNP3 and Modbus.

Attributes to capture

The August 2025 joint guidance, Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators (CISA with EPA, NSA, FBI and the Australian, Canadian, German, Dutch and New Zealand national cyber agencies), rates 14 attributes as high priority. The table shows each one and where the data usually comes from.

The same guidance rates firmware/software version, VLAN, serial number, baseline image, backup frequency and time source as medium or low priority. Many teams promote firmware version to high, because vulnerability matching depends on it.

Taxonomy, criticality and sector models

The joint guidance sets out five steps: define scope and objectives; identify assets and collect attributes through physical inspection and logical survey; create a taxonomy; manage and collect data, including integrator agreements, vendor manuals and maintenance records, stored centrally with security controls; and implement life cycle management from acquisition through commissioning to decommissioning. The taxonomy step classifies assets by criticality or function, groups them into ISA/IEC 62443 zones and conduits, maps process dependencies with consistent naming, and is validated and reviewed periodically.

It also publishes conceptual, non-authoritative taxonomies for three sectors, built with industry working sessions in early 2025, each running from process areas to notional assets, three criticality tiers and functional zones.

High-criticality assets get the most stringent measures, such as segmentation and role-based access control; medium assets get robust monitoring and regular updates; low assets get basic measures and are inventoried for completeness. Agree tier definitions with process safety and operations, not security alone. Electricity entities subject to NERC CIP-002 already categorise BES Cyber Systems as high, medium or low impact and can align the two.

Integrating with vulnerability and change management

• Known exploited first: the joint guidance says "Use the KEV catalog as authoritative input to a vulnerability management prioritization framework", and suggests Stakeholder-Specific Vulnerability Categorization (SSVC), which accounts for exploitation status.
• Match on precise data: vendor, model, module and firmware version determine whether an ICS advisory applies. Ingest machine-readable advisories in CSAF format where vendors and CISA publish them, so matching is automated rather than manual.
• Software bills of materials: Secure by Demand asks OT suppliers for "a software bill of materials in a commonly used and machine-readable format". Link SBOMs to model and firmware records so that a newly disclosed library flaw can be traced to affected devices. See the Open Source Security Guide.
• Compensating controls: where a device cannot be patched, record the compensating control (tighter conduit rule, disabled service, added monitoring) against the asset so it is reviewed when the asset changes.
• Change management: the joint guidance requires inventory updates for the introduction or removal of devices "in all cases", including under emergency change authority. Make the inventory update a closing step of every work order that adds, replaces or removes a device.
• Configuration baselines: NERC CIP-010-4 shows what a usable baseline contains: OS or firmware, installed software, custom software, logical network accessible ports and security patches, monitored at least every 35 days for high impact systems. The model works outside electricity too.

For prioritisation and remediation workflow, see the Vulnerability Management Guide.

Monitoring, baselines and keeping the inventory current

NIST SP 1800-23 frames the target capabilities as discovering connected assets, capturing attributes to baseline them, continuous identification of newly connected and disconnected devices, assigning criticality, and alerting "on deviations from the expected operation of assets". Once the inventory exists, the same sensors become a detection layer:

• New or missing devices: alert on any device not in the inventory, and on critical devices that stop communicating.
• Communication baseline: alert on new peer pairs, new protocols on a conduit and write or program commands from hosts that normally only read.
• Unauthorised discovery: T0846 Remote System Discovery, T0888 Remote System Information Discovery and T0840 Network Connection Enumeration from hosts that are not approved inventory tools.
• Firmware and mode changes: firmware versions or controller modes that differ from the baseline without a work order.

Tune for the plant: MITRE's T0846 guidance warns against alerting on novelty or scan volume alone. For SOC integration, see the SOC Guide.

Metrics

• Coverage: percentage of known network segments and remote sites with collection, and percentage of high-criticality zones validated by walkdown in the last year.
• Completeness: percentage of assets with all 14 high-priority attributes plus firmware version populated.
• Currency: median days between a device change and the inventory update, and unknown devices detected per month (falling over time).
• Vulnerability linkage: percentage of assets automatically matched to advisories, and median days from a KEV-listed OT vulnerability to a patch or recorded compensating control.

Where identity fits

The joint guidance lists user accounts as a high-priority attribute while advising that roles (operators, technicians, vendors, integrators) are documented without listing access or credentials. That is the right split: the inventory records which accounts and roles exist on each device, and credentials live in a vault.

• Device and default accounts: record whether each controller, HMI and network device has local accounts, whether defaults have been changed, and whether it supports individual accounts at all. See the OT and ICS Identity and Access Guide.
• Machine identities: OPC UA application certificates and other device certificates and keys are assets with expiry dates. Record them alongside the device. See the Device and IoT Identity Guide.
• Service and vendor access: historian, backup and vendor support accounts define who can reach a zone, so link them to the remote access paths recorded in the inventory. See the Third-Party Access Guide.

Rolling out OT asset visibility

1. Scope and govern: name the authority requiring the inventory, owners for each site, and the definition of an asset (include network infrastructure, remote access devices and gateways).
2. Seed: import engineering project files, network diagrams, firewall rules and maintenance records to build a first draft.
3. Pilot passive collection: deploy sensors at one site's Level 2 and Level 1 aggregation switches; verify that SPAN changes do not affect switch performance, and keep the previous switch configuration for rollback.
4. Reconcile: compare observed devices with the draft, investigate unknowns with engineers and confirm by walkdown in high-criticality zones.
5. Close gaps carefully: add selective active queries only for device types proven safe on a test bench, during maintenance windows, with operations on hand to stop the activity.
6. Classify: assign criticality tiers, zones and owners using a sector taxonomy as a starting point.
7. Integrate: connect the inventory to advisory matching, change management, the SOC and, where used, the CMDB, with OT data protected as sensitive.
8. Scale and review: roll out site by site, then review attributes, taxonomy and coverage at least annually.

Decision guidance: a small utility or single plant can start with a well-structured spreadsheet or CMDB, open source decoders such as Zeek with ICSNPP, and engineering walkdowns. Multi-site operators usually need a dedicated OT visibility platform with central management and advisory matching, tested on their own device models before any active feature is trusted. Choose passive-only where devices are old, undocumented or safety-related; add selective active querying where firmware accuracy matters and the vendor supports it.

Framework mapping

Common failure patterns

• Running IT scanners on controllers: a well-meant vulnerability scan stops a PLC or HMI, and OT then refuses all security tooling for years.
• Sensors only at the boundary: monitoring at the IT and OT firewall misses controller traffic, so the inventory is mostly Windows hosts.
• A one-off project: an inventory built for an audit and never tied to change management is wrong within months.
• Missing access paths and accounts: the inventory lists devices but not remote access appliances, cellular modems or the accounts that use them. The Colonial Pipeline ransomware attack began with an unused VPN account, the kind of access path an inventory should surface.
• No criticality: thousands of assets with equal weight, so advisories and alerts are triaged by volume instead of consequence.
• Inventory exposed: a complete OT inventory is an attacker's target list; storing it in a widely shared file share without access control undoes the benefit.

Practitioner checklist

• Define scope, ownership and what counts as an asset, including network devices, gateways and remote access paths.
• Deploy passive, protocol-aware collection at Level 1 and Level 2 aggregation points, not just at the IT and OT boundary.
• Permit active queries only for tested device types, with engineering approval, in maintenance windows, and never on safety systems without vendor support.
• Register approved discovery tools so that other discovery traffic raises an alert.
• Populate the 14 high-priority CISA attributes plus firmware version for every asset.
• Assign criticality tiers, zones and named engineering owners using a sector taxonomy as a starting point.
• Automate matching to KEV, CSAF advisories and supplier SBOMs.
• Make inventory updates a mandatory step in every change and emergency change.
• Protect the inventory itself as sensitive data with access control and backups.
• Track coverage, completeness, currency and vulnerability linkage metrics quarterly.

Standards and references

• CISA and partners: Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators
• NIST: SP 1800-23 Energy Sector Asset Management
• CISA and partners: Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products
• MITRE ATT&CK: ICS Assets
• MITRE ATT&CK: Remote System Discovery (T0846)
• NERC: CIP-010-4 Configuration Change Management and Vulnerability Assessments
• CISA: ICSNPP Industrial Control Systems Network Protocol Parsers
• University of Bristol: A Taxonomy for Contrasting Industrial Control Systems Asset Discovery Tools

Related NHI Mgmt Group resources: OT Security Guide · OT and ICS Identity and Access Guide · Vulnerability Management Guide · Device and IoT Identity Guide · Attack Surface Management Guide