In brief · As of October 2026
The CRA prescribes neither a specific format nor a list of fields for the SBOM. From 11 December 2027, Annex I Part II(1) requires manufacturers to identify and document the components of a product, including by drawing up an SBOM in a commonly used and machine-readable format covering at the very least the top-level dependencies. Concrete fields such as producer, name, version, unique identifier and dependency relationship appear only in the draft standard prEN 40000-1-3, which does not yet confer a presumption of conformity. BSI TR-03183-2 goes further with hash and licence and is not binding. For a plant, we read the top level as the devices with manufacturer, order number and firmware version.
The question now comes up regularly in project meetings: the customer wants an SBOM, but what has to be in it? Answers range from a spreadsheet of devices to a CycloneDX file listing every library in every firmware. Neither answer can be derived from the regulation.
This article therefore separates, in every section, what is an obligation, what the draft standard provides and what we recommend. Where the data for a plant SBOM comes from is covered in the article on creating the SBOM in plant engineering. This one is only about content.
What does the CRA text require of the SBOM?
The obligation is a single sentence. Under Annex I Part II(1) CRA, manufacturers shall “identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”. Art. 3(39) defines the software bill of materials as “a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements”. This applies from 11 December 2027 (Art. 71(2)).
That is all. The text names no specific format but requires one that is commonly used and machine-readable. It contains no list of fields, no obligation to cover transitive dependencies and no hash values. A specification that says the CRA requires “an SBOM according to TR-03183” states a customer requirement, not a legal one.
Who gets to see the SBOM?
The SBOM is part of the technical documentation: Annex VII(2)(b) lists it under the vulnerability handling processes. Under Annex VII(8) it is to be provided to the market surveillance authority further to a reasoned request, where the authority needs it to check compliance with the essential requirements. In addition, market surveillance can request SBOMs for an EU-wide dependency assessment by the ADCO (Art. 13(25)).
Towards the customer, the text is deliberately restrained. Recital 77 states that manufacturers should not be obliged to make the SBOM public. Annex II(9) only covers the case where the manufacturer decides to make it available to the user: the user information must then say where it can be accessed. A supply contract clause “deliver the SBOM” is therefore a contractual matter. It can make sense, but it does not follow from the CRA.
Is there an implementing act on format and fields?
Art. 13(24) CRA allows the Commission to specify the format and elements of the SBOM by implementing act. Such an act would be binding. As of October 2026 we are not aware of any such act; the Commission’s overview of CRA implementation (updated 27 July 2026) lists it neither as adopted nor as planned.
The Commission’s interpretive documents are silent on content as well. The Commission FAQ v1.4 of 4 September 2026 mention the SBOM only under due diligence for third-party components: reviewing the SBOM of a component, “when available”, is listed as an example (No. 4.4.2). The guidelines C(2026) 5252 of 27 July 2026 do not address the SBOM. Both documents are interpretation and not binding. How suppliers fit into this who do not even publish machine-readable advisories is covered in the article on suppliers without CSAF.
What does the draft standard prEN 40000-1-3 provide?
It becomes concrete only in the draft harmonised standard on vulnerability handling, prEN 40000-1-3 by CEN/CENELEC JTC 13, currently at CEN Enquiry. Clause 5.2.8 requires producer, name and version for every software component (PRE-7-RQ-02), plus a dependency relationship and a unique identifier per component; the draft gives CPE, PURL and SWHID as examples (PRE-7-RQ-07). The SBOM itself needs a structured, machine-readable format with SPDX and CycloneDX as examples (PRE-7-RQ-04), metadata with author, version and timestamp (PRE-7-RQ-06), and a new edition for every new build or release (PRE-7-RQ-05).
Two points often treated as mandatory are only risk-based requirement enhancements in the draft. Transitive dependencies are to be included “when technically feasible” (PRE-7-RQ-03-RE); a note concedes that suppliers often cannot provide the necessary information. The draft requires a component hash only if the supplier provides it (PRE-7-RQ-07-RE). For hardware components, clause 5.2.9 has a separate list: producer, component name, component identifier and, if applicable, firmware version (PRE-8-RQ-02).
None of this is an obligation. A presumption of conformity arises only once the reference of the final standard has been published in the Official Journal (Art. 27(1) CRA), and the wording may still change until then. Following it nevertheless gives the best available indication of what conformity assessment is likely to rely on.
What role does BSI TR-03183-2 play?
The German BSI’s Technical Guideline TR-03183-2 is the most detailed field catalogue in the German-speaking region. The current version 2.1.0 of 20 August 2025 requires JSON or XML in CycloneDX 1.6 or higher or SPDX 3.0.1 or higher. Required fields for the SBOM are creator and timestamp; per component they include creator, name, version, filename, dependencies, distribution licence and a SHA-512 hash of the deployable component. Dependencies have to be resolved recursively, at least up to the first component outside the scope of delivery.
The BSI itself states that the guideline is not binding and confers no presumption of conformity; harmonised standards are to replace it. The draft standard refers to it in one place only, a note on the top-level SBOM. For a plant built from purchased devices, filename and SHA-512 per firmware part are usually not obtainable. We therefore consider the TR a good yardstick for your own software with your own build and a poor template for a plant specification.
Does the Machinery Regulation require an SBOM?
No. The Machinery Regulation (EU) 2023/1230, applicable from 20 January 2027, has no software bill of materials. The closest provision is Annex III Part B, section 1.1.9: the machinery shall identify the software installed on it that is necessary for it to operate safely, and shall be able to provide that information at all times in an easily accessible form. That concerns safety-relevant software and its version, not the components and supply chain relationships the CRA has in mind. We still see it as a point of connection, because the software versions of the safety equipment have to be readable anyway.
How do we read the obligation for a plant?
From here on it is interpretation. This is how we at Werkspilot read it, as an assessment and not as legal advice:
- The top-level dependencies of a plant are the installed devices with their firmware. Each device appears with manufacturer, order number and firmware version, linked by the relationship “plant contains device”. This matches the hardware list in PRE-8-RQ-02 of the draft standard.
- In OT, the unique identifier is in practice manufacturer plus order number plus firmware version. Industrial advisories identify hardware that way, not by CPE: as of 7 October 2026 the Siemens CSAF feed contains 841 advisories and no CPE. What other manufacturers do is shown in the comparison SBOM by manufacturer.
- Hashes are rare for purchased firmware. The draft requires one only if the supplier provides it; where the manufacturer publishes it, it belongs in the SBOM.
- A transitive SBOM for purchased components is not required and cannot be captured without the supplier’s build. Your own software, such as an IPC image you build yourself, is different: there is a build, and a deep SBOM is feasible.
- The customer requirement “deliver the SBOM” is governed by the contract. The CRA does not require passing it on (Recital 77, Annex II(9)).
Which fields belong in a plant SBOM?
The table shows the form, not the content. Each row names the source, how binding it is and where the information typically comes from in an OT project.
| Field | Source | Obligation / draft standard / recommendation | Obtainable in OT from |
|---|
| Top-level components (devices) | Annex I Part II(1) CRA | Obligation from 11 Dec 2027 | Bill of materials from ERP or EPLAN, engineering project |
| Commonly used, machine-readable format | Annex I Part II(1) CRA; PRE-7-RQ-04 | Obligation, format open | Export as CycloneDX or SPDX |
| Producer | PRE-7-RQ-02, PRE-8-RQ-02 | Draft standard | Bill of materials, rating plate, scan |
| Component name | PRE-7-RQ-02, PRE-8-RQ-02 | Draft standard | Bill of materials, engineering project |
| Version or firmware version | PRE-7-RQ-02, PRE-8-RQ-02 | Draft standard | Project (target), scan at acceptance (actual) |
| Unique identifier | PRE-7-RQ-07, PRE-8-RQ-02 | Draft standard; order number as key: recommendation | Order number from bill of materials or project, I&M data via scan |
| Dependency relationship (“plant contains device”) | PRE-7-RQ-07 | Draft standard | Plant structure from project or bill of materials |
| Metadata: author, version, timestamp | PRE-7-RQ-06; TR-03183-2 Table 2 | Draft standard | Set when the SBOM is created |
| New edition per release | PRE-7-RQ-05 | Draft standard; per acceptance and firmware update: recommendation | Acceptance record, service visit |
| Component hash | PRE-7-RQ-07-RE; TR-03183-2 Table 3 (SHA-512) | Draft standard, risk-based, only if supplied | Rare; only where the manufacturer publishes it for the firmware |
| Transitive dependencies | PRE-7-RQ-03-RE | Draft standard, risk-based, “when technically feasible” | Not for purchased parts; for your own software from your own build |
| Licence | TR-03183-2 Table 3; prEN only as a note | TR, not binding | Manufacturer information, often missing for firmware |
| Serial number | PRE-8-RQ-02, Note 3 (optional) | Recommendation | Scan, rating plate |
| Where the SBOM can be accessed, in the user information | Annex II(9) CRA | Obligation only if the SBOM is made available to the user | Operating instructions |
What belongs in the specification today?
Anyone committing to an SBOM should fix the level: devices with manufacturer, order number and firmware version, as CycloneDX or SPDX, with author, version and timestamp, created anew at every acceptance test and after every firmware update. Deeper dependencies, hashes and licence information are services one can offer, but the CRA does not require them. We are following whether the Commission acts under Art. 13(24) and how the draft standard is finally worded, and will update this article.
Guide: the plant SBOM in five steps.
Which sources feed the device list, which scan method reaches which devices and how matching against manufacturer advisories works without CPE, compact as a PDF with a checklist per step.
Request the guide →
Werkspilot continuously checks the device list of delivered plants against the advisories of the component manufacturers. This article reflects the state as of October 2026 and is not legal advice. The regulation itself is authoritative; prEN 40000-1-3 is a draft standard, and the Commission FAQ and guidelines are not binding.
