OT Asset Inventory and Discovery: How to Build an Accurate Industrial Asset Baseline

An accurate OT asset inventory is more than a list of IP addresses. It is an evidence-backed baseline of the devices, systems, software, owners, operational roles, dependencies, and communications that sustain an industrial process. That distinction matters. A flat device list may show that a programmable logic controller exists, but not which production line it controls, which engineering workstation can modify it, whether its communications are expected, or what operational consequence would follow from its loss. OT asset discovery must also respect a constraint that does not apply equally in conventional IT: an aggressive probe, malformed request, or unexpected session can disrupt a fragile controller or legacy service. The goal is therefore not maximum probing. It is maximum confidence with minimum production interaction. This guide presents a production-safe methodology based on passive discovery, existing data sources, engineering knowledge, reconciliation, and controlled validation.

What an OT asset inventory must establish

A useful industrial asset baseline should answer six questions:

1. What is present? Hardware, software, virtual systems, network infrastructure, embedded devices, and supporting services.
2. Where is it? Site, area, cell, zone, VLAN, subnet, cabinet, or physical location.
3. What does it do? Process function, system role, protocols, and dependencies.
4. Who is accountable for it? Operational owner, technical custodian, and security contact.
5. How important is it? Safety, production, environmental, quality, financial, and regulatory consequences.
6. How does it normally communicate? Peers, direction, protocol, port, frequency, and timing. This information supports segmentation, incident response, vulnerability management, change control, compliance, and security assessment. It also establishes the data foundation needed to model IT-to-OT attack paths with a cyber digital twin.

Why OT asset discovery requires a different approach

Industrial environments commonly contain long-lived devices, proprietary protocols, unsupported operating systems, serial-to-IP gateways, vendor-managed equipment, and systems that cannot be interrupted for routine security work. Some devices communicate infrequently. Others appear under multiple IP addresses or share generic hostnames. Documentation is often fragmented across engineering, maintenance, IT, integrators, and security teams. No individual source should automatically be treated as authoritative. Active discovery creates another concern. Broad port scans, service enumeration, authenticated scanning, or protocol-specific queries may be acceptable on approved IT systems but unsafe for production controllers and embedded devices. Learn more about the risks of testing live OT systems. A safer operating principle is:

> Observe first, reconcile second, and interact only when the asset owner has approved a tested method.

A production-safe OT asset inventory methodology

Treat inventory development as a recurring evidence-management process, not a one-time scan. Each record should retain its source, confidence level, and last validation date so teams can distinguish observed facts from assumptions.

Step 1: Define scope, ownership, and safety constraints

Start with a bounded environment such as one site, process area, or production line. Document:

• Included networks, facilities, and process units
• Relevant IT, OT, safety, and vendor-managed systems
• Approved passive collection points
• Prohibited protocols, probes, or testing techniques
• Maintenance windows and escalation contacts
• The person authorized to approve inventory changes Create a small working group that includes OT security, controls engineering, network engineering, plant operations, maintenance, and relevant system vendors. Security can manage the process, but operations and engineering must validate operational context.

Step 2: Collect evidence from existing OT data sources

Begin with information already generated by the environment. Useful sources include:

• Firewall configurations, object groups, rules, and traffic logs
• Router and switch configurations, MAC tables, ARP tables, and VLAN records
• Passive OT monitoring or network detection platforms
• NetFlow, IPFIX, packet captures, and network metadata
• SCADA, HMI, historian, and engineering workstation configurations
• Domain, DNS, DHCP, authentication, endpoint, and backup records
• Virtualization and server management platforms
• PLC, RTU, DCS, and safety-system project files
• CMMS, EAM, procurement, warranty, and maintenance records
• Existing spreadsheets, diagrams, and compliance inventories
• Physical cabinet surveys and operator interviews Record collection time, coverage, and known limitations. A firewall log may reveal routed traffic but miss isolated devices. A switch table may show a MAC address without identifying its process role. A controller project file may be authoritative for engineering configuration but stale after an emergency replacement.

