What the CRA actually requires for SBOMs, how deep they must go and why the sourcing process, not the tool, determines compliance.
Eine SBOM (Software Bill of Materials, German: software bill of materials) is, under the CRA, a formal record of the details and supply-chain relationships of the components contained in a product’s software elements. The regulation requires manufacturers to identify and document vulnerabilities and components, among other measures by creating an SBOM in a machine-readable format that at least reveals the first level of dependencies. It is part of the (internal) technical documentation, not a public document.
The CRA requires the SBOM at a single, clearly defined point. Annex I Part II number 1 requires manufacturers to identify and document vulnerabilities and components, and names the SBOM as the means to do so. Two requirements are decisive here, and both are more narrowly defined than is often assumed.
First, the format: a common machine-readable format. Practically used formats such as CycloneDX or SPDX satisfy this. Exactly which fields and elements a CRA-compliant SBOM must contain has not yet been conclusively determined. The Commission will specify the format and the elements of the software bill of materials by implementing act. Until then, the open requirement in the annex applies.
Second, the depth: the SBOM must reveal at least the top-level dependencies. The regulation does not here demand a complete resolution of every transitive dependency down to the last nesting level. That is an important relief: anyone who knows the top level of their components fulfills the legal minimum depth.
The SBOM is also not standalone. It belongs in the technical documentation that the manufacturer must create anyway. It is therefore a building block of vulnerability handling, not an isolated extra document.
Do you have to disclose the SBOM to your customers?
No. This question causes a lot of uncertainty, but the regulation’s answer is clear. Manufacturers are to determine and document which components are contained. There is explicitly no obligation to publish the software bill of materials.
Who sees the SBOM depends on who asks:
| Who | Gets to see the SBOM? |
|---|---|
| Market surveillance authority | on justified request, insofar as required for conformity assessment |
| Customer / user | no, no obligation to hand it over |
| Public | no, no publication obligation |
For the market surveillance authority there is a submission on request: on justified demand the manufacturer must present the SBOM if this is necessary for the authority to verify compliance. Market surveillance authorities can also request the SBOM in the context of a joint Union dependency assessment. Confidentiality is preserved: dependency information is only shared anonymously and in aggregate.
There is no obligation to hand it over to the user. The information duties only require indicating where the SBOM is accessible, if the manufacturer makes it available to the user at all. Whether you pass the SBOM on to customers therefore remains your choice. You are not obliged to do so.
The SBOM is therefore initially an internal tool for technical documentation and your own vulnerability handling. That shifts attention away from the question “How do I present it?” to the actually relevant question: How is a reliable list created in the first place?
Why creating the SBOM is not the real hurdle
Here is our core thesis, deliberately a practical assessment rather than normative text: creating the SBOM is not the real hurdle if development is structured cleanly. Anyone who already knows which libraries, modules and purchased components they use when building their product already has the top level of dependencies effectively in mind and usually recorded in build files. The SBOM simply puts that knowledge into a machine-readable format.
It becomes critical exactly where that knowledge about your own components is incomplete. Those who integrate components without recording their origin, version and maintainer get limited help from even the best tool. A scanner can reveal many things retroactively, but it does not replace the decision that must be made before accepting a component.
For that reason, in our view the effort shifts to an earlier point in the development process: to when you select and assess a component. That is where the substance of the later list is created.
The components list is created during sourcing not at the end
Our practical recommendation is: enter every software component into an inventory already at sourcing, instead of reconstructing at the end of development what was used. The SBOM then ceases to be a separate project and becomes a by-product of orderly component management.
This approach aligns with a duty that the CRA states clearly. Anyone who integrates components obtained from third parties into their product must exercise due diligence to ensure these components do not impair the cyber security of the overall product. This explicitly applies to free and open source software as well. What this due diligence means in concrete terms is described by the CRA as follows: check the conformity of the component (including CE marking, insofar as the CRA applies), ensure the component receives regular security updates, consult relevant vulnerability databases or carry out additional security checks.
From this we derive a recommended approach: assess a component before you include it, not afterwards when a tool reports it. A library without an update history, a component with open entries in a vulnerability database, or a module without a clear maintainer is a decision best made before integration. Working this way, you simultaneously collect exactly the information that later forms the SBOM: name, version, origin, maintenance status. For the structural framework of such an approach the BSI TR-03185 on the secure software lifecycle provides good orientation. The special case of free and open source software is discussed in depth under CRA and open-source software.
Vorlagen für den CRA-Komponentenprozess
On the templates page you will find tools to support the structured building of your component inventory before a new third-party component flows into your product.
Where do tools sit in the V-model — on the right
Tools for software composition analysis have their place, but it is not at the beginning. In our view tools sit on the right side of the V-model: they validate the component list, they do not create it. The list arises on the left, planning branch, when you set requirements, procure components and assess them before integration. On the right, testing branch, a scanner then compares what was actually built against that list and reveals discrepancies.
This order is more than a formality. Whoever runs the tool first and treats the hits as the list accepts uncritically what happened to end up in the code by chance. Whoever assesses first and then scans, uses the tool as a check on a deliberate decision.
What scanners don’t see — firmware versions and commercial third-party components
Tools have blind spots, and you should know them before you rely on a scan. In practice scanners and SCA tools reliably detect open-source packages because their metadata is openly available and well catalogued. For commercial third-party components and concrete firmware versions they often remain blind. These details are not in searchable code but in the supplier’s documentation. You must enter them manually into the inventory from supplier information.
| What tools reliably detect | What must be entered manually into the inventory |
|---|---|
| open-source packages and libraries | commercial third-party components without open metadata |
| declared dependencies in build files | concrete firmware versions of embedded modules |
| known versions with catalogue entries | information that only appears in supplier documents |
This brings us back to the duty of care. To know what is inside a purchased component you need the supplier’s information, and you need it before the tool runs. A supplier self-disclosure is, in our view, the most practical way to fulfil this due diligence and obtain the information a scanner does not provide for commercial components. Which role in the supply chain is responsible for the SBOM depends on whether you act as manufacturer, importer or distributor; we address that separately in the article on vulnerability and SBOM obligations in the supply chain. How to practically secure supplier attestations is shown in the VDMA document series on supply chain security.
What you should do now
The following steps are a practical recommendation derived from the duties mentioned. They intentionally shift effort forward so that the SBOM almost produces itself at the end.
- Keep a component inventory and record every component already at sourcing with name, version, origin and maintainer.
- Assess every component before integration: check conformity, update history and entries in vulnerability databases.
- Request supplier information for commercial third-party components and embedded firmware, ideally a self-disclosure, and enter it manually into the inventory.
- Produce the SBOM in a common machine-readable format that at least maps the top-level dependencies, and include it in the technical documentation.
- Use scanners as verification, not as the source: let the tool compare the built product against your inventory.
- Keep the SBOM available for the market surveillance authority; handing it over to customers remains your decision.
If you organise component management this way, you will have fulfilled most of the CRA’s SBOM obligation before you even touch a tool. The timing of when the requirements apply to your products is set out in CRA transition periods.
Approach SBOM structure and sourcing processes deliberately
If you would like to know where your component inventory stands today and which steps make sense next, contact us. We will look at your specific situation, especially regarding firmware and commercial third-party components.
