OT Asset Inventory and Management: Tools, Techniques, and Processes

Introduction

Asset inventory is the foundation of every OT security function. Vulnerability management requires knowing what devices are deployed before vulnerabilities can be assessed. Incident response requires knowing what is in a zone before containment decisions can be made. Network segmentation design requires knowing what communicates with what before firewall rules can be written. Patch management requires knowing firmware versions before advisories can be correlated.

"Know your assets" consistently appears as Step 1 in every OT security framework — IEC 62443, NIST SP 800-82, the SANS 20 Critical Controls for ICS — because it is genuinely prerequisite to every other security capability. Yet it consistently remains one of the weakest elements of OT security programs in practice.

The gap between documented asset inventories and the actual OT device population is substantial. In virtually every OT environment we have assessed, the device count discovered through passive network monitoring significantly exceeds the count in engineering documentation. Devices installed during past projects, legacy systems that were never fully decommissioned, protocol converters added by vendors during maintenance, and temporary devices that became permanent — all contribute to an undocumented device population that represents a real security exposure.

This guide provides a practical methodology for building a comprehensive, accurate, and continuously maintained OT asset inventory program — from discovery through database design, accuracy maintenance, and integration with downstream security functions.

Why OT Asset Inventory Is Harder Than IT

Before designing the program, understand the constraints that make OT asset inventory more challenging than enterprise IT asset management:

Device diversity: An enterprise IT environment has a relatively homogenous device population — Windows workstations, servers, network infrastructure, mobile devices. An OT environment may contain hundreds of different device types from dozens of vendors: PLCs, RTUs, DCS controllers, HMIs, SCADA servers, historians, safety controllers, engineering workstations, protocol converters, managed switches, wireless access points, UPS systems with network management cards, and embedded sensors with IP connectivity.

Limited agent support: Enterprise IT asset management typically deploys software agents on endpoints for real-time inventory. The majority of OT devices — PLCs, RTUs, industrial switches, protocol gateways — do not support software agent installation. Inventory must be built from external observation rather than device self-reporting.

Active scanning risk: Automated network scanning tools (Nmap, vulnerability scanners) can crash PLCs, cause spurious I/O state changes, and disrupt real-time control communications in OT environments. Active scanning requires careful validation before use and may simply not be feasible against certain device types.

Documentation gaps: Engineering documentation for OT systems is often years out of date. Installation records may exist for the original commissioning but not for subsequent additions, replacements, and modifications. Network diagrams may reflect the intended design rather than the actual installed configuration.

Extended lifecycles: OT devices are in service for 15-30 years. An inventory program must accommodate devices across a wide range of generations, from modern devices with SNMP and API access to legacy devices accessible only via serial connection.

Discovery Methods

Method 1: Passive Network Traffic Analysis

Passive network monitoring — observing communications without sending any packets — is the safest and most comprehensive discovery method for OT environments. OT-specific monitoring platforms identify devices by analyzing the traffic they generate and the traffic they receive.

What passive monitoring can discover:

• IP address and MAC address for every communicating device
• Device type inferred from protocol behavior (Modbus server → PLC or RTU; OPC UA server → data server or historian)
• Vendor and model from protocol fingerprinting (Siemens S7-1500 has a distinctive Profinet response structure; Rockwell PLCs respond differently to ENIP broadcast queries)
• Firmware version from protocol responses where devices include version information in communications
• Communication relationships: which devices communicate with which, using which protocols
• Operating system from TCP/IP stack fingerprinting where applicable

Platforms for passive OT discovery:

• Dragos Platform: Strong protocol coverage and industrial fingerprinting for major PLC and DCS families
• Claroty: Broad protocol support, strong passive fingerprinting, auto-populates asset records
• Nozomi Networks: Good multi-protocol coverage with OT and IoT device fingerprinting
• Microsoft Defender for IoT: Passive monitoring with integration into Azure and Microsoft Sentinel

Limitations of passive monitoring:

• Devices that are powered off or in standby during the monitoring period will not be discovered
• Devices connected via serial (not IP) communications are not visible to network monitoring
• Air-gapped devices with no network connectivity require manual discovery
• Some device types generate little or no spontaneous traffic and may not be detected until a communication event occurs during the monitoring period

Run passive monitoring for a minimum of 30 days before considering discovery complete. Process cycles, shift changes, maintenance windows, and batch sequences generate different traffic patterns. A monitoring period of less than one full operational cycle will produce an incomplete inventory.

Method 2: Configuration File and Documentation Analysis

Engineering project files contain detailed device information that is not always visible in network traffic:

PLC programming projects: Siemens TIA Portal project files, Rockwell Studio 5000 files, and similar engineering projects include hardware configurations that enumerate every PLC, I/O module, and network interface configured in the project. Analyzing these files produces a device list that is often more complete than network monitoring for devices at Level 0-1 of the Purdue model that may communicate infrequently.

