An OT asset inventory is a maintained record of the devices, systems and software in an industrial environment, with the attributes needed to make security decisions. It tells you what each asset is, where it is, what it runs, who owns it and how much it matters to operations.
Almost every OT security activity depends on it. This guide explains what to record, where the data comes from, how to verify it and how to keep it useful.
Why an asset inventory matters
- Assessment scope. You cannot agree what an assessment covers without a list of what exists.
- Vulnerability decisions. A vendor advisory only matters if you know whether affected models and firmware versions are installed.
- Segmentation. Designing zones requires knowing which assets belong together and what they talk to.
- Incident response. Responders need to know what a suspicious device is, what it controls and who to call.
- Lifecycle planning. Obsolete and unsupported assets are a security and reliability concern.
Frameworks reflect this. Asset identification appears in IEC 62443-2-1, the NIST Cybersecurity Framework's Identify function and most regulatory expectations for critical infrastructure.
Decide what the inventory is for
Start with purpose, not columns. An inventory built only for vulnerability matching needs precise version data; one built for incident response needs ownership and dependencies. Write down the two or three decisions the inventory must support and let them drive the data model.
Also decide the scope and granularity. Will you record every I/O module, or stop at controllers? Will you include unmanaged switches and serial devices? Being explicit prevents an inventory that is detailed in one area and empty in another.
Asset attributes
A practical starting set:
| Attribute | Why it matters |
|---|---|
| Unique ID and name | Consistent reference across documents and tools |
| Asset class | Controller, HMI, server, workstation, network device, safety-related system, etc. |
| Manufacturer and model | Needed to match vendor advisories |
| Firmware / OS / software version | Determines vulnerability applicability and support status |
| Site and location | Where to go physically; area, building or cabinet |
| Network zone and segment | Which security boundary the asset sits behind |
| IP / communication interfaces | Where available and appropriate to record |
| Function | What process role the asset supports |
| Owner | Who is accountable for the asset |
| Criticality | Consequence of loss or compromise |
| Dependencies | What it relies on and what relies on it |
| Support status | Vendor support, end-of-life dates |
| Data source and verified date | Where the record came from and when it was confirmed |
Not every attribute is needed for every class. Keep the model as small as the decisions allow; a short, accurate inventory beats a long, stale one.
Collect and verify the data
Asset data in industrial environments is usually spread across several sources:
- Engineering drawings, I/O lists and network diagrams
- Control system configuration databases and project files
- Maintenance management (CMMS) records
- Vendor and integrator handover documentation
- Exports from monitoring or discovery tools, if already in use
- Site surveys and walkdowns
- The knowledge of engineers and technicians
Consolidate these into one structure, normalize vendor and model names, and resolve duplicates. Expect conflicts — two sources listing different firmware for the same controller is common.
Verification is what turns a list into an inventory. Verify the most critical zones first, through walkdowns, read-only configuration review or tool data, and record a verified date. Unverified records can stay, clearly marked as such.
A note on discovery tools: passive network monitoring and carefully planned active queries can help find and verify assets. Active scanning of control networks can disrupt sensitive devices and should only be done with vendor guidance and operational approval.
Assign ownership
Every asset needs an owner — a role or person accountable for its configuration, maintenance and security decisions. Ownership is often split between operations, engineering, IT and vendors. Make it explicit. Assets without owners are the ones that stay unpatched and undocumented.
Map network zones and dependencies
Link each asset to its network zone and record significant communications and dependencies, such as an HMI depending on a particular server, or several zones depending on one domain controller or time source. This information supports architecture reviews, zone and conduit models, and impact analysis during incidents.
Version and firmware information
Version data is the hardest attribute to keep accurate and one of the most valuable. Record the source of the version (configuration export, label, interview) and when it was captured. Track end-of-support dates so obsolete assets can be planned for. Version accuracy directly affects whether vulnerability decisions can be trusted.
Data quality and review cycles
Measure quality simply: the percentage of records with each key attribute, and the percentage verified in the last year, by zone or site. Then keep it current:
- Tie updates to change management. Any change that adds, removes or modifies an asset updates the inventory.
- Review periodically. At least annually, and after projects or outages.
- Report gaps. Known unknowns are useful information.
How inventory supports assessment and risk management
With a reliable inventory, assessments can be scoped precisely, risk scenarios can be tied to specific assets and their criticality, vulnerability advisories can be screened quickly, and segmentation can be designed around real systems. See A practical guide to OT cybersecurity assessments and Prioritizing OT cybersecurity risks.
Key takeaways
- Define the inventory's purpose before choosing attributes.
- Consolidate existing sources, then verify the most critical areas first.
- Record data source, verification date and owner for every asset.
- Link assets to zones and dependencies.
- Keep the inventory current through change management and periodic review.