Table of contents
- No build in machine building
- One controller, three names
- SBOM and VEX
- Supplier requirements
- Where to start
On 14 July 2026, Siemens published nine security advisories in a single day (SecurityWeek, 15 July 2026). For a large manufacturer, that is an ordinary month. Anyone using Siemens controllers in their machines must then answer the same question: which of the machines we have delivered actually contain this?
Attackers often know sooner. They scan ports and read firmware versions, and frequently know more about a plant in the field than the manufacturer’s PLM (Product Lifecycle Management) system. Without a bill of materials, the manufacturer pieces the answer together from memory, circuit diagrams and supplier queries, which takes weeks.
Since September, there has been a deadline: under Article 14(2)(a) of Regulation (EU) 2024/2847, manufacturers must submit an early warning about an actively exploited vulnerability without delay and in any case within 24 hours of becoming aware of it. The early warning only requires the Member States in which the product was made available, not every affected customer site. But even that list can only be compiled within 24 hours if the mapping already exists.
There is no build in machine building
In software development, the SBOM is a by-product: the package manager knows which libraries are included, and tools such as Syft or Trivy read that out. Machine building has no such moment. There is design, engineering and commissioning, but no reproducible build.
On top of that, 80 to 90 per cent of the software in a typical machine comes from third parties: firmware in controllers, drives and network components, the operating system of the industrial PC, libraries in the PLC project. The bill of materials therefore has to be assembled from sources never intended for it: the PLC project, E-CAD (electrical design software), ERP (enterprise resource planning) and the controller manufacturers’ diagnostic tools. None is complete; the list only becomes useful once they are combined.
One controller, three names
Even a formally correct SBOM can be practically worthless. The same Siemens controller is listed in the vulnerability database as a CPE (Common Platform Enumeration), cpe:2.3:o:siemens:simatic_s7-1500_firmware:3.1.5, as a Package URL (purl), pkg:generic/siemens/simatic-s7-1500@3.1.5, and as 6ES7516-3AN02-0AB0 in the ERP system. The database only finds the first; only the last appears on the delivery note.
The result is errors in both directions: matches for components that are not installed, and no match for the one that is actually affected. Moreover, brand, manufacturer, legal entity and advisory publisher are rarely the same. The device says Hirschmann; the company behind it is Belden. Many medium-sized automation vendors publish via CERT@VDE, the German VDE (VDE Verband der Elektrotechnik Elektronik Informationstechnik e.V.) association’s industrial-security CERT. Searching only by manufacturer name means looking in the wrong places.
The SBOM asks the question, VEX provides the answer
One of our projects shows how little an SBOM achieves on its own. The SBOM for a single drive contained 340 components, and matching it against vulnerability databases produced 180 CVE (Common Vulnerabilities and Exposures) hits. After excluding the code paths that cannot be reached in the device at all, 26 remained. In the end, someone had to genuinely assess three.
The machine builder cannot take the step from 180 to 26 alone, because they do not have the source code. Only the supplier can, recording the result in an exploitability statement, the VEX (Vulnerability Exploitability eXchange). Without it, machine builders triage other people’s code at their own expense and never get beyond “probably not affected”.
What belongs in the specification
The CRA obliges every manufacturer, under Annex I, Part II, point (1) of Regulation (EU) 2024/2847, to create an SBOM, but they only have to hand it over to the market surveillance authorities, not to customers. What a machine builder receives from its suppliers is therefore a matter for the contract. We recommend six points for every order and every framework agreement:
- an SBOM (Software Bill of Materials) for the delivered component in CycloneDX 1.6 or later or SPDX 3.0.1 or later, updated with every firmware release
- an exploitability statement in VEX format, with a justification wherever “not affected” is claimed
- a named security contact, ideally a PSIRT (Product Security Incident Response Team)
- a machine-readable advisory channel based on CSAF 2.0 (Common Security Advisory Framework)
- a committed support period for security updates
- an obligation to pass on actively exploited vulnerabilities without delay
The second point determines the value of the others, and hardly any supplier offers it voluntarily.
Where to start
Getting started requires neither a tool decision nor a budget request. A real machine, a spreadsheet and someone with two days a week are enough for the first 90 days. The order matters: first the ability to assess matches and record the assessments, then the depth of the bill of materials. Going for depth first produces a list nobody can work through.
The installed base matters too. The CRA’s technical requirements largely apply to new products, but the reporting obligations also cover machines that have been running for years. Start with new products, then work backwards through the series with the largest installed base.
Ultimately, what counts is not whether an SBOM exists, but how long it takes from an advisory to an answer for the customer. At Complioty, we start with the PLC project every machine builder already has and work from there through the assessment to the published advisory. We describe the full approach in our white paper “O’zapft is. SBOMs for machine building”. Find it at: go.complioty.de/sbom-whitepaper
