You cannot segment, patch, monitor or recover what you do not know you have. In OT, the asset inventory is the foundation for almost every other security control, and building it safely requires a different approach from IT.
The problem in real environments
Most industrial sites have some form of asset list. It is usually a spreadsheet from commissioning, an engineering drawing set, a maintenance system with equipment tags, and the knowledge in the heads of two or three long-serving engineers. None of these was built for security, and they rarely agree with each other.
Common gaps we see when comparing the documented inventory with what is actually on the network:
- Devices that exist on the network but not in any record: a laptop left connected as a permanent "engineering station", a managed switch added during an expansion, a packaged skid controller with its own embedded web server.
- Records that describe the asset but not its network identity: the PLC is listed by tag and location, but not by IP address, MAC address or the conduits it uses.
- Firmware and software versions that were accurate at handover and have not been updated since, even though the integrator has upgraded several devices.
- No owner. The device is "operations" or "the vendor", which in practice means nobody is accountable for its security.
Without an accurate inventory, a vulnerability advisory for a specific controller family produces a week of phone calls instead of a quick answer. IEC 62443-2-1 and NIST SP 800-82r3 both treat asset identification as a basic programme element, and IEC 62443-3-2 depends on it: you cannot partition a system into zones and conduits until you know what the system contains.
Why IT discovery methods are risky in OT
In IT, inventory is often built by scanning: ping sweeps, port scans, authenticated agent queries. Applied to an OT network without care, these techniques can cause real harm.
- Fragile network stacks. Some older controllers, protocol gateways and serial-to-Ethernet converters have limited TCP/IP implementations. Unexpected packets, malformed probes or a high rate of connections can cause them to hang, drop communications or reboot.
- Real-time sensitivity. Scanning traffic competes with control traffic. On networks with tight timing, extra load or broadcast storms can trigger communication faults and safety trips.
- Protocol side effects. Industrial protocols often lack authentication. A discovery tool that sends the wrong function code to a device can do more than read: it may change state.
- No agents. PLCs, RTUs and IEDs cannot run endpoint agents, and many Windows-based HMIs are under vendor support contracts that forbid installing additional software.
This does not mean active techniques are forbidden. It means they must be chosen, tested and scheduled with the same discipline as any other change to the control system.
Passive monitoring versus active querying
Passive monitoring
Passive discovery listens to a copy of network traffic and builds the inventory from what it sees. An OT-aware monitoring platform decodes industrial protocols such as Modbus/TCP, EtherNet/IP (CIP), PROFINET, S7comm, DNP3, IEC 60870-5-104, IEC 61850 MMS and GOOSE, and BACnet, and extracts device identities, vendors, models, and sometimes firmware versions from normal traffic.
Strengths: no packets are sent to the control network, so the risk to process availability is essentially zero when the traffic copy is set up correctly. It also maps communication relationships, which you need for zone and conduit design. Limits: it only sees what talks on the monitored segments. Devices that communicate rarely, sit behind serial links, or only exchange traffic on unmonitored switches will be missing or partially described. Firmware versions are often unavailable passively, because they are only exchanged during engineering sessions.
Active querying
Active discovery sends requests to devices. In OT, the safer form is selective, protocol-native querying: asking a controller for its identity object using the same requests its own engineering software uses, at a low rate, to specific known addresses. Many OT monitoring platforms support this as an optional mode.
Strengths: fills gaps that passive monitoring leaves, especially firmware versions, module details and serial numbers. Limits: carries some risk, and needs testing on representative hardware, approval from operations, and scheduling in a maintenance window for the first runs.
The practical answer: passive first, active by exception
Use passive monitoring as the default and continuous source. Add targeted active queries only for asset classes that have been tested against them, at rates and times operations has agreed. Supplement both with offline sources: engineering project files, controller configuration exports, maintenance records and physical walkdowns. Physical walkdowns remain necessary, because some assets (serial devices, isolated safety systems, standalone panels) will never appear on a monitored Ethernet segment.
SPAN and TAP placement
Passive monitoring is only as good as the traffic it receives. Placement decisions determine what you can see.
SPAN versus TAP
A SPAN (mirror) port copies traffic from selected ports or VLANs on a managed switch to a monitoring port. It is cheap and quick but consumes switch resources, may drop packets under load, and its configuration can be changed or lost during switch maintenance. A network TAP is a dedicated hardware device inserted into a link that copies all traffic. It is more reliable and, for passive or fail-open models, does not interrupt the link if it loses power, but it requires a brief outage to install. Use data-diode style or receive-only TAPs where you need assurance that the monitoring network cannot send traffic back into the control network.
Where to place sensors
- Supervisory layer (Level 2 to Level 3). Captures HMI, SCADA server, historian and engineering workstation traffic to controllers. This is usually the highest value per sensor.
- Control network core and distribution switches. Captures controller-to-controller and controller-to-I/O traffic where it crosses these switches.
- Conduits between zones. The OT DMZ and IT/OT boundary, to see what actually crosses each boundary compared to what the firewall rules intend.
- Remote sites. Substations, pump stations and remote facilities often need small local sensors, or a decision about which traffic is worth backhauling.
Traffic that stays local to an access switch (between two devices on the same switch) will not appear on an uplink SPAN. Plan coverage per switch, document which segments are monitored, and treat unmonitored segments as known gaps rather than assuming visibility. Keep the monitoring network separate and one-directional, and make sure sensors themselves are hardened and inventoried.
What attributes to capture
A useful security inventory captures enough to answer three questions: what is it, how exposed is it, and what happens if it fails or is compromised. A practical attribute set:
| Category | Attributes |
|---|---|
| Identity | Asset tag, hostname, device type, vendor, model, serial number |
| Network | IP and MAC addresses, VLAN, switch and port, zone membership |
| Software | Firmware version, OS and patch level, installed engineering or application software, modules and cards |
| Communication | Protocols used, peers it talks to, listening services, remote access paths |
| Location | Site, building, area, cabinet or panel |
| Criticality | Process function, safety relevance, consequence of loss of availability or integrity |
| Ownership | Responsible engineer or team, maintaining vendor, support contract status |
| Lifecycle | Install date, vendor support or end-of-life status, last verified date |
Criticality and ownership are the attributes most often missing, and they are the ones that let security decisions make sense to operations. Criticality should be assigned with process engineers, based on consequence, not on how expensive the device is. A small remote I/O module feeding a safety-related interlock can be more critical than a large SCADA server with a hot standby.
Keeping it current
An inventory built once and left alone decays quickly. Practical measures to keep it current:
- Continuous passive monitoring with alerts on new assets. A new MAC address or new device type on a control network should create a ticket for someone to identify and classify it.
- Tie it to change management. Any approved change that adds, replaces or upgrades an asset updates the inventory as a closing step. Include firmware upgrades performed by vendors.
- Periodic reconciliation. Compare monitoring data, engineering records and maintenance systems on a schedule, for example quarterly, and resolve differences.
- Last-verified dates. Track when each record was last confirmed. Records not verified for a long time are candidates for walkdown or targeted querying.
- One authoritative source. Decide which system holds the master record and feed the others from it, rather than maintaining parallel spreadsheets.
Using the inventory for vulnerability management
The main payoff of an accurate inventory is fast, reasoned vulnerability management. When an advisory is published by a vendor or by a national CERT, the workflow becomes:
- Match. Identify affected assets by vendor, model and firmware version. Without firmware data, the answer is "possibly all of them", which is not actionable.
- Assess exposure. Use zone, communication and remote access attributes to judge whether the vulnerable service is reachable, and from where.
- Weigh consequence. Use criticality to decide how urgently the asset matters. A remotely reachable vulnerability on a high-consequence controller is a different priority from the same issue on an isolated test bench.
- Choose a response. Patching in OT often waits for an outage window or vendor qualification. Compensating controls, such as tightening conduit rules, disabling an unused service, or removing a remote path, can reduce risk in the meantime.
- Record the decision. Note the response and the review date against each affected asset, so residual risk is visible and owned.
The same data supports incident response (which assets talk to the compromised host), backup coverage (does every controller have a current configuration backup), and lifecycle planning (which devices are past vendor support).
Common mistakes
- Running an IT scanner across the control network. Even once, without testing and approval, this can cause outages and lose the trust of operations for years.
- Assuming the monitoring platform sees everything. Coverage gaps from switch topology, serial networks and isolated systems are normal. Document them.
- Collecting data without owners. An inventory with thousands of assets and no owners produces reports, not action.
- Treating criticality as a security team decision. It must come from people who understand the process and its consequences.
- Leaving the inventory exposed. A complete OT inventory with IP addresses, firmware versions and criticality is a reconnaissance gift. Restrict access to it and protect it like any other sensitive design document.
Where to start
Start with the existing records, however incomplete, and one passive sensor at the supervisory layer of your most critical process area. Compare what the sensor sees with what the records say, and resolve the differences with the engineers who own the system. Add criticality and ownership for that area before expanding coverage. Once one area has an inventory that operations trusts, extend sensor placement, introduce tested active queries where firmware data is missing, and connect the inventory to change management and vulnerability advisories.