ENISA SBOM Advisory Recommends More Than the CRA Requires
On October 22, 2026, the European Union Agency for Cybersecurity (ENISA) published its Technical Advisory for Software Bill of Materials. The document is written for small and medium-sized enterprises (SMEs) that are starting with the software bill of materials (SBOM). For these companies, it describes an automated pipeline in which every SBOM is signed after validation. This goes well beyond the obligation in Annex I, Part II, point 1 of the Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA. We do not recommend this pipeline to machine builders as their next step, because many of them do not yet know the firmware versions of the components they buy in.
The advisory is technical guidance for setting up SBOM processes. It binds no one and states explicitly that it does not interpret the CRA. It contains an architecture with data flows along an SBOM lifecycle, a threat model based on STRIDE, and countermeasures. It excludes hardware bills of materials (HBOM), cryptographic bills of materials (CBOM), and AI bills of materials (AI-BOM) and covers only the software bill of materials. We explain what an SBOM is and how to create one in our article on SBOM requirements under the CRA.
Contents
- The advisory is sector-neutral and does not mention machine building
- ENISA goes further than the CRA and the BSI guideline
- The advisory stays vague on supplied firmware and small manufacturers
- In machine building, the SBOM often lacks even the firmware version
- Inventory and risk assessment first, signing last
The advisory is sector-neutral and does not mention machine building
ENISA developed the text from a draft dated late 2025 and coordinated it with the CRA Expert Group. ENISA has announced further revisions. The advisory follows the principles of ENISA's Secure by Design and Default Playbook.
According to ENISA, the document is sector-neutral, and it does not mention machine building. Besides the architecture and the threat model, it lists open-source tools for each lifecycle phase.
ENISA goes further than the CRA and the BSI guideline
The advisory states that its recommendations may go beyond the requirements of the CRA. How far becomes clear when you compare it with the text of Regulation (EU) 2024/2847 and with Technical Guideline TR-03183-2. Germany's Federal Office for Information Security (BSI) publishes this guideline, and the advisory itself names it as the basis for its data fields:
| CRA | BSI TR-03183-2 (version 2.1.0) | ENISA advisory | |
|---|---|---|---|
| Depth | at least top-level dependencies (Annex I, Part II, point 1) | SBOM of the delivery item as MUST | no minimum depth of its own |
| SBOM type | not specified | build SBOM; without a build, equivalent information | starts at the build |
| Format | commonly used and machine-readable (Annex I, Part II, point 1) | CycloneDX 1.6 or later, or SPDX 3.0.1 or later, in JSON or XML | commonly used and machine-readable |
| Signature | not required | recommendation (“should”) in the explanatory annex | fixed step after validation |
| Sharing | kept in the technical documentation; provided to market surveillance authorities on reasoned request (Annex VII, point 8); provided to users voluntarily (Annex II, point 9) | supplier is responsible for the availability of referenced SBOMs | controlled sharing with access control |
| Legal status | regulation | technical guideline, not a legal norm | explicitly non-binding |
The depth in the CRA column is our reading. We equate the CRA's top-level dependencies with the top-level SBOM in the BSI guideline, meaning the primary component plus everything it depends on directly. None of the three sources says this. On that reading, the three documents form clear levels. The BSI guideline requires more depth than the CRA, and ENISA recommends more infrastructure than both.
On sharing, we keep running into the same conflict in our projects. Customers want to see the SBOM of the machine, and manufacturers do not hand it over. Under the CRA, customers have no right to it. The advisory supports this restraint: it names controlled sharing as a countermeasure against leaks of information about versions and supplier relationships. We explain how the CRA assigns obligations for SBOMs and vulnerabilities in who is responsible for vulnerabilities and SBOMs.
The advisory stays vague on supplied firmware and small manufacturers
For components supplied as binaries, the advisory refers to the analyzed SBOM. If such components cannot be fully analyzed, manufacturers should document the “known unknowns.” The BSI guideline classifies firmware images as archives that cannot be broken down into their original components. Neither source says how a manufacturer should define the top-level dependencies of such an image. For a purchased controller with a runtime system and a fieldbus stack, that decision determines what goes into the SBOM.
The second open point concerns the audience. The advisory addresses SMEs that are starting with SBOMs. For integration, it then assumes “mature continuous integration infrastructure and standardised build processes” and uses the wording “must be established,” although it declares itself non-binding. ENISA's SBOM Adoption State of Play 2026, on which the advisory draws, reports that 41% of respondents want to fully automate SBOM generation for each release or build. A smaller share, 26%, expect fully automated maintenance over the support period. ENISA itself calls automation after the build “work in progress.”
In machine building, the SBOM often lacks even the firmware version
A packaging machine with a purchased programmable logic controller (PLC), a human-machine interface (HMI) panel, and a remote maintenance router has no build of its own. The ENISA pipeline has nothing to attach to. The software sits in the suppliers' components and arrives as a binary image. Device makers with their own firmware have an easier time. Yocto, Zephyr, and Linux already generate SPDX, and the build only has to switch the feature on. If you build your own firmware and run continuous integration (CI), you should use this. ENISA's approach fits these manufacturers.
For machine builders, the problem starts one step earlier. At many of them, we see components kept in stock and reordered as needed. The firmware version changes between two purchases, and nobody in production writes it down. Two identical packaging machines can therefore leave the factory with different versions.
What counts for the SBOM is the version you deliver. That is almost always the firmware installed on the PLC, panel, and router at assembly, at the factory acceptance test, or at commissioning. Production must record this version for each machine. Many manufacturers have to change their production processes before an SBOM for the machine becomes possible.
Which SBOM does the CRA require from you?
Our template gives you a structure for your product's SBOM that you can add to your technical documentation.
Inventory and risk assessment first, signing last
We recommend that machine builders create the SBOM at the depth the CRA requires, and no deeper. The larger gaps are in the cybersecurity risk assessment, and that is where the effort should go first. You can spot this gap when a project raises questions like “Do we need secure boot?” but nobody knows which installed component carries risk at all. Another sign is the objection that the firmware version of the safety PLC does not matter because the PLC is not connected to the internet. As long as it is unclear where the risks in the product lie, SBOM questions come too early. We show how risk assessment is divided between manufacturer and operator in risk assessment under the CRA, the Machinery Regulation, and NIS2.
We consider signing and artifact binding the last step. If you cannot determine the firmware version of the automation components, a signature protects a list whose content is wrong.
On the starting point, we agree with ENISA. It recommends starting at the build and identifying the integration points first. This first step does not yet include a signature. The overview of CRA obligations for manufacturers lists which obligations besides the SBOM belong in the technical documentation.
For software and device manufacturers with their own CI, the advisory is a usable working basis. It does not address what machine builders need.
Define the SBOM depth for your machine
We work out with you which SBOM your machine needs under the CRA and which steps in production and risk assessment come first.
