OT Software Asset Management:  Ensuring Visibility and compliance

In most operational technology environments, software is treated as a feature of hardware – something that is commissioned and gets forgotten until it stops working.

That mindset is quietly becoming one of the most significant risks in critical infrastructure.

The Invisible OT Software Stack 

Ask most asset managers in power generation or utilities to enumerate their OT software assets, and you will get one of two responses: a list of vendors, or a blank stare.

That is not a criticism. It reflects how OT software has traditionally been treated as invisible infrastructure. It runs. It works. Do not touch it.

But beneath every operational environment lies a software stack: firmware, embedded OS, application logic, communication middleware, historian clients, HMI layers, and a web of dependencies that nobody has fully mapped out or fully understand. When that stack was last updated, or whether it has ever been updated – is often unknown.

This invisibility has a cost. And regulators are starting to notice the impact on the resilience of OT systems and the software associated with it.

What the Security of Critical Infrastructure Act Actually Demands

Australia’s Security of Critical Infrastructure Act (SOCI Act) has moved the conversation from aspiration to obligation. For operators in power, water, transport, and other regulated sectors, the message is clear – you are accountable for understanding and managing your critical assets – including the software that runs them.

But compliance is not just about checking a box. The organisations that will navigate this well are not the ones that scramble to document their software stack before an audit. They are the ones that have built genuine software asset governance into how they operate on a day-to-day basis. They are the ones that integrate their software and the tools to ensure resilient operation of their facilities. That is a meaningful difference.

What Does an OT Software Asset Actually Look Like? 

An OT software asset is not just the application binary. It includes: 

• The software itself – version, vendor, license status, and end-of-life date
• Its dependencies – third-party libraries, runtime environments, communication protocols
• Its configuration – which may drift over time, introduce vulnerabilities, or simply diverge from documented baselines.
• Its operational context – what process it controls, what failure looks like and who owns it and depends on it being operational.

A mature OT software asset register captures all of this and maps a clear dependency between the software, hardware, people and processes it supports.

What is considered OT specific software assets: OT software is any code, firmware, or configuration that controls or monitors physical processes.

Examples include:

Control & automation software: Firmware and configuration on PLC, DCSs and RTUs and safety instrumented system (SIS) logic.

Human-machine interface (HMI) & visualisation: SCADA applications, operator workstation software, and alarm management platforms.

Historian & data management: Process historians, data aggregation middleware, and reporting engines that sit between OT and IT.

Communication & networking software: OPC servers (OPC DA, OPC UA), protocol translators (Modbus, DNP3, IEC 61850), and industrial network, firewall/DMZ software.

Engineering & configuration tools: PLC/DCS programming environments, configuration management tools, and device calibration software.

Embedded operating systems: The OS running underneath all of the above often Windows XP/7/Server variants, VxWorks, or QNX which carry their own end-of-life risk entirely separate from the application layer.

Vendor-supplied utilities: Diagnostic tools, firmware update utilities, and remote access agents that ship with equipment and often get forgotten once commissioning is done.

Supporting software: Patch management tools, antivirus agents approved for OT use, backup and recovery software, and asset discovery and vulnerability management tools.

Software Asset Management in OT Environments: Maturity Is a Journey

The good news is that you do not need perfection on day one. Software asset management maturity in OT typically moves through recognisable stages: 

Level 1 – Reactive: Software is managed by exception. Patches happen when things break. Backups versions are unknown and unorganised. Source files are not catalogued and stored.

Level 2 – Aware: An inventory exists, but it is static, manually maintained, and partially accurate. Dependencies are not tracked or mapped out properly.

Level 3 – Governed: Asset registers are actively maintained. Lifecycle dates are tracked. Change management processes exist and are followed.

Level 4 – Optimised: Software assets are managed proactively. Dependency graphs inform risk decisions. End-of-life planning is built into capital programs. Compliance reporting is largely automated.

Most critical infrastructure operators today sit between levels 1 and 2. The gap to level 3 is achievable and the operational benefits extend well beyond compliance.

Treating OT Software as a Durable Asset

Capital assets get depreciation schedules. They get maintenance budgets. They get end-of-life planning and OT software should get the same treatment.

When organisations start treating their OT software as a durable, evolving asset – rather than a static feature of hardware – several things happen:

Visibility improves. You know what you have, where it runs, and when it needs attention.

