Creating an SBOM in special machinery and plant engineering: where the data comes from when there is no source code

Tools for creating an SBOM run over the build and read package manager metadata. A packaging machine made of PLCs, HMIs, drives, industrial PCs and sensors from dozens of suppliers has neither. Why the common tools come up empty here is covered in a separate article on tool selection. This one addresses the counter-question: where does the data come from when there is no source code and the plant is no longer reachable after delivery?

The SBOM describes devices with firmware versions, not libraries

An SBOM from a software build describes packages and libraries – a level not accessible to a plant builder for purchased components. What can be described is the device level: which device from which manufacturer, running which software version, sits in the plant. That is the level industrial advisories work on as well. A manufacturer does not report "library X version Y is vulnerable" but "product Z up to and including firmware 2.4.7 is affected". A closed purchased component is therefore treated as a boundary node and not decomposed further – the reasoning is set out in the guide to the CRA and the Machinery Regulation. This must be distinguished from a plain hardware bill of materials: it states which device is installed, but not which software runs on it. Vulnerabilities attach to software versions, not to parts.

That also answers the question of depth, which decides half the effort: a flat list of devices with their firmware versions is enough, the software composition of each component does not belong underneath it. The regulation does not demand it – under Annex I Part II No. 1 CRA the software bill of materials has to cover "at the very least the top-level dependencies of the products" – and three further reasons speak for the flat form:

• The depth cannot be captured. What sits inside the firmware of a purchased PLC is known only to its manufacturer. Without their build and their SBOM only guessing is left, and a guessed dependency list looks like a finding in an audit.
• Depth would not change the response. If the firmware of a drive contains a vulnerable library, the only available action stays the same: wait for the supplier's firmware release and install it.
• Advisories arrive at product level. "Product Z affected up to firmware 2.4.7" matches a device list directly; the supplier has already done the translation from library to affected product version. Evaluating sub-component feeds yourself instead mainly buys noise – the order of magnitude, thousands of kernel CVEs per year from a single module, most of them without a score, is quantified in the guide to the CRA and the Machinery Regulation.

The principle has two limits. For your own software – your own PLC code, an IPC image you build yourself – there is a build and therefore a genuine, deep SBOM; the classic toolkit is the right choice there. And where you do need more depth, it comes from the supply contract: a clause guaranteeing machine-readable CSAF/VEX per release.

The three data sources

The data sits in three places, and they differ not only in content but in how much they can be trusted: the bill of materials says what was ordered. The engineering project says what was configured. Only the scan says what actually runs. Effort and the strength of the statement rise in that order.

Source 1: the bill-of-materials export from ERP, PDM and ECAD

The commercial and design view already exists in-house, usually in the ERP and partly in the PDM or PLM system. Per line item it supplies the manufacturer's article number – Siemens calls it the MLFB, others use their own order or type number – plus description, quantity, supplier, assembly position and the assignment to project, order and plant. That article number is the identifier manufacturer advisories use to name their affected products, and therefore the key to the later matching step. What the ERP does not know is which firmware runs on the device: goods receipt books an article number, not a software version.

This calls for an export from a system that is running anyway – the three usual systems are not equally suited:

• ERP. Supplies the order-related bill of materials with supplier and plant assignment. Weakness: purchasing carries order descriptions, not consistently normalised manufacturer article numbers.
• ECAD, usually EPLAN. For the control cabinet the more precise list: device tag plus the real manufacturer article number per device. Where both exist, the EPLAN parts list is the better starting point for advisory matching, and the ERP export the source for order, supplier and assignment.
• PDM/PLM. Adds the assembly structure – useful once a series model is maintained, dispensable for the first plant.

A CSV or Excel extract with the fields above is enough; the effort lies in making it reproducible and retrievable per plant.

Source 2: the engineering project and its hardware export

The engineering project is fully present at most machine builders and still rarely used. TIA Portal at Siemens, TwinCAT at Beckhoff, Studio 5000 at Rockwell, Automation Studio at B&R – each of these projects holds, for every configured device, the order or type number and the configured firmware version, exactly the field where the bill of materials ends. The export looks different per vendor; the content is the same.

The route is best documented at Siemens. The CAx export writes the configured hardware out as an AutomationML file; devices carry a type identifier of the form OrderNumber:6ES7 510-1DJ01-0AB0/V2.9 – order number, slash, configured firmware version. TIA Openness exposes the same attributes per device.

This is reliable for devices from the hardware catalogue that were configured with a concrete firmware version. For GSD/GSDML-based third-party devices the type identifier names the GSD file rather than an order number, and devices configured only as placeholders carry no defensible version. How large that share is in your own engineering standard is something a first export of a real project shows within five minutes.