Network device configurations: Managed switch configurations (exported via SNMP or console backup) include MAC address tables and interface descriptions that identify connected devices, even those that have not been seen communicating on the network.

SCADA database exports: SCADA server tag databases include all configured data sources — PLC addresses, register mappings, and device identifiers. These provide a map of the SCADA system's intended device population.

Historian configurations: Process historian configurations include data source definitions that enumerate connected devices and the parameters collected from each.

Automated analysis tools can parse engineering project files from major vendor formats to produce structured asset lists. Where automation is not available, manual review is time-consuming but valuable.

Method 3: Active Discovery (Validated and Controlled)

Active scanning — sending packets to devices to elicit responses — provides more complete information than passive monitoring but carries risk in OT environments. Before using active scanning:

1. Identify which devices in the target subnet are safe to scan (typically Windows-based servers and workstations, managed network infrastructure, modern PLCs with validated scanning support)
2. Identify which devices must never be actively scanned (older PLCs, RTUs, safety controllers, any device where the vendor does not confirm scanning compatibility)
3. Configure scanning tools to use the minimum scan intensity that achieves discovery objectives — typically a host ping scan and limited port scan rather than a full vulnerability scan
4. Schedule active scanning during off-production periods or maintenance windows, not during normal process operations
5. Monitor the network and operations team during scanning for any signs of impact

Tools suitable for OT active scanning (with appropriate configuration):

• Nmap with limited scan profiles: nmap -sn -PS80,443,102,502 target_subnet for a ping sweep using common OT protocol ports, without vulnerability probing
• Claroty active query: Protocol-specific queries designed for OT devices, validated by the vendor
• Nozomi active discovery: Configurable active queries with OT device compatibility ratings per vendor and model

Never use vulnerability scanners (Nessus, OpenVAS) against OT devices without explicit vendor confirmation of compatibility and extensive testing in a lab environment first.

Method 4: Manual Inventory

Some OT devices cannot be discovered remotely:

• Serial-connected devices: PLCs, RTUs, and instruments communicating via RS-232 or RS-485 serial connections to protocol gateways have no independent IP presence. They must be inventoried by reviewing gateway configurations and performing physical inspection.
• Air-gapped systems: Control systems with no network connection require physical access for inventory.
• Intermittently powered equipment: Seasonal equipment, standby systems, and backup units that are not currently active will not be visible to network discovery.

Manual inventory through facility walkdowns is time-consuming but necessary for completeness. Use barcode scanners and a mobile inventory application to capture device information efficiently during physical inspection. Include panel number, physical location, cabinet label, and any asset tag information alongside the technical device data.

Asset Database Design

Required Data Fields

An effective OT asset database captures the information needed to support vulnerability management, incident response, change management, and compliance reporting. Minimum required fields per device:

Extended Fields for Specific Device Types

For PLCs and controllers, additionally capture:

• Programming software and version used to manage this device
• Engineering workstations authorized to program this device
• Last logic download date and version reference
• Access protection level configured
• Protocol(s) in use (Modbus, EtherNet/IP, PROFINET, etc.)

For Windows-based systems (HMIs, engineering workstations, SCADA servers), additionally capture:

• Windows version and service pack
• Installed security software (antivirus, application whitelisting)
• Domain membership (standalone, OT domain, corporate domain)
• Backup configuration and last backup date
• Patch compliance status

For network devices (switches, firewalls), additionally capture:

• Firmware/IOS version
• Management protocol (SNMP v2/v3, SSH, HTTPS)
• Connected devices per interface
• Spanning tree and VLAN configuration summary

Database Technology Selection

OT asset databases are implemented on a range of platforms, from dedicated OT CMDB tools to adapted enterprise solutions:

OT-specific platforms:

• Claroty Asset Database: Auto-populated by the Claroty monitoring platform, with attributes discovered passively
• Dragos Asset Inventory: Integrated with the Dragos platform's passive discovery
• Nozomi Vantage Asset Intelligence: Device inventory with OT-specific attribute enrichment

Enterprise CMDB adapted for OT:

• ServiceNow CMDB with OT extensions: Organizations that have ServiceNow can extend the CMDB model to include OT-specific attributes and import from OT monitoring platforms
• IBM Maximo: Widely used in industrial facilities for asset management; can accommodate OT security attributes with customization

Simpler options for smaller programs:

• A well-structured spreadsheet is a legitimate starting point. Prioritize building a complete inventory in any tool over waiting for the perfect tool to arrive.
• Microsoft Access or similar lightweight database provides structured querying while remaining accessible to teams without dedicated database administrators.

Maintaining Inventory Accuracy

