You Cannot Secure What You Cannot See: Building an OT Asset Inventory

A production line rarely arrives as one neat, self-contained system and stays that way. It acquires a replacement drive here, a new HMI there, a remote support connection added during an urgent breakdown, and perhaps a reporting link into the wider business network. Each change may be sensible on its own, yet over several years the picture held in drawings, software folders and people’s memories can drift away from the equipment that is actually running the factory.

That gap matters. If a site does not know which controllers, industrial computers, network devices, software versions and external connections it depends on, it becomes much harder to assess risk, plan an upgrade or recover confidently after a fault. Building an OT asset inventory gives engineering, operations and IT teams a shared starting point. Done properly, it is not a cyber security exercise imposed on production; it is a practical record of the systems on which production already relies.

An OT asset inventory is more than an equipment list

The National Cyber Security Centre defines an OT asset inventory as an organised, regularly updated list of an organisation’s systems, hardware and software, including attributes such as manufacturer, model and supported communications protocols. Its current guidance on creating a definitive view of OT architecture goes further, however. It treats the inventory as one part of a continually maintained record that also explains how assets connect, what they support and how people and processes interact with them.

That distinction is useful in a factory. A spreadsheet showing that a PLC exists is helpful; knowing which line it controls, where its project file is held, which HMI and remote I/O depend on it, who can make changes and whether a supplier connects remotely is far more valuable. The aim is not to collect technical detail for its own sake, but to create enough context for better decisions.

The NCSC describes its approach as principles-based guidance, with goals rather than blanket minimum requirements. The depth of an inventory should therefore reflect the site, the consequences of disruption and the complexity of the control environment. A small standalone machine and a plant-wide SCADA system will not need identical records.

What should an OT asset inventory contain?

There is no single template that suits every manufacturer, but a useful inventory should help a competent person identify an asset, understand its role and locate the information needed to support it. The following fields provide a sensible starting point and can be adapted to the site:

• Identity and location. A clear asset name or identifier, physical location, production area and responsible owner.
• Function and dependency. What the asset controls or monitors, which process depends on it and the likely operational or safety consequence if it becomes unavailable.
• Technical details. Manufacturer, model, hardware revision, relevant firmware or software version, operating system where applicable, and supported industrial protocols.
• Connectivity. Network address or segment where appropriate, required communications, connected systems, gateways, wireless links and any route to enterprise, cloud or third-party services.
• Support and lifecycle. Supplier, warranty or support status, known obsolescence concerns, maintenance arrangements and any restrictions on updating or replacing the asset.
• Engineering information. Where approved drawings, PLC or HMI project files, configurations, backups, manuals and change records are stored, together with their current revision status.

The inventory should point to sensitive engineering records, not become an uncontrolled container for passwords, encryption keys or unrestricted copies of every configuration. Access to those items needs to follow the organisation’s own information-security arrangements.

Build the record without disrupting production

For many established factories, the most realistic starting point is not a network discovery tool. It is the information the business already has: electrical and control drawings, panel schedules, machinery manuals, PLC and HMI project folders, backup records, purchase information, maintenance systems and the knowledge held by engineers and trusted suppliers. Comparing these sources often exposes the first useful gaps, such as a machine that has been modified without a drawing update or a remote connection whose purpose is no longer clear.

Passive monitoring can help confirm which devices communicate and may reveal undocumented changes. Active scanning requires much more care. The NCSC’s collection guidance warns that point-in-time active scanning can overwhelm some legacy devices and cause performance problems, freezing or crashes. Any scanning activity should therefore be assessed and planned by competent OT specialists, tested for the environment and, where relevant, validated with the original equipment manufacturer. General IT discovery practices should not simply be applied to a live control network without considering the operational consequences.

A phased approach is usually more manageable. Sites can begin with the production systems whose loss would have the greatest effect on safety, quality or output, then expand the record as confidence and ownership improve. This avoids turning the exercise into an enormous data-collection project that never reaches a usable first version.

Map relationships, criticality and ownership

An inventory becomes genuinely useful when it shows relationships. A drive may depend on a PLC, the PLC on an industrial switch, the HMI on a server, and the maintenance team on a vendor’s remote-access service. If those links are not visible, a change that looks local can create a problem somewhere else.