Risk decisions get better. Dependency mapping reveals exposure that vulnerability scans alone will not catch.

Compliance becomes manageable. When your asset register is accurate and current, demonstrating it to regulators is straightforward.

Performance gains follow. Proactive lifecycle management means fewer unplanned outages caused by legacy software failure.

The Evolving OT Software stack

Walk through a modern SOCI-compliant program and you will find a software stack that would have been unrecognisable in most OT environments five years ago.

• Identity & access management (IAM) for OT – privileged access management (PAM) tools specific to OT environments, tracking who can access what system, remote access controls, and session recording. Increasingly a SOCI expectation.

• Patch management – distinct from vulnerability management, this is the workflow tooling that actually deploys, schedules, and tracks the application of patches across OT endpoints.

• Secure remote access (SRA) – dedicated OT remote access platforms that replace ad-hoc VPN or RDP sessions with audited, time-limited, vendor-managed connectivity. Highly relevant post-pandemic and under SOCI.

• OT-specific endpoint detection & response (EDR) – agents designed for industrial endpoints (engineering workstations, HMIs) that would not tolerate a standard enterprise EDR.

• Network monitoring platforms are being deployed to map traffic, detect anomalies, and provide the situational awareness that underpins incident response obligations.

• Vulnerability management tools continuously scan the OT environment to identify known weaknesses in software versions, firmware, and configurations – mapping findings against threat intelligence databases to help operators prioritise remediation before those weaknesses can be exploited.

• Syslog collection and OT- specific event management tools are aggregating log data from PLCs, HMIs, and historians that contain logs and information that generally lies hidden within the platforms.

• Configuration and change management solutions are creating baselines, tracking drift, and generating the audit trails of configuration changes that regulators expect to see.

• Backup and recovery tooling is being applied to engineering workstations and control system configurations that were never previously subject to any formal recovery process.

Each of these tools solves a real problem. Together, they represent a fundamental shift in the nature of the OT software environment – one that asset owners are only beginning to understand and implement across assets.

SBOM and Software Asset Management: Ensuring SOCI Act Compliance

As the OT software stack grows in complexity, a new question is emerging for critical infrastructure operators: do you know what is inside the software you are running?

A Software Bill of Materials (SBOM) answers that question. It is a structured inventory of every component inside a piece of software: the libraries it depends on, their versions, and their origins. For OT environments this matters acutely, because firmware embedded in PLCs, RTUs, and field devices has historically shipped as a black box. A firmware image might internally carry a known critical vulnerability, and without an SBOM, the asset owner has no way of knowing until something goes wrong.

Under Australia’s SOCI framework, supply chain transparency is an increasingly explicit expectation. The Australian Cyber Security Centre’s guidance on critical infrastructure risk management programs points directly to software supply chain risk as an area requiring active management -and SBOMs are the mechanism through which that management becomes practical.

Operators who cannot demonstrate visibility into the components running across their environment will find it increasingly difficult to satisfy their obligations under the Act as regulatory expectations tighten.

The governance implication is straightforward: an SBOM is not a one-time deliverable. It must be updated every time software changes, which means establishing processes to receive updated SBOMs from vendors as part of the normal patch and release cycle. For operators with a functioning asset register and active vulnerability management processes already in place, adding SBOM capability is the natural next step and the one that closes the supply chain visibility gap that every other tool in the stack cannot address on its own.

The Shift to Mature Software Management in Critical Infrastructure

The organisations ahead of the curve are not waiting for regulatory pressure to force their hand. They are building the governance foundations now because they understand that software underpins every physical asset they operate, and that visibility over their software stack is a prerequisite for operational resilience.

For critical infrastructure operators, the question is no longer whether to manage OT software as an asset. The SOCI Act, the threat landscape, and the operational complexity of ageing environments have settled that debate.

The question is: how mature is your approach to software as an asset – and what would it take to get to the next level?

Author: Rheinhardt Peens, Managing Director at Tier Sixteen.

I will be exploring this topic in depth by invitation from EESA at Engineers Australia Perth on 27 May 2026, covering OT software stacks, dependency management, maturity frameworks, and practical pathways for power generation and critical infrastructure operators. If you’re working through these challenges in your organisation, I’d welcome the conversation – feel free to check out our services here or connect with me on LinkedIn.