An asset inventory that was accurate on the day it was built will diverge from reality over time. Devices are added, replaced, and decommissioned. Firmware is updated. IP addresses change. Maintaining accuracy requires integrating inventory updates into operational processes.

Change-Driven Updates

Every OT change management event should include an asset inventory update step:

• New device installation: Add to inventory as part of commissioning. Do not close the commissioning change record without confirming the asset record is complete.
• Device replacement: Update the inventory record to reflect the replacement device. Retire the record for the decommissioned device with a decommission date.
• Firmware update: Update the firmware version field in the asset record upon completion of the patching change.
• IP address change: Update immediately — an incorrect IP address makes the asset record misleading and affects network-based controls (firewall rules, monitoring coverage).

Passive Monitoring as a Continuous Inventory Update Feed

OT monitoring platforms can serve as a continuous inventory feed: when the passive monitoring platform detects a new device, or detects a change in a known device's firmware fingerprint, it generates an alert that drives an inventory review. This capability — sometimes called configuration drift detection — automatically surfaces inventory inaccuracies without requiring periodic manual comparison.

Configure your OT monitoring platform to alert on:

• New devices detected on the OT network
• Changes in firmware fingerprints for known devices
• New IP address or MAC address associations

Each alert should trigger an inventory review: verify whether the change is authorized (and update the inventory accordingly) or unauthorized (and escalate for investigation).

Periodic Verification Campaigns

In addition to change-driven and monitoring-driven updates, conduct periodic inventory verification campaigns:

• Annual zone walkdowns: Physical inspection of OT areas to verify that every device in the inventory is physically present, accurately described, and accessible. Identify and inventory devices present but not in the database.
• Annual software version audit: Compare firmware and software versions in the asset database against current patch levels. Flag discrepancies for investigation.
• Quarterly network scan comparison: Compare the devices observed by passive monitoring against the inventory database. Every device observed on the network should have an inventory record; every device in the inventory should be observed (or have a documented reason for absence).

Integration with Downstream Security Functions

Vulnerability Management Integration

The OT asset inventory is the master data source for vulnerability correlation. When a new CVE or ICS-CERT advisory is published:

1. Match the affected product and version range against the asset database
2. Generate a list of all OT assets that match the affected criteria
3. Assess each match for exploitability in context (network exposure, compensating controls)
4. Assign priority scores and assign to responsible owners for remediation

This workflow is automated in integrated platforms (vulnerability management tools that consume the OT asset inventory) and semi-automated where the inventory is maintained in a CMDB that requires manual correlation with advisory information.

Zone and Conduit Documentation

Network segmentation designs in IEC 62443 terms require knowing which devices are in which zones. The asset inventory — with its zone assignments per device — is the authoritative source for zone membership lists. Firewall rules, network access controls, and monitoring sensor placement are all derived from this information.

Maintain zone assignments in the inventory and update them whenever devices are moved between zones, new zones are created, or zone boundaries are adjusted.

Incident Response Support

During OT security incidents, the asset inventory provides critical context:

• Which zone is the affected device in, and what other devices are in that zone?
• What is the operational criticality of the device — is it safety-critical or production-critical?
• What communications does this device normally have, and what would be expected versus anomalous?
• Who is the responsible operations team for this device?
• What vendor provides support, and what is the emergency contact?

An investigator working an incident without a current, accurate asset inventory is operating blind. The value of the asset inventory is never more apparent than in the first 30 minutes of an OT incident.

Compliance Reporting

Multiple regulatory frameworks require documented OT asset inventories:

• NERC CIP CIP-002: Requires identification and categorization of BES Cyber Systems and their assets
• AWIA (water sector): Risk and resilience assessment requires identification of OT assets
• IEC 62443 Part 2-1: Security management system requirements include asset identification
• NIS2 (EU): Requires asset management for essential and important entities

A well-maintained asset inventory with zone assignments, criticality ratings, and vulnerability status satisfies the documentation requirements of all these frameworks. The asset inventory built for security is simultaneously the compliance evidence for regulatory audits.

Conclusion

Building a complete OT asset inventory is a foundational project that pays dividends across every security function. It is also work that is never truly "finished" — the inventory must be continuously maintained to remain accurate and useful.

The organizations that build effective OT asset programs commit to two things: completing a thorough initial discovery using multiple complementary methods, and integrating inventory maintenance into operational processes so that the inventory stays current without requiring periodic heroic efforts to reconcile reality with records.

Start with passive monitoring. Supplement with documentation analysis and selective manual walkdowns. Build the database around the fields needed for downstream security functions. Integrate updates into change management. Review continuously. The completeness of the foundation will determine the effectiveness of every security capability built on top of it.

Beacon Security provides OT asset discovery engagements, inventory program design, and integration of asset management with vulnerability management and incident response capabilities for industrial organizations. Contact us to assess your current asset visibility and build a program that maintains accuracy over time.