BFM · Buildings & FacilitiesImages generated
Field guide · Range Lab
What an OT asset inventory actually contains
Ask most plants for their asset inventory and what comes back is a spreadsheet of IP addresses, sometimes with a hostname column, sometimes with a note saying “PLC?” against a few of them. It was exported from a switch or a scanning tool, it was accurate on the day it was made, and it answers almost none of the questions that matter when something has to be decided about the plant network. This guide sets out what an asset inventory for a control system actually contains, where each field comes from, and how it stays current.
Why a list of addresses is not an inventory
An IP address tells you that something answered on the network. It does not tell you whether that something is a controller holding a furnace at temperature or a label printer, whether stopping it would stop the line, who is allowed to change it, or whether a vendor in another country can reach it tonight. Those are the questions a plant manager asks when a patch is proposed, a firewall rule is drafted or an engineer wants to plug in a laptop, and an address list cannot answer any of them.
The inventory is the document that lets the plant make those decisions without walking out to the cabinet each time. It is also the foundation of every other piece of OT security work: you cannot draw zones and conduits around assets you have not named, and you cannot rank paths by consequence if you do not know what each path leads to.
An address tells you that something answered. An inventory tells you what it would cost if it stopped answering.
The fields that matter
Make and model, and the generation of the device, so that a notice from the manufacturer can be matched to the plant in minutes rather than in a site walk. Firmware version, because two controllers of the same model on different firmware are different assets for the purpose of knowing what they are exposed to and what a patch would involve. Both are usually missing from an address list, and both are visible in a passive capture when the device announces itself, or on the label and the HMI diagnostics page when it does not.
The Purdue level the device sits at, and the zone it belongs to. Level says what kind of thing it is in the architecture: a sensor or a drive at Level 0 or 1, a controller at Level 1, an HMI or SCADA server at Level 2, a historian or MES at Level 3. Zone says which group of assets it shares trust with, which is the unit at which segmentation is designed. A device whose level and zone are recorded can be placed on the drawing; one without them floats.
Communication paths and protocols: what the device talks to, in which direction, over which protocol and port. This is the field that turns a list into a map. It is also the field that shows which conversations cross a zone boundary, which is where most of the risk sits. A controller that talks only to its HMI and its drives is a different proposition from the same controller that is also polled by a reporting server in the office.
Owner and vendor access. The owner is the named person or role on site who can authorise a change to the device and who is called when it fails; on most sites the honest answer is the maintenance lead or the integrator, and writing that down is itself useful. Vendor access records whether the manufacturer or integrator has a route to the device, through what, and under which contract. Physical location, in cabinet and panel terms, so that the person sent to look at the device can find it: a building, a room, a cabinet number, a slot. And criticality in process terms: what the plant loses if this device stops or misbehaves, written as a consequence (the line stops, the batch is lost, the room warms) rather than as a score.
A sample
The table below shows the shape, with rows from two imaginary sites, a factory and a building, so that the range of entries is visible. Real inventories run to hundreds of rows and carry more columns; the point here is what a row has to say.
Sample
| Asset tag | What it is | Firmware | Level · zone | Talks to | Owner · vendor access | If it stops |
|---|---|---|---|---|---|---|
| RNG-MFG-01 · PLC-02 · CAB-14 | PLC, press line 2 | 2009 firmware | L1 · Press zone | HMI-02, drives in CAB-14, MES server (polled) | Maintenance lead · integrator VPN box, permanent | Line 2 stops |
| RNG-MFG-01 · HMI-02 · CAB-14 | Panel HMI, press line 2 | 2016 image, unsupported OS | L2 · Press zone | PLC-02 only | Maintenance lead · none | Operators blind, line runs |
| RNG-MFG-01 · EWS-01 · OFFICE-3 | Engineering workstation, all lines | 2021 image | L3 · Engineering | Every PLC, email, file server | Controls engineer · machine builder session on request | Nothing immediately; holds all project files |
| RNG-MFG-01 · HIST-01 · SERVER-RM | Historian | 2019 release | L3 · Plant servers | All PLCs (read), office reporting server | IT · vendor support portal | Reporting stops, line runs |
| RNG-BFM-02 · BMS-01 · PLANT-RM | BMS head end | 2014 release | L2 · Building plant | Chiller and AHU controllers, contractor gateway | Facilities manager · contractor cellular gateway, permanent | Chillers hold last setpoint; no alarms |
| RNG-BFM-02 · CHL-01 · CAB-03 | Chiller controller | 2012 firmware | L1 · Building plant | BMS-01 | Facilities manager · through the BMS gateway | Cooling lost; building warms |
Where the fields come from
No single source fills the table. A passive capture at the right switch ports gives the make and model, often the firmware, the protocols and the communication paths, because controllers announce themselves and because the paths are simply the conversations that pass the mirror port. It gives this without sending a packet to a controller, which is why it is the first source and not the last. It does not give the owner, the contract or the cabinet number, and it cannot see a device that stayed silent during the capture.
The cabinet walk-down gives the physical location, the label on the device, the modem with an antenna that the capture may have heard but could not place, and the jumper that is not in any drawing. It is slow, and it is the only way to fill some fields. Contracts and drawings give the rest: the vendor access column comes from the service agreements, the owner column from the organisation chart and a conversation, and the designed zones from the commissioning drawings, which are then corrected against what the capture and the walk-down found.
Keeping it current
An inventory decays from the day it is written, for the same reasons an air gap decays: a line is added, a machine is replaced, a contractor fits a gateway. On most sites of this kind the practical answer is not a tool that promises to keep it current on its own, but three habits. Every change to the plant network goes through a form that updates the inventory as part of the change. A passive capture is repeated at an interval the plant can sustain, and the differences are reconciled. And the inventory has an owner, one person whose job includes being asked whether it is still right.
ISA/IEC 62443-2-1 · security programme requirements for asset owners
The inventory does not need to be beautiful. It needs to be true, held by the plant rather than by a vendor, and detailed enough that the next decision about the plant network can be made from it. That is the document our method builds first, whether the site is a building whose chiller plant has outlived three tenants or a manufacturing floor that has been added to since commissioning. Everything after it depends on it.
Sources · ISA/IEC 62443-2-1 (security programme requirements for asset owners); ISA/IEC 62443-3-2 (zones and conduits); NIST SP 800-82 Rev. 3.