The NCSC recommends recording the communications an asset needs, the protocols involved, the security controls already in place and the wider dependencies around each connection. Its guidance also suggests categorising assets by criticality, exposure and availability. Those headings translate well into practical engineering questions: what happens to the process if this device fails, how reachable is it, and how much downtime can the site tolerate while it is maintained or replaced?

Ownership matters just as much. Engineering may understand the process, IT may manage the surrounding network, a machine builder may hold the original project file, and an external integrator may support the software. The inventory should make those boundaries clear, particularly for remote access and systems that cross from the production environment into business reporting, data storage or cloud services.

Keep the inventory accurate and protect what it reveals

An OT asset inventory is useful only while people trust it. That means updating it when equipment is installed, modified, temporarily connected, moved or retired, rather than relying on a major audit every few years. Commissioning and handover are natural control points: a project should not be considered fully closed until the agreed asset details, drawings, software backups and support information have been added to the site record.

Clear ownership helps. One person or role should be accountable for the record, while nominated contributors supply updates from engineering, IT, procurement and external projects. Version control and a simple approval process make it possible to see what changed and why. Periodic validation is still worthwhile, but it should confirm an active process rather than rebuild the inventory from the beginning each time.

The record itself also needs protection. It can reveal network structure, software versions, remote connections and critical dependencies, all of which may be valuable to an attacker. The NCSC’s OT information-security guidance recommends proportionate controls around confidentiality, integrity and availability. In practice, that means limiting access to people who need it, controlling who can edit it, maintaining an audit trail and keeping resilient backups that remain available during an incident.

From cyber visibility to better engineering decisions

Cyber security may provide the prompt, but the value of an OT asset inventory is broader. Maintenance teams can find the correct software and drawings more quickly. Engineering managers can see where unsupported equipment, single points of failure or missing backups create operational risk. Project teams can scope alterations with fewer assumptions, while procurement can ask better questions about documentation, remote access and lifecycle support before new equipment reaches the factory floor.

It also supports recovery. When a controller, industrial PC or network component fails, knowing the exact device, configuration, dependencies and approved backup location reduces uncertainty. The inventory cannot replace a tested recovery plan or properly maintained spares, but it provides the information those arrangements depend on.

AES works with manufacturers on control panel design and build, PLC and HMI programming, machinery integration, automation upgrades and the electrical infrastructure around production systems. As part of that work, AES can help identify installed control assets, clarify dependencies and improve engineering documentation and handover information. Where a site requires a formal cyber security assessment, penetration testing or organisation-wide risk programme, the work should involve appropriately qualified OT cyber security specialists, with controls, IT and operational teams working together.

If your factory has accumulated undocumented changes, ageing controllers or unclear support arrangements, an OT documentation and controls review can provide a sensible starting point. AES can help you understand the engineering picture, prioritise practical gaps and make future automation work easier to manage.

FAQs

What is an OT asset inventory?

An OT asset inventory is an organised, regularly updated record of the systems, hardware and software used to monitor or control physical processes. It normally includes identifying details, location, function, communications, ownership and supporting engineering information. It should form part of a wider understanding of the site’s OT architecture and dependencies.

Is an OT asset inventory the same as a network diagram?

No. A network diagram shows how systems communicate, while an asset inventory records information about the individual assets. The two should support one another. An inventory without connectivity can miss important dependencies, while a diagram without asset detail may not help with maintenance, vulnerability review or recovery.

How often should an OT asset inventory be updated?

There is no universal interval that suits every site. The record should be updated whenever relevant equipment, software, connectivity or ownership changes, with periodic checks used to confirm accuracy. The frequency and depth of those checks should reflect the criticality and pace of change in the environment.

Can we use active network scanning to find OT assets?

Possibly, but it should not be treated as a routine IT scan. Some legacy OT devices may react badly to active scanning. The method, timing and scope require a site-specific assessment by competent specialists, with testing and OEM validation where appropriate. Existing records, staff knowledge, configuration data and passive monitoring may provide safer starting points.