Step 3: Use passive discovery to observe assets and communications

Passive OT asset discovery analyzes traffic copied from network infrastructure through a TAP, packet broker, or SPAN port. It does not initiate sessions with production assets. Passive observation can identify:

• IP and MAC addresses
• Industrial and conventional protocols
• Client-server or controller-device relationships
• Vendor and device-family indicators
• Firmware or operating-system clues exposed in normal traffic
• Communication frequency and direction
• Previously undocumented cross-zone connections Collection must still be engineered carefully. Confirm that a SPAN configuration will not overload a switch, that collection coverage includes relevant VLANs, and that packet handling meets the organization’s data-security requirements. Passive discovery also has limits. Silent spares, powered-down systems, serial-only devices, and assets that communicate outside the observation window may remain invisible. Run collection across representative production states, including startup, shutdown, batch changes, maintenance, and failover where practical.

Step 4: Reconcile conflicting asset records

Do not concatenate source files and call the result an inventory. Normalize and reconcile them. Use stable identifiers where available, including serial number, MAC address, chassis identifier, switch port, physical location, or engineering project reference. IP address alone is not a reliable identity. For every candidate record:

1. Normalize vendor, model, hostname, location, and protocol names.
2. Merge records only when multiple attributes support the match.
3. Preserve aliases and previous addresses.
4. Retain provenance for each important field.
5. Assign a confidence rating.
6. Send unresolved conflicts to the appropriate owner. A simple confidence model is useful:

• High: Confirmed by current network evidence and an engineering or physical source.
• Medium: Supported by one reliable source or several indirect sources.
• Low: Inferred, stale, incomplete, or contradicted by another source. Uncertainty should remain visible. A clearly marked unknown is safer than false precision.

Step 5: Record the inventory fields that support security decisions

A practical OT asset inventory should include the following fields where applicable:

Category Recommended fields

Identity Unique ID, hostname, aliases, IP addresses, MAC address, serial number Classification Asset type, vendor, model, hardware revision, system role Software Operating system, firmware, application, version, patch level Location Site, building, area, line, cell, cabinet, switch, port, VLAN, zone Process context Process served, control function, dependencies, redundancy role Communications Peers, protocol, port, direction, frequency, remote access path Governance Business owner, operational owner, technical custodian, vendor Risk Criticality, safety impact, production impact, recovery priority Lifecycle Installation date, support status, backup status, replacement plan Evidence Data source, first seen, last seen, last validated, confidence Avoid forcing every field into a single manual spreadsheet. Maintain a governed system of record or a federated model that preserves links to authoritative engineering and maintenance systems.

Step 6: Assign asset criticality and accountable ownership

Criticality should reflect operational consequence, not merely device type or vulnerability score. Assess the plausible impact of loss, manipulation, or unavailability across:

• Personnel and public safety
• Production capacity and duration of outage
• Environmental release or permit violation
• Product quality and integrity
• Equipment damage
• Regulatory or contractual obligations
• Recovery complexity and replacement lead time
• Dependency on the asset by other critical processes Use a defined scale with documented criteria. Include compensating factors such as redundancy, manual operation, fail-safe behavior, and available spares. Ownership must name accountable roles rather than a generic department. Distinguish the operational owner who accepts process risk from the technical custodian who maintains the system. Assign a security contact and vendor contact where needed.

Step 7: Establish normal communication baselines

An asset inventory becomes significantly more useful when it records relationships. For each important communication, capture:

• Source and destination asset or zone
• Initiator and responder
• Protocol and service
• Direction and expected path
• Typical frequency, volume, and time window
• Business or process justification
• Whether the flow crosses a trust boundary
• Approving owner and last review date Observe enough operating modes to avoid treating legitimate but infrequent activity as anomalous. Examples include monthly reporting, backup transfers, vendor maintenance, failover, and batch-recipe downloads. The resulting map can inform a security-first OT network architecture and expose communications that do not align with intended zones and conduits.