Ready-made tools for this step exist mainly for the operator side: octoplant (AUVESY-MDT) cyclically backs up the controllers, and the Octovision layer on top turns that data into an asset inventory with CVE context; OTbase (Langner) merges engineering data and network discovery into one inventory. Both assume the software runs where the plant stands. Werkspilot works directly with the sources that are there anyway: the export goes in as the engineering system writes it, and is then held against supplier advisories continuously, per delivered plant.

Three reasons make the engineering project the second-best source. First, it describes the as-configured state: what gets configured is often "firmware version x or later", while what gets installed and swapped is the version the supplier ships at that moment. Second, it knows nothing about your own stock room: components that sat on the shelf for a while go into the plant with an older firmware version, and they are rarely updated before installation. Third, it only covers the automation scope: the industrial PC running the vision system, the camera system and the remote-access router do not exist for this source. As a starting point it still works, because it delivers order number and a first version assumption in one record.

Source 3: the network scan at acceptance testing or commissioning

A scan of the plant network captures what is actually installed. Per reachable device it typically yields manufacturer, type designation, firmware or software version, addressing and network structure. The firmware version is held in no commercial system and decides whether a plant is affected: two plants of the same series, delivered eight months apart, routinely carry different firmware versions of the same component because the supplier moved on in the meantime.

Equally important is what a scan does not see:

• Non-networked components. A hard-wired safety relay or a drive without an Ethernet connection does not appear in the scan – even though it carries firmware.
• Devices behind a fieldbus or safety circuit. Anything not directly on the IP network is visible at best indirectly, via the head module's entry.
• Devices that do not answer. Not every industrial device discloses type and version over a protocol that can be read passively.

Such a scan belongs in the acceptance window in your own works, run with tools that speak the automation protocols – which ones those are is set out in the article on SBOM tools. A scan in a running production plant at the operator's site is a different matter – and not one to be done casually.

The three sources compared

Combining them into one record per device

None of the three sources is an SBOM by itself. Using type designation and article number, they are merged into one record per device: what is installed from ERP, PDM or EPLAN, what was configured from the engineering project, which version actually runs from the scan.

By hand, that match does not scale. A mid-sized special machine has 80 to 150 network devices, and a plant builder delivers several per year. More importantly, the sources almost never spell the same device the same way: the scan reports what the device claims about itself over its protocol, while the ERP carries purchasing's order description. Spellings, spaces and suffixes for form factor or options diverge systematically; matching that up plant after plant costs more time than the scan and the export together.

The fastest way to make this concrete is on a real plant. Export the hardware from one plant's engineering project and we will match the devices against open vulnerabilities. A CAx export from TIA Portal, the equivalent from TwinCAT or Studio 5000, the parts list from EPLAN or the bill of materials from the ERP: no finished SBOM and no particular format required. You will see immediately how many line items map cleanly and where it snags. Bring an export.

What comes out is a list per plant: manufacturer, article number, description, software version, installation location, plus the provenance of each entry – measured, or taken from master data. The provenance decides in an audit how defensible a statement is.

Tools for the acceptance scan

For the scan in the acceptance window a commissioning tool serves better than a security product, and the best ones already sit on the engineering laptop: with Siemens, PRONETA and the TIA Portal online view; with Beckhoff, Rockwell or B&R, the respective diagnostic tool; plus Wireshark as a passive cross-check. From regular acceptance tests onwards, a discovery tool covering several vendor worlds pays off; OT monitoring platforms such as Claroty or Nozomi are built for the operator and are the wrong category for a one-off capture at acceptance. The tool comparison per route is set out in the dedicated article on SBOM tools for plant builders.

IT scanners such as Nmap and vulnerability scanners in their default configuration are as a rule unsuitable for plant networks. Older controllers and field devices answer aggressive port probing with a standstill in the worst case. Tools that ask in the protocols of automation, by contrast, do the same as any engineering station on the network.

What goes into the SBOM when CPE and PURL are missing

The established formats – CycloneDX and SPDX – normally expect CPE or PURL as the identifier. For industrial components these frequently do not exist at all.

That is no reason to change format, but a reason to choose the identifier realistically: manufacturer plus article number plus version. This is exactly how industrial advisories identify their affected products – the evidence, including an evaluated manufacturer feed without a single CPE, is set out in the article on tool selection. Both formats can carry such identifiers; the minimum content follows BSI TR-03183 Part 2.

A clean, complete list in CSV is therefore worth more than a formally correct CycloneDX file whose version numbers are guesses. No dedicated format tool is needed at first: converting a device list to CycloneDX is a solved problem, there are official libraries for it, and tools such as the CycloneDX CLI or sbom-utility check at the end whether the file holds up formally.

