‘We have an asset register’ is a statement that almost every industrial site will make. ‘When was it last updated?’ is the question that reveals what it is actually worth. An OT asset register that was accurate three years ago and hasn’t been touched since the last major project tells you what the site used to have, not what it has now.
A useful OT asset register is a living document that supports cybersecurity assessments, lifecycle planning, incident response, and maintenance. Building one, and keeping it current, requires more discipline than most sites apply to it. This article describes what a good OT asset register contains and how to build one.
Why the asset register matters
In an OT cybersecurity context, the asset register is foundational. You cannot assess vulnerability if you don’t know what you have. You cannot detect anomalous network behaviour if you don’t know what normal traffic looks like. You cannot recover from an incident if you don’t know which systems need to be rebuilt. ISA/IEC 62443 and NIST CSF 2.0 both identify asset management as a core requirement, and both make it clear that you cannot progress to more sophisticated controls without it.
Beyond cybersecurity, the asset register drives lifecycle planning. Operating a PLC on a CPU that has been discontinued, running SCADA on a Windows version that is no longer receiving security updates, or relying on a server that can no longer be replaced with identical hardware: all of these are risks that only become visible when they are documented.
What the register should contain
For each item in the OT asset register, capture:
- Asset name/ID: a unique identifier that matches the tag or label on the physical equipment
- Asset type: PLC, DCS, SCADA server, engineering workstation, HMI terminal, network switch, firewall, historian, and so on
- Manufacturer and model: the exact make and model, including the specific CPU or chassis model where relevant
- Firmware/software version: the current installed version, for PLCs, DCS, and network equipment
- Operating system: for computers and servers, the OS version, service pack or build, and patch level
- IP address: the current assigned IP address, subnet, and VLAN or zone
- Network zone: which zone the device is in (OT, IT, DMZ, field)
- Physical location: which panel, control room, substation, or field location
- Function: what this device does, for example ‘Citect Primary I/O Server, Mill 1’ or ‘ControlLogix PLC, Conveyor Drive Control’
- Communications: what other devices it communicates with, and via what protocol
- PLC/SCADA program backup location: where the program or project backup is stored, and when it was last taken
- Lifecycle status: supported, end of life, discontinued, or vendor end-of-life date if known
- Last modified: the date and description of the last known change to the device or its program
- Owner/responsible person: who is accountable for this device (operations, maintenance, IT, vendor)
The physical walkdown
The most reliable way to build an OT asset register is a physical walkdown: visiting every control panel, substation, control room, and network cabinet and documenting what is actually there. Network discovery tools (such as Nmap) can assist in identifying devices on the network, but they cannot replace physical inspection for devices that may be present but not network-connected, or connected to a segment that the discovery tool cannot reach.
During the walkdown, photograph each panel and item. A photograph dated and labelled with the asset ID provides a reference point that is far more useful than a text description when a future engineer is trying to identify what they are looking at.
The walkdown almost always reveals items that were not in any previous documentation. Vendor-installed HMI panels, decommissioned equipment that is still powered, third-party devices added during maintenance: these are common findings. Every undocumented device is a potential vulnerability and a potential point of failure.
Capturing institutional knowledge
At sites where experienced engineers are approaching retirement, the asset audit is an opportunity to capture knowledge that would otherwise leave with them. Interview departing or retiring engineers specifically about:
- Equipment that is known to be unreliable and why
- Undocumented modifications that were made in the field without being recorded
- Custom logic or configurations that are not obvious from the documentation
- Historical events: past failures, workarounds that were applied, and whether they were ever properly resolved
Keeping it current
The most common failure mode of an OT asset register is that it is accurate at the time of creation and then never updated. Every change to the OT environment, whether a new device added, a firmware update applied, or a PLC program modified, should be reflected in the asset register.
The practical approach is to integrate asset register updates into the site’s management of change process. Any approved change to the OT environment that affects the asset register should trigger an update as part of the change completion.
Tools such as Rockwell FactoryTalk AssetCentre provide automated change tracking for Rockwell PLC and SCADA software. Every download to a PLC is logged with a timestamp, user, and before/after program comparison. This does not replace the broader asset register, but it provides an audit trail for the most critical OT assets.
About the author
Dennis Murphy RPEQ has delivered OT asset audits for Sugar Australia’s Racecourse Refinery, Mackay Sugar, and other Queensland industrial clients. Contact: [email protected]