SBOM under the CRA: obligation, content, format and BSI TR-03183-2
A software bill of materials is the inventory of the software in a product. The Cyber Resilience Act requires one from every manufacturer but does not prescribe a format. This page explains the obligation, the BSI's recommendation and how it connects with the reporting obligation.
The Cyber Resilience Act requires manufacturers to maintain a software bill of materials (Annex I, Part II, point (1)). This is a machine-readable list of the software components that make up a product, covering at least the top-level dependencies. The manufacturer does not have to publish it. It forms part of the technical documentation and must be provided to the market surveillance authority on reasoned request. The Regulation does not specify a binding format. In Germany, Technical Guideline TR-03183-2 of the German Federal Office for Information Security (BSI) describes what a usable SBOM looks like: CycloneDX version 1.6 or later, or SPDX version 3.0.1 or later, with a fixed set of required data fields for each component.
Key points
- The SBOM is mandatory for every product with digital elements, as part of vulnerability handling (Annex I, Part II, point (1)) and of the technical documentation (Annex VII, point (2)(b)).
- The Regulation requires a commonly used, machine-readable format covering at least the top-level dependencies. BSI TR-03183-2 recommends going deeper.
- There is no obligation to publish it (recital 77). The market surveillance authority may see the SBOM on reasoned request.
- Vulnerabilities do not belong in the SBOM. VEX and CSAF exist for that purpose.
- Without an up-to-date SBOM, you cannot quickly establish whether your product is affected by a vulnerability in a third-party component. The reporting deadlines do not leave time for that.
What is an SBOM and why does the CRA require one?
SBOM stands for software bill of materials. The term is modelled on the bill of materials used in manufacturing. Just as a machine is made up of assemblies and bought-in parts, the software in a product consists of the manufacturer's own code, third-party libraries, open-source components and often an operating system. The SBOM lists these components with their name, version and creator, in a form that software can read.
The reason for the obligation is practical. Most vulnerabilities are discovered in components that many manufacturers use. When a flaw becomes known in a widely used library, every manufacturer needs to know which of its products use it. With a list, that question can be answered in minutes. This ties in with the due diligence obligation in Article 13(5): components that are bought in or freely available must not compromise the security of the product.
What exactly does the Regulation require?
The obligation is set out in Annex I, Part II, point (1). Manufacturers must identify and document vulnerabilities and components contained in their products,
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
Annex I, Part II, point (1) CRA
Three things follow from this. First, the SBOM is a data format, not a table in a word processor. Second, the minimum is the top-level dependencies, meaning the components the product integrates directly. Third, the SBOM is part of the technical documentation (Annex VII, point (2)(b)), which must be provided to the market surveillance authority on reasoned request (Annex VII, point (8)).
The Regulation does not lay down the format, the fields or the depth beyond the top level. Article 13(24) empowers the Commission to specify format and elements by implementing act. As at 7 October 2026, no such act has been adopted.
Who may see the SBOM?
The SBOM is not a publication and not something to hand out to customers. Recital 77 says so explicitly:
Manufacturers should not be obliged to make the SBOM public.
Recital 77 CRA
Who may request the list follows from several provisions of the Regulation:
- The market surveillance authority on reasoned request (Annex VII, point (8), Article 53). In Germany, the draft German CRA implementation act (CRA-Durchführungsgesetz) assigns this role to the BSI.
- The notified body, if the product goes through third-party assessment (module B or H under Annex VIII).
- The administrative cooperation group of market surveillance authorities (ADCO) only indirectly: authorities can request SBOMs for Union-wide dependency assessments but share them only in anonymised and aggregated form (Article 13(25), recital 22).
- Users have no entitlement. A manufacturer that provides the SBOM voluntarily states where it can be accessed in the information and instructions to the user (Annex II, point (9)).
Customers are nevertheless asking for the SBOM more and more, particularly operators that are themselves subject to NIS2. That is then a matter for the contract, not an obligation under the CRA.
What does BSI TR-03183-2 recommend?
Part 2 of the BSI's Technical Guideline TR-03183 (version 2.1.0 of 20 August 2025) describes what an SBOM should contain. The guideline is voluntary, but it is the only guidance from a public authority in Germany that makes the requirement concrete, and it refers to the CRA itself. A manufacturer that follows it can explain why its SBOM is "commonly used" and complete enough.
Format
Two formats are permitted: CycloneDX version 1.6 or later, or SPDX version 3.0.1 or later, each as JSON or XML and only in officially released versions of the specification (section 4). Both are open standards that common tools can generate and read. Which one a manufacturer chooses matters less than sticking to the same one across all its products.
Required data fields
Each software version delivered needs its own SBOM in the documentation; when the software changes, a new one is created (section 3.1). Section 5.2 sets out what it must contain as a minimum:
| Level | Required data field | Note from the guideline |
|---|---|---|
| SBOM | Creator of the SBOM | E-mail address, otherwise a URL |
| SBOM | Timestamp | UTC recommended |
| Component | Component creator | E-mail address or URL |
| Component | Component name | Otherwise the actual filename |
| Component | Component version | Semantic Versioning or Calendar Versioning, otherwise the file's modification date |
| Component | Filename of the component | Actual name of the file delivered |
| Component | Dependencies on other components | Stating whether the list is complete |
| Component | Distribution licences | As an SPDX licence identifier |
| Component | Hash value of the deployable component | SHA-512 |
| Component | Executable, archive and structured property | Whether the component is executable, an archive or structured |
Where available, the SBOM URI, the source code URI, the URI of the deployable form of the component, other unique identifiers such as CPE or purl, and the original licences are added (sections 5.2.3 and 5.2.4). Optional fields are the effective licence, the hash value of the source code and the URL of the component creator's security.txt (section 5.2.5).
Depth
This is where the guideline goes further than the CRA. Section 5.1 requires every component within the scope of delivery to be resolved recursively along every path, up to and including the first component outside the scope of delivery; that third-party component must be identified at least by creator, name and version. In other words: your own components in full, plus the first level of whatever comes from outside. Section 8.3 distinguishes between a top-level SBOM (one level), an n-level SBOM and a transitive SBOM. SBOMs of supplier components may be referenced rather than embedded, provided they themselves comply with the guideline.
Do vulnerabilities belong in the SBOM?
No. The SBOM is a static list for each version. Which vulnerabilities are known in the components, and whether the product is affected, changes all the time and belongs in separate documents. The guideline excludes vulnerability information from the SBOM (section 3.1) and refers to two formats:
- VEX (Vulnerability Exploitability eXchange): a machine-readable statement by the manufacturer on whether a known vulnerability in a component actually affects the product.
- CSAF (Common Security Advisory Framework): a machine-readable format for security advisories covering the vulnerability, the affected products and remediation.
The SBOM says what is inside. VEX and CSAF say which of it is a problem and what the manufacturer is doing about it.
What does the SBOM have to do with the reporting obligation?
More than the wording suggests. The reporting obligation under Article 14 is triggered by an actively exploited vulnerability in your own product, with an early warning due within 24 hours of becoming aware. Most vulnerabilities a manufacturer hears about, however, initially concern a third-party component: a security advisory for a library is published, a customer asks, a security researcher reports a flaw in a component. The first question is then always the same: is this component, in this version, in our product?
With a maintained SBOM for each version, answering that is a matter of matching. Without an SBOM, it means days of investigation, and the deadline starts running during those days as soon as it turns out that the flaw is being exploited. The due diligence obligation presupposes the same. Recital 34 mentions checking components against the European vulnerability database (EUVD) or other publicly accessible databases. Article 13(6) requires the manufacturer to report a vulnerability in an integrated component to the component's manufacturer or maintainer and to remediate it itself.
According to the Commission guidance (paragraph 218), the assessment comes down to three questions: Is the vulnerable component included? Is the vulnerable code reachable in the product? Is the flaw being exploited in the product? Only the last question decides whether the reporting obligation applies; a published CVE entry (the public identifier of a known vulnerability) does not trigger it on its own. The result "included but not affected" should be communicated externally as VEX or CSAF, not recorded in the SBOM.
Where readiness comes in
CRA Response Center picks up where the SBOM leaves off: reports to the security address are classified, and for important reports the people responsible are alerted by SMS and e-mail, with awareness and deadlines recorded in the history. The tool knows the most important built-in components from the questionnaire completed during set-up, so it also recognises notices from suppliers. Checking whether a product is affected only works if the manufacturer knows, for each version, what is inside it. The SBOM is the foundation that makes 24 hours achievable at all.
Which tools does a manufacturer need?
Maintaining an SBOM by hand breaks down by the second version at the latest. Five categories of tool work together:
- Generation in the buildPackage manager extensions, container scanners or analysis tools for firmware without source code generate the SBOM with every build.
- Management and storageA repository holds the SBOM for each release, versioned and easy to find.
- Matching against vulnerability databasesSoftware composition analysis tools continuously check the list against vulnerability databases such as the EUVD and against vendor advisories.
- VEX and CSAF generationThe result of the assessment is recorded and distributed as a VEX statement or a CSAF advisory.
- ValidationValidators check whether an SBOM conforms to the specification and contains the required fields of TR-03183-2.
What matters is less the tool than the rule: no version leaves the building without an SBOM.
Common mistakes
- One SBOM for "the product" instead of one per version. If you only know the current version, you cannot establish whether customers running older versions are affected.
- Writing vulnerabilities into the SBOM. The list is out of date immediately. Vulnerability status belongs in VEX or CSAF.
- Only top-level dependencies, without stating completeness. Without a statement on whether the dependency list is complete, nobody knows whether a component is missing from the list or simply not included in the product.
- SBOM created once, never updated. Every change of component, including a library update, produces a new version with a new SBOM.
- Accepting supplier firmware without an SBOM. The due diligence obligation under Article 13(5) also applies to bought-in software.
What remains open?
As at 7 October 2026, the Commission has not used the empowerment in Article 13(24); whether a binding format will follow is open. The harmonised standard on vulnerability handling (prEN 40000-1-3) has not been cited in the Official Journal; whether it will set different requirements for depth or fields than the BSI guideline cannot yet be said.
Free templatesCRA Reporting KitReporting playbook, awareness record, notification templates for the ENISA platform, call chain and deadline calculator. Six Word templates, two Excel workbooks and a handbook, free by e-mail.Request the kitFrequently asked questions
Is an SBOM really mandatory?
Yes. Annex I, Part II, point (1), requires it as part of vulnerability handling, and Annex VII, point (2)(b), as part of the technical documentation, regardless of the product class.
What format must the SBOM be in?
The Regulation only says "commonly used and machine-readable". BSI TR-03183-2 specifies CycloneDX version 1.6 or later, or SPDX version 3.0.1 or later, as JSON or XML. So far there is no binding format set by implementing act.
How deep must the SBOM go?
The Regulation requires at least the top-level dependencies. The BSI guideline goes further: all of your own components in full, plus the first third-party component on each path with creator, name and version.
Do I have to give the SBOM to my customers?
No. Recital 77 expressly rules out an obligation to publish it. A manufacturer that provides it voluntarily states where it can be accessed in the information and instructions to the user (Annex II, point (9)). Customer requests for it are a matter for the contract.
Do known vulnerabilities belong in the SBOM?
No. The guideline rules this out because the SBOM is a static list for each version. Vulnerability status belongs in VEX statements or CSAF security advisories.
Do I need an SBOM for hardware without its own software?
Only if it contains code. Firmware counts as software and needs an SBOM.
Further reading
- Manufacturer obligations under Article 13 CRAAll obligations at a glance, from the risk assessment to record keeping.
- Actively exploited vulnerabilityWhy a CVE entry on its own does not trigger the reporting obligation.
- Support periodHow long security updates are required and what that means for the SBOM of each version.
- Glossary: BSI TR-03183The technical guideline and its parts in two sentences.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13(5), (6), (24) and (25), Article 53, Annex I, Part II, point (1), Annex II, point (9), Annex VII, points (2)(b) and (8), recitals 22, 34 and 77, Publications Office of the EU, 20 November 2024.
- Commission guidance on the application of the Cyber Resilience Act, Annex to Communication C(2026) 5252, paragraph 218, European Commission, 27 July 2026.
- BSI TR-03183-2 Software Bill of Materials (SBOM), Version 2.1.0, sections 3.1, 4, 5.1, 5.2 and 8.3, German Federal Office for Information Security (BSI), 20 August 2025.
- Germany BSI SBOM Guidelines, FOSSA, 2025.
- The new CRA guidance in practice, Schutzwerk, 2026.