Capture happens at acceptance testing

The window for capturing this data is narrow. At acceptance testing or commissioning the plant is complete, powered, accessible and under your own control. After that it stands at the operator's site, frequently without remote access, and any later attempt becomes a reconstruction from wiring diagrams and delivery notes – that is, exactly the hardware bill of materials that does not know the firmware version. The scan therefore belongs in the acceptance procedure as a step, alongside functional testing and documentation. Anchored there, the SBOM for every future plant emerges as a by-product.

The cost argument behind this bites earlier than the commonly quoted year 2027 suggests. The regulation applies broadly from 11 December 2027, but the reporting obligation under Article 14 already applies from 11 September 2026 (Art. 71(2) CRA). Under Art. 69(3) CRA the obligations of Article 14 expressly extend to all products within scope that were placed on the market before 11 December 2027. For the installed base it stays at reporting – the remaining obligations, such as vulnerability handling, do not apply there (Commission FAQ, section 5.3). But you can only report what you can attribute, and Art. 14(8) additionally requires informing the affected users. That presupposes knowing which delivered plants contain the affected component.

This data therefore gets captured either way, only later and at greater cost: a plant that passes acceptance without a scan has to be reconstructed from wiring diagrams, delivery notes and memory – at a multiple of the effort, without the firmware versions, and with a weaker result than a single measurement would have produced. At ten deliveries a year, the next few acceptance tests decide how large the reconstruction backlog is in 2027.

For the installed base the realistic expectation is this: a permanently current field inventory across every delivered plant is a fiction. What exists is the documented as-delivered state plus your own touchpoints – service calls, retrofits, spare parts deliveries. Why that model holds and a live inventory does not is derived in detail there.

The goal is continuous matching, not a one-off list

Creating the SBOM is itself an obligation under the Cyber Resilience Act (Annex I Part II No. 1). The list alone is not the end of it – it is the basis for the actual goal: ongoing vulnerability management. Only once new supplier advisories run continuously against this inventory does it produce a statement – usually the all-clear that your own plants are not affected. It gets needed when the end customer asks or a report is due. The machine-readable format for it is a VEX statement. What satisfies the CRA is this continuous matching, not the file created once and filed away.

Five questions from practice

Is the TIA project enough as an SBOM?

As a starting point yes, as evidence no. The project knows the as-configured state of the automation scope – not the real firmware version after delivery, replacement and service calls, and not the devices outside the project. Anyone who can use only one source takes the scan.

Does the component manufacturer not simply supply an SBOM?

Rarely. For a purchased PLC, HMI or safety laser scanner there is usually no SBOM shipped with the product in 2026. From December 2027 component manufacturers must create an SBOM (Annex I Part II No. 1) – they are not obliged to pass it on to their customers. Recital 77 states expressly that there is no obligation to publish it; it has to be produced on the reasoned request of the market surveillance authority (Annex VII No. 8). Annex II No. 9 merely governs that the manufacturer states where the SBOM can be found, if they make it available at all. For everything delivered before then – and for the installed base of the next 15 years – compiling it stays with the plant builder. Delivery can be put in the contract; but you cannot rely on it across the board.

Is the hardware bill of materials from the ERP enough?

No, but it is half the work and the right starting point. Without the firmware version, an advisory only tells you a product might be affected. With an installed base of 200 plants, that is the difference between 200 suspected cases and a defensible statement about which plants are actually affected.

Does every delivered plant need its own SBOM?

In the result yes, in the effort no. Plants of one series share most of their bill of materials; the sensible approach is a maintained series model plus the deviations and firmware versions per delivery. Customer-specific options and the measured state make the individual plant unique – the basis stays shared.

How often does an SBOM need updating?

Not by calendar but by event. It changes when the plant changes: retrofit, component replacement, firmware update during a service call. Every touchpoint of your own is an opportunity to bring the record up to date. Between those events, the last known state is the most honest statement available.

How to start at your next acceptance test

Take one plant instead of a concept for the entire installed base: a CAx export from the corresponding engineering project beforehand as the skeleton, the scan as a step in the acceptance procedure, both merged once with the bill-of-materials export. After that you know the quality of your master data, the number of components the scan misses, the number of devices in the project without a version and the real reconciliation effort.

The pace here is not set by the 2027 calendar but by your acceptance schedule. Every plant that leaves the works before then without a captured as-delivered state is one more reconstruction case – and those dates are already in your planning. Discuss what this looks like for your plants.

Werkspilot monitors supplier advisories automatically and matches them against the field base of plant builders and integrators. This article reflects Werkspilot's assessment and does not constitute legal advice.