When an ICS advisory lands, the question is simple: which of our controllers run the affected firmware, where are they, and what process do they run? Most OT sites cannot answer it from their records. This template defines an OT asset register that can: the fields to capture for PLCs, RTUs, safety controllers, HMIs, engineering workstations, historians, network devices and field instruments, with firmware, ownership, criticality, zone and process dependency for each. It follows the five-step process and the high, medium and low priority attributes in the joint CISA guidance Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators (August 2025), and uses ISA/IEC 62443 zones and conduits to tie each asset to its security requirements. It is written for OT security engineers, control and instrumentation engineers and site asset owners building a register in a spreadsheet, CMMS, OT security platform or CMDB. How to discover assets safely is covered in the OT Asset Visibility Guide; this page gives you the register itself.
How to use this template
- Replace bracketed text: [Organisation], [Site], [OT asset owner] and values such as [90 days] are placeholders for your own choices.
- Use the priority column: fields marked High, Medium and Low follow the CISA guidance priorities; fields marked Added are recommended by this template for vulnerability and incident work. Fill every High field before starting on Medium.
- One row per asset, one tab per site: keep common fields (Section 4) on every row and use Sections 5 to 7 for class-specific fields. Keep zone, conduit and dependency tables (Sections 6 and 7) on their own tabs and reference them by ID.
- Use fixed values: drop-down lists for asset type, criticality, zone, status and discovery method, so the register can be filtered by advisory, zone or criticality.
- Protect the register: it is a map of the plant. Store it with access limited to named roles, never put passwords or keys in it, and record where credentials are held instead. Handling rules belong in the OT Security Policy Template.
1. Purpose
1.1 This register records every OT asset at [Site] that monitors or controls a physical process, supports that control, or connects to the OT network, so that each asset has an accountable owner, a known criticality, a known firmware and software state and an assigned zone.
1.2 The register is the authoritative source for ICS advisory triage, patch planning, segmentation design, backup and recovery, incident response and audit. Discovery and monitoring tools feed the register; they do not replace it, because serial, fieldbus and isolated devices are often invisible to network tools.
2. Scope and asset classes
2.1 In scope: all assets at Purdue levels 0 to 3.5 and the IT/OT DMZ at [Site], including vendor-owned and leased equipment, portable engineering laptops and transient cyber assets, virtual machines and their hypervisors, and cloud services that receive or send OT data.
| Asset class | Examples | Typical record source |
|---|---|---|
| Controllers | PLC, RTU, DCS controller, safety instrumented system (SIS) logic solver, protection relay | Engineering project files, passive monitoring, walk-down |
| Field devices | Smart transmitters, drives, valve positioners, I/O modules, remote I/O | Instrument index, HART or fieldbus asset tools, walk-down |
| Operator and engineering systems | HMI, SCADA server, engineering workstation, historian, OPC server, alarm server | Endpoint agent where safe, passive monitoring, IT asset data |
| Network and security devices | Industrial switches, routers, firewalls, data diodes, wireless access points, serial-to-Ethernet gateways | Network management, configuration backups |
| Infrastructure | Hypervisors, domain controllers, backup servers, time servers, remote access jump hosts | Virtualisation console, IT CMDB |
| Transient and third-party | Vendor laptops, USB media stations, temporary diagnostic devices | Access logs, permit-to-work records |
2.2 Out of scope: [list, for example purely mechanical or pneumatic equipment with no electronics]. Record the reason for each exclusion.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [OT asset owner] (site or plant manager) | Accountable for register completeness and accuracy at [Site]; approves criticality ratings |
| [Control engineer] per process area | Maintains records for their area; updates the register in every change record |
| [OT security engineer] | Owns the register structure, reconciles it with discovery data, runs advisory matching and reports metrics |
| [Process safety lead] | Confirms which assets have a safety function and their criticality |
| [Integrator or vendor] | Supplies as-built asset data at commissioning and after any service visit |
4. Common fields for every asset
4.1 The fourteen CISA high-priority attributes are mandatory for every asset in scope. Where an attribute does not apply (for example IP address on a serial device), record "N/A, serial" rather than leaving it blank, so gaps can be told apart from non-applicable fields.
| Field | Priority | Format or allowed values | Why it matters |
|---|---|---|---|
| Asset number | High | Unique ID, [SITE-AREA-TYPE-nnnn]; match the tag on the device and in the CMMS | Joins register, maintenance and engineering records |
| Hostname or device tag | High | As configured on the device | Matches logs and monitoring alerts |
| Asset role or type | High | Drop-down from Section 2 classes | Drives class-specific fields and filters |
| Manufacturer | High | Canonical vendor name from a fixed list | Advisory matching |
| Model | High | Full model and part number, including hardware revision | Advisories name models and part numbers |
| Operating system | High | For example embedded RTOS, Windows 10 IoT Enterprise LTSC | Patch and end-of-support planning |
| IP address | High | IPv4 or IPv6; "N/A, serial" where not networked | Firewall rules, alert triage |
| MAC address | High | Colon-separated | Passive discovery reconciliation |
| Active or supported communication protocols | High | For example Modbus TCP, EtherNet/IP, PROFINET, S7comm, DNP3, OPC UA, IEC 61850 | Conduit rules and monitoring |
| Ports and services | High | Listening ports with service name | Attack surface, firewall rule review |
| User accounts | High | Local and domain accounts, including vendor and shared accounts; where credentials are vaulted | Access reviews, default credential removal |
| Logging | High | What is logged and where it is sent | Incident investigation |
| Physical location | High | Site, building, room, cabinet or panel, rack position | Response and walk-down |
| Asset criticality | High | High, Medium, Low per Section 5 | Prioritises patching, monitoring and recovery |
| Firmware or software version | Medium | Exact version string, plus date verified | The field most advisories key on |
| OS version | Medium | Build or patch level | Patch status |
| Department or owner | Medium | Named person | Accountability |
| Distributor | Medium | Supplier or integrator | Support and firmware sourcing |
| Physical or virtual | Medium | Physical, Virtual | Recovery method |
| VLAN | Medium | VLAN ID | Zone assignment check |
| Backup frequency and type | Medium | For example logic and configuration, weekly, offline copy | Recovery readiness |
| Baseline image | Medium | Golden image reference and date | Rebuild after incident |
| Serial number, date of manufacture, time source, local time zone, primary communication method, network monitoring, endpoint protection, notes | Low | Free text or fixed lists | Warranty, log correlation, coverage tracking |
| Zone ID | Added | From Section 6 | Links asset to security requirements |
| Process or function served | Added | Process unit and function, from Section 7 | Operational impact of an advisory or outage |
| Safety function | Added | Yes (SIS or protection), No | Change and patch restrictions |
| Support end date | Added | Vendor end of support or end of life, ISO 8601 | Replacement planning |
| Remote access path | Added | None, or jump host or vendor portal name | Exposure review |
| Discovery method and last verified | Added | Passive, active query, project file, walk-down; date | Data confidence and staleness |
| Lifecycle status | Added | Acquired, Commissioning, Operational, Spare, Decommissioned | Matches CISA life cycle stages |
5. Criticality rating
5.1 Rate criticality by importance to operations, safety and mission, as the CISA guidance describes. Use the highest applicable rating.
| Rating | Criteria | Expected treatment |
|---|---|---|
| High | Has a safety function; loss or manipulation could cause injury, environmental release, equipment damage or a site-wide outage; [loss of more than X hours production] | Most stringent controls: strict segmentation, role-based access, continuous monitoring, tested offline backups, advisory triage within [2 working days] |
| Medium | Loss degrades one process area or requires manual operation; no direct safety effect | Robust monitoring and regular updates; advisory triage within [10 working days] |
| Low | Loss has little operational effect, or a ready workaround exists | Basic controls; recorded for completeness |
5.2 Criticality is set by the [Control engineer] and approved by the [OT asset owner] and, for safety functions, the [Process safety lead]. For a structured method, see the OT Cyber Physical Risk and Safety Guide.
6. Class-specific fields
6.1 Controllers and safety systems
- Logic version: project file name, checksum or version, and date of last download to the controller.
- Key switch or operating mode: Run, Program, Remote, and whether mode changes are logged.
- Modules: communication and I/O modules with their own firmware versions, recorded as child assets.
- Engineering software: tool and version needed to program it, and which workstation holds it.
- Logic backup location: repository path and last verified restore.
6.2 HMIs, servers and workstations
- Installed applications and versions: SCADA, historian, OPC, vendor tools.
- Patch status and vendor-qualified patch level: last patch date and the vendor compatibility statement used.
- Endpoint protection or allowlisting mode: none, monitor, enforce.
- Service accounts: names, purpose and vault reference. See NHIs in OT.
6.3 Network devices
- Configuration backup reference and date; management interface and protocol; zones and conduits the device enforces.
7. Zones, conduits and dependencies
7.1 The CISA guidance organises assets into zones that share security requirements and conduits that control traffic between zones, following ISA/IEC 62443, and asks owners to document process dependencies and map communication paths. Keep these as separate tabs.
| Tab | Fields |
|---|---|
| Zones | Zone ID, name, Purdue level, process area, target security level, highest asset criticality, zone owner |
| Conduits | Conduit ID, source zone, destination zone, protocols and ports, direction, enforcing device, firewall rule references |
| Data flows | Source asset, destination asset, protocol, purpose, frequency, conduit ID |
| Dependencies | Asset, depends on (asset or service, for example time server, domain controller, licence server), effect if unavailable |
7.2 Use the OT Zones and Conduits Worksheet Template to define zones, and the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide for the design rules.
8. Keeping the register current
8.1 Update the register in every change record, including changes made under emergency change authority, before the change is closed. See OT Management of Change for Cyber.
8.2 Integrators deliver as-built asset data in this template's format at commissioning and after service visits.
8.3 Reconcile passive discovery data against the register every [month]; unknown devices are investigated within [7 days].
8.4 Walk down a sample of [10] assets per area every [6 months], checking nameplates, firmware and location against the register, and the reverse: [10] register rows checked on the floor.
8.5 Review the taxonomy and criticality ratings at least [annually] and after major plant changes.
Implementation guidance
- Define scope and objectives: pick one site or process area, agree the use cases (advisory triage, segmentation, recovery) and the owner. This is step 1 of the CISA process.
- Collect existing data before scanning: engineering project files, instrument indexes, CMMS records, network diagrams and configuration backups often give most of the High fields without touching the network.
- Add passive discovery: monitor SPAN or TAP traffic to fill IP, MAC, protocol and often firmware fields. Use active queries only where the asset owner approves them and vendor guidance confirms they are safe. See the Safe Active Scanning and Testing in OT Guide.
- Walk down what tools cannot see: serial and fieldbus devices, isolated panels and spare stock.
- Apply the taxonomy: set criticality and zones with engineering and safety input.
- Put it to work: run the next ICS advisory against the register and measure how long it takes to produce the affected list. See the ICS Advisory Triage and OT Vulnerability Management Guide.
- Extend site by site: reuse the field list and drop-downs so registers can be combined.
Choosing where to keep it
| Option | Suits | Watch for |
|---|---|---|
| Spreadsheet | Small sites, first pass, under a few hundred assets | Version control, access control, stale data |
| CMMS or EAM | Sites where maintenance already tracks equipment | Network and firmware fields often missing; add custom attributes |
| OT security platform | Larger or multi-site estates with passive monitoring | Blind to serial and isolated assets; still needs owner and criticality from engineers |
| IT CMDB | Organisations with mature IT asset management that covers OT | Access by IT staff to plant data; OT-specific fields and classes |
Metrics
- Completeness: percentage of assets with all fourteen High fields populated.
- Firmware confidence: percentage of controllers with firmware verified in the last [12 months].
- Reconciliation gap: unknown devices found by discovery per month, and median days to resolve.
- Advisory response time: hours from advisory publication to a list of affected assets.
- Support exposure: number of High criticality assets past vendor end of support.
Common failure patterns
- Device type without firmware: the register says "PLC" but not the module firmware, so advisories cannot be matched.
- Tool output treated as the register: monitoring sees networked devices only; serial, fieldbus and spare assets are missing.
- No owner or criticality: security fills the fields engineers should own, and ratings lose credibility.
- Emergency changes skipped: overnight replacements never reach the register.
- Register left open: a detailed plant map shared widely becomes reconnaissance material.
Framework mapping
| Framework | Reference | How this register supports it |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01, ID.AM-02, ID.AM-03, ID.AM-05, ID.AM-08 | Hardware and software inventories, communication maps, prioritisation, life cycle |
| NIST SP 800-53 Rev. 5 | CM-8, CM-8(1), CM-3, CP-9 | Component inventory, updates on installation and removal, change control, backups |
| CISA OT asset inventory guidance | Five process steps; attribute priorities | Sections 4, 5 and 7 and Implementation guidance follow them |
| ISA/IEC 62443 | Zones and conduits | Section 7 |
| ISO/IEC 27001:2022 | Annex A 5.9 | Inventory of information and other associated assets |
Standards and references
- CISA and partners: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
- CISA: Asset Inventory Guidance resource page
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology Security
- CISA and partners: Secure by Demand Priority Considerations for OT Owners and Operators
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: OT Security Guide · OT Security Checklist · IT Asset Inventory Template · OT Backup, Recovery and Golden Image Guide