SBOM has become one of those ideas that sounds obvious in a board presentation and messy the moment it reaches a real plant. In theory, it is simple. Ask every supplier what sits inside the software you run. In practice, OT estates are made up of PLCs with opaque firmware, SCADA stacks that have grown over the years, historians with connectors and plug-ins from different eras, and vendor appliances that were bought for uptime rather than transparency. The modern OT now looks much closer to IT than it once did, yet it still carries unique performance, reliability, safety, and change control constraints. That is why SBOM in OT is possible, but it has to be framed as an operational risk tool, not as a purity exercise.

The stronger question for the energy sector is not whether every OT product can produce a perfect SBOM tomorrow morning. The stronger question is whether operators can get enough component visibility to make faster decisions on patching, isolation, procurement, and incident response before they are forced into blind trust. That is also where policy is heading.

It is becoming common for manufacturers of products with digital elements to identify and document components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies, and to provide it to market surveillance authorities where needed for compliance checks. At the same time, explicit focus is put on refining data fields, automation support, and operational practices so that SBOMs are scalable and interoperable rather than theoretical.

Why OT makes SBOM harder

The software world often assumes continuous deployment, short release cycles, and an environment where change is routine. OT does not work like that. Change management is paramount in OT, that software changes must be thoroughly tested and rolled out carefully, that outages may need to be scheduled days or weeks in advance, and that many OT environments still rely on older operating systems and firmware that may no longer be supported by the vendor. That changes the value of SBOM. In enterprise IT, it can be a speed tool. In OT, it is first a decision confidence tool.

Also Read: How to navigate the investment opportunity in climate tech sector

This is why many operators still hesitate. They hear SBOM and imagine a flood of component data that creates work without reducing plant risk. That fear is reasonable if the programme is designed badly. A raw component list that is disconnected from asset criticality, patch windows, vendor support, and engineering ownership is not a control. It is an admin. The answer is not to reject SBOM. The answer is to define what useful visibility looks like in an industrial setting.

What SBOM should really mean

For PLCs, the industry needs to be honest. Most operators are not going to get perfect software transparency for every controller any time soon. But that does not mean nothing can be done. A practical PLC SBOM starts with the firmware image, the communications stack, the engineering workstation software used to configure the controller, and any embedded third-party components that materially affect exposure or patching decisions. In OT terms, that is already meaningful progress because it ties software transparency to the assets that can change physical behaviour. The software and firmware inventory, version numbers, vendor details, and SBOM information belong inside an accurate asset inventory and risk management practice.

Historians and SCADA systems are where SBOM adoption should move faster. These platforms are usually closer to standard operating systems, databases, application servers, remote access layers, and commercial software components. In other words, they are part of OT where component transparency is more achievable and more immediately useful. If operators are serious, this is where they should begin, because the effort is lower and the payoff in vulnerability management is more visible. SBOM data improves the speed and efficiency of vulnerability response, helps identify end-of-support components earlier, and becomes far more powerful when integrated into vulnerability management and asset management tools already in use.

Vendor appliances are the real test. These are the black boxes that every site depends on, and very few teams can fully inspect. They are also where operator frustration is highest. It is suggested that buyers seek manufacturers who include hardware and software bills of materials with product delivery and who commit to timely remediation. That matters because procurement is often the only moment when the operator has real leverage. If an appliance supplier still treats component transparency as optional, that is no longer a technical footnote. It is a signal about how seriously they take lifecycle accountability.

Also Read: What big tech won’t show you about the future of AI

The mistake is treating SBOM as a file rather than a workflow

The market still talks about SBOM as though the job ends once a JSON or XML file has been generated. That is far too narrow, especially in OT. SBOM includes workflows for acquisition, management, and use, while its sharing work distinguishes between authors, consumers, and distributors across the lifecycle. SBOM is only data until it is consumed and converted into insight that can drive action. That is the right way to think about OT. A plant does not need more documents. It needs better decisions.

This is also why SBOM without VEX will disappoint many operators. A component list tells you what is inside. It does not tell you whether a newly disclosed vulnerability is actually exploitable in your deployed configuration, or whether the vendor has already assessed the exposure differently. VEX can be used alongside SBOM to improve prioritisation and effectiveness. In OT, that matters enormously because patching is costly and often disruptive. The real value is not finding every theoretical issue. It is knowing which issues deserve scarce outage time.

Can we actually do SBOM in OT

Yes, but it needs a sequence that respects operational reality.

First, use procurement to shape the future estate. Regulations are moving in that direction, and buyers should use that momentum. New PLC platforms, historians, SCADA systems, remote access products, and industrial appliances should be bought with explicit expectations around SBOM, update support, vulnerability disclosure, and version control. This is the easiest part of the OT estate to improve because it relies more on commercial discipline than plant retrofit heroics.

Also Read: How to unlock possibilities through data privacy enhancing technologies

Second, treat legacy products differently from new builds. Binary decomposition of software installation packages is recommended to generate SBOMs where no vendor-supplied SBOM is available, including for legacy software, where technically and legally feasible. When software already exists, binary analysis tools can use increasingly accurate heuristics and datasets to infer underlying components. That does not solve every appliance or controller, but it creates a realistic middle path for brownfield environments.

Third, connect SBOM to asset inventory and criticality from the start. The accurate inventory of vendor, model, firmware, operating system, and software versions is central to identifying and remediating vulnerabilities. SBOM disclosures should be aligned with asset inventories for risk exposure and criticality calculations. That is the step that turns software transparency into plant relevance. Without it, SBOM remains a software artefact. With it, it becomes part of operational risk management.

—

Editor’s note: e27 aims to foster thought leadership by publishing views from the community. You can also share your perspective by submitting an article, video, podcast, or infographic.

The post SBOM for OT: Can we actually do it? appeared first on e27.