The short answer
Building an OT Asset Inventory
An OT asset inventory lists every controller, remote unit, HMI, server, workstation, switch, firewall, radio, modem, drive, instrument, and appliance in the control system, with its make, model, serial number, firmware or software version, network addresses, location, role, owner, criticality, and support status. It is built by walking every site and opening every panel, because drawings are out of date and network scans miss what is serial or switched off, then checked against the switch address tables, the SCADA device list, and passive listening on the network, and it is kept current by making the inventory update a mandatory step of every change. It is the foundation for matching advisories to equipment, planning patches and firmware, knowing what to back up, and knowing what was touched in an incident.
Key points
- If it has a network interface or a program, it is an asset, including the vendor box nobody remembers and the cellular modem in the enclosure.
- Walk every site and open every panel; the drawings are the starting point, not the answer.
- Cross-check with the switch address tables, the SCADA driver list, and passive listening; each finds what the others miss.
- Record the fields that will be used: version for advisories, address for segmentation, criticality for priority, support status for replacement.
- The inventory update is the closing step of every change record; an inventory without that habit is out of date in a year.
- Start with what touches the network and what runs the critical processes; perfection comes later.
What counts
- Controllers, remote terminal units, I/O adapters and remote racks, safety controllers.
- HMI panels, operator workstations, engineering laptops, servers, virtual machines and the hosts under them.
- Switches, routers, firewalls, wireless access points, media converters, serial-to-Ethernet gateways.
- Radios, cellular modems, leased line modems, satellite terminals.
- Drives, soft starters, and motor protection relays with communication ports.
- Instruments and analyzers with Ethernet, fieldbus, or configurable interfaces; HART-capable transmitters.
- Uninterruptible power supplies, power monitors, and generators with network cards.
- Cameras, access control panels, intrusion systems on the control network.
- Vendor appliances: remote support boxes, historian gateways, licensing servers, time servers.
- Printers, and anything else with a cable into a control network switch.
The fields
| Field | Why it matters |
|---|---|
| Asset tag and description | The name used on drawings and in the SCADA, so that everything cross-references |
| Site, building, panel, and position | Where to find it, physically |
| Make, model, and part number | Advisories and lifecycle notices are issued by model |
| Serial number and hardware revision | Warranty, recall, and the exact unit affected by a hardware advisory |
| Firmware, operating system, and application versions, with the date read | Advisories name versions; patch status starts here |
| Network addresses, MAC addresses, VLAN, and the switch port it connects to | Segmentation, firewall rules, and finding it during an incident |
| Protocols and connections | What it talks to and how; the basis of the conduit list |
| Role and process served | What stops if it fails |
| Criticality | A rating from the risk assessment that sets the priority for everything else |
| Owner and support contact | Who decides about it and who to call |
| Support status and end of life | When it must be replaced |
| Backup status | Whether a configuration or program backup exists and when it was taken |
| Physical security | Locked panel, locked room, fenced site, intrusion alarm |
| Notes | Default credentials changed, known issues, spares held |
Building it
- 1
Start from the paper
The drawings, the IP schedule, the SCADA device list, the integrator handover documents, and the purchase records. Assemble a first list and expect it to be wrong in both directions.
- 2
Walk every site
Open every panel and every enclosure, including the ones at the well and the tank, and record what is there: nameplates, labels, firmware from displays, cables into switches. Photograph the panel interior. This is the step that finds the vendor modem and the unmanaged switch.
- 3
Read the switches
The address tables of every managed switch list every device that has talked through them, with the port. Compare with the walk; anything on a switch and not in the walk is found and identified.
- 4
Listen
A passive capture at the core switch shows who talks to whom with what protocol and often reveals firmware versions from the protocol identification. It confirms the connections and finds devices that were missed.
- 5
Reconcile
Every device found by any method is in the list once, with its fields filled from the best source. Unknown devices are traced to a cable and a purpose, or removed from the network.
- 6
Rate criticality
From the risk assessment: what the loss or compromise of each asset does to the process, on a scale the utility defines.
- 7
Publish and protect
The inventory is a sensitive document: it is the attacker map. It lives where the security documentation lives, with access control and a backup.
Keeping it current
Inventories are accurate the day they are finished and decay from then on. The habit that keeps them alive is the change record: no change closes without the inventory updated, and a like-for-like replacement of a failed module is a change record for exactly that reason. A quarterly comparison of the switch address tables with the inventory catches what the habit missed, and the annual walk of the sites, which is needed for other reasons, re-verifies the physical layer. Passive monitoring, where it is installed, alerts on a new address the day it appears.
What it is for
- Matching security advisories to the equipment actually installed, by model and version.
- Planning patches and firmware updates, and knowing what cannot be patched.
- Knowing what to back up, and checking that it was.
- Designing segmentation: the zones are drawn around the assets and their connections.
- Answering the first questions in an incident: what is on this network, what does this address belong to, what did the compromised machine talk to.
- Planning replacements before end of life rather than after failure.
- Satisfying the risk assessment requirements that expect a utility to know what it has.
Frequently asked questions
- Can we just scan the network?
- Active scanning finds networked devices that answer and can crash older controllers and instruments that do not expect unsolicited traffic; it is used with care, on a schedule, with the process in a suitable state, and never as the first method. The walk finds what is not on the network or is switched off, and passive listening finds what is on the network without touching anything. Scanning is a supplement for the machines that tolerate it.
- How long does the first inventory take?
- A day per plant and an hour per remote site for the walk, plus a few days to reconcile, for a typical utility. It is the largest single effort in the first year of a security program and the one that pays back most, because everything else depends on it.
- What about the devices with no network connection?
- A standalone controller with a serial programming port is still an asset: it has a program to back up, firmware with advisories, and a panel someone can open. Include it, mark it as not networked, and it drops out of the segmentation work while staying in the backup and firmware work.
- Who owns the inventory?
- The control system owner, with a named person maintaining it. It is not an IT asset register, although the IT register may want a copy of the server entries; the fields and the criticality ratings are operational.
Related topics
- Passive DiscoveryFinding out what is on a control network by listening rather than probing: why active scans are risky around older controllers, how a mirror port feeds a sensor, what the traffic reveals, the blind spots, and how the sensor becomes continuous monitoring.
- Documenting Firmware VersionsWhy the firmware version of every controller, module, drive, switch, radio, and instrument belongs in the inventory with the date it was read: advisories are issued by version. Where to read each one, the several versions one controller has, and the cadence.
- OT Risk AssessmentRanking what could go wrong in a control system and what it would cost: the consequence-first method for utilities, the assets and scenarios to list, likelihood without pretending to know it, the risk matrix, and turning the ranked list into a work plan.
- Change Management for OTA change process sized for a utility control system: what counts as a change, the request with risk and rollback, owner approval, the window, backup before and verification after, the baseline update, the emergency path, and the record.
- Advisories and AlertsWhere a utility learns its equipment has a known vulnerability and what to do with the news: the government and vendor advisory feeds, the sector center, the exploited catalog, subscribing by product, a weekly triage on exposure and consequence, and records.
- Security Program BasicsWhat a control system security program is for a utility that has never had one: a named owner, an inventory, a risk assessment, a few policies, baseline controls, training, vendor rules, an exercised incident plan, and a first-year plan for a small staff.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.