What the regulation actually requires, how much depth is sufficient, and why the sourcing process — not the tool — determines compliance.
An SBOM (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 the manufacturer to identify and document vulnerabilities and components, among other things by producing 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 asks for the SBOM in a single, clearly defined place. Annex I Part II number 1 requires manufacturers to identify and document vulnerabilities and components, and mentions the SBOM as the means to do so. Two requirements are decisive, and both are narrower than often assumed.
First, the format: a common machine-readable format. Widely used formats in practice like CycloneDX or SPDX meet this requirement. Which exact fields and elements a CRA-compliant SBOM must contain has not yet been finally specified. The Commission will determine the format and elements of the software bill of materials by an implementing act. Until then, the open requirement in the Annex applies.
Second, the depth: the SBOM must at least show the top-level dependencies. The regulation does not require a complete resolution of every transitive dependency down to the last nesting level at this point. That is an important relief: anyone who knows their top-level components cleanly meets the statutory minimum depth.
The SBOM is also not a standalone item. It belongs in the technical documentation that the manufacturer must produce anyway. It is therefore a building block of vulnerability management, not an isolated additional 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 should determine and document which components are included. 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 over |
| Public | no, no publication obligation |
For market surveillance authorities, there is a requirement to present it on demand: upon justified request the manufacturer must provide the SBOM if this is necessary for the authority to verify compliance. Market surveillance authorities can also request the SBOM as part of a joint Union dependency assessment. Confidentiality is preserved: information about dependencies is forwarded only in anonymized and aggregated form.
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 does make it available to the user at all. Whether you share the SBOM with customers remains your decision. You are not obliged to do so.
The SBOM is therefore primarily an internal tool for technical documentation and your own vulnerability management. That shifts the focus away from the question “How do I present it?” to the actually relevant question: How is a reliable list produced in the first place?
Why creating it is not the real hurdle
Here is our core thesis, intentionally a practical assessment not a legal text: creating the SBOM is not the main hurdle if development is well structured. If you already know which libraries, modules and purchased components you use when building your product, you effectively already have the top-level dependency information in your head and usually also in your build files. The SBOM merely puts that knowledge into a machine-readable format.
Things get difficult where that knowledge about your own components is incomplete. If you integrate components without recording where they came from, which version they are, and who maintains them, even the best tool can only help to a limited extent. A scanner can uncover many things retroactively, but it does not replace the decision that must be made before a component is adopted.
That is why, in our view, the effort shifts to another point in the development process: forward, to the point where you select and assess a component. That is where the substance of the later list is created.
The component list is created during sourcing, not at the end
Our practical recommendation is: record every software component in an inventory at the time of sourcing, instead of reconstructing retroactively at the end of development what was included. The SBOM then ceases to be a standalone project and becomes a by-product of orderly component management.
This approach aligns with a duty the CRA clearly formulates. Anyone who integrates components obtained from third parties into their product must exercise due diligence to ensure those components do not impair the cybersecurity of the overall product. This explicitly also applies to free and open-source software. The CRA describes what that due diligence means in concrete terms: check the component’s conformity (including CE marking where the CRA applies), ensure the component receives regular security updates, consult relevant vulnerability databases, or perform additional security tests.
From this we derive a practical approach: evaluate a component before you adopt 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 collect the information that later constitutes the SBOM as you go: name, version, origin, maintenance status. For the structural framework of such an approach, BSI TR-03185 on the secure software lifecycle provides good orientation. The special case of free and open-source software is covered in more depth in CRA and open-source software.
SBOM template: keep a structured component inventory
Our SBOM template helps you record software components in a structured way from the outset — including work instructions for your development team and examples.
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 start. In our view, tools sit on the right of the V-model: they validate the component list, they do not create it. The list is created on the left, planning branch when you set requirements, procure components and evaluate them before integration. On the right, verification branch a scanner then compares what was actually built against that list and exposes deviations.
This sequence is more than a formality. Whoever runs the tool first and treats the hits as the list accepts, uncritically, whatever happened to land in the code. By contrast, those who evaluate first and then scan use the tool to check a deliberate decision.
What scanners do not see: firmware versions and commercial third-party components
Tools have blind spots, and you should know them before relying on a scan. In practice, scanners and SCA tools reliably detect open-source packages because their metadata is public and well catalogued. With commercial third-party components and specific firmware versions they often remain blind. These details are not in searchable code but in supplier documentation. You must enter them into the inventory manually from supplier information.
| What tools reliably detect | What must be entered into the inventory manually |
|---|---|
| Open-source packages and libraries | commercial third-party components without open metadata |
| declared dependencies in build files | specific 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 supplier information — and you need it before the tool runs. A supplier self-declaration is, in our view, the most practical way to fulfill this duty of care and obtain the details 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 treat that separately in the piece 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 deliberately shift effort forward so that the SBOM almost creates itself at the end.
- Maintain a component inventory and record each component at sourcing with name, version, origin and maintainer.
- Evaluate each 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-declaration, and record it manually in the inventory.
- Generate the SBOM in a common machine-readable format that at least reflects the top-level dependencies, and include it in the technical documentation.
- Use scanners as a control, not as the source: have the tool compare what was built against your inventory.
- Keep the SBOM available for market surveillance authorities; handing it over to customers remains your decision.
Organizations that set up component management this way will have fulfilled much of the CRA’s SBOM obligation before they ever touch a tool. When the requirements apply to your products is outlined in the CRA transition periods.
SBOM structure and sourcing processes tackled purposefully
If you want to know where your component inventory stands today and which next steps make sense, contact us. We will look at your specific situation, especially regarding firmware and commercial third-party components.