Step 8: Validate the inventory without unsafe active scanning

Use layered validation rather than defaulting to broad network scans:

1. Cross-source comparison: Confirm important fields against at least two independent sources.
2. Engineering review: Ask control engineers and operators to validate roles, dependencies, and process impact.
3. Physical verification: Inspect selected cabinets, network ports, labels, and serial numbers under plant procedures.
4. Configuration review: Compare records with switch, firewall, HMI, historian, controller, and project configurations.
5. Temporal observation: Check whether assets and flows appear across representative operating states.
6. Sampling: Validate a risk-based sample from each zone, asset class, and confidence level.
7. Change reconciliation: Compare observed changes against approved maintenance and management-of-change records. If active interrogation is necessary, require explicit authorization, vendor guidance, a documented method, tested rate limits, rollback procedures, and operational monitoring. Prefer a lab, spare device, or digital representation before interacting with production. Do not assume that a low scan rate makes every query safe.

How to measure OT inventory accuracy and coverage

Useful metrics include:

• Percentage of assets with an assigned operational owner
• Percentage with criticality and process function recorded
• Percentage supported by more than one evidence source
• Percentage observed or validated within the required review period
• Number of unknown, duplicate, stale, or conflicting records
• Percentage of critical communications with an approved justification
• Time required to reconcile an approved change
• Number of unapproved assets or flows detected per review cycle Track metrics by site, zone, and criticality. A 95% completion rate can conceal serious exposure if the missing 5% includes safety controllers or remote-access infrastructure. Inventory validation should be event-driven as well as periodic. Trigger review after network changes, controller replacements, vendor work, mergers, outages, or newly observed communications.

Turn asset visibility into validated OT risk reduction

An inventory is foundational, but visibility alone does not show whether an adversary can traverse IT and OT boundaries, reach a critical controller, or bypass a compensating control. Use the baseline to support segmentation reviews, vulnerability prioritization, incident response, and safe attack-path validation. Frenos ingests data from existing OT and security tools to create cyber digital twins for simulated penetration testing. This allows teams to evaluate exploitable IT-to-OT routes without testing directly on production assets. When visibility is incomplete, Frenos’ Optica rapid visibility service can help develop the network model from available evidence. At S4x26, Frenos reported building a digital twin from raw firewall data in 11 minutes and 42 seconds. It also reported normalizing 63,928 network flows through a Cisco Cyber Vision integration and running 154,000 attack-path simulations in 17 minutes, identifying 18 validated paths into critical OT zones. Request a demo of the Frenos OT cybersecurity platform to see how existing inventory and network data can support production-safe attack-path validation.

Frequently asked questions

What is an OT asset inventory?

An OT asset inventory is an evidence-backed record of industrial hardware, software, ownership, process roles, criticality, dependencies, locations, and normal communications. It should cover controllers, HMIs, engineering workstations, servers, network devices, safety systems, gateways, and supporting IT services.

Is passive discovery enough for a complete OT inventory?

No. Passive discovery is valuable and production-safe, but it may miss silent, offline, serial-only, or rarely communicating assets. Reconcile passive observations with engineering files, network configurations, maintenance systems, physical verification, and operator knowledge.

Is active scanning safe in OT environments?

Not by default. Some legacy or embedded systems may respond unpredictably to probes or service enumeration. Any active method should be asset-specific, approved by operations, supported by the vendor where possible, tested outside production, and governed by rollback and monitoring procedures.

How often should an OT asset inventory be updated?

Update it continuously where data allows, reconcile it after every approved change, and conduct formal risk-based validation periodically. Critical assets and trust-boundary communications should have shorter validation intervals than low-impact supporting systems.

Who should own the OT asset inventory?

The organization should assign one accountable inventory owner, but maintenance requires participation from operations, controls engineering, networking, IT, security, and vendors. Individual assets should have named operational owners and technical custodians. For a broader implementation sequence, use this OT security checklist alongside the inventory methodology above.