What is an SBOM in simple terms?

An SBOM is the ingredients list of a piece of software. For a specific release it lists every component with supplier, name, version, license and dependencies, in a machine-readable format such as SPDX or CycloneDX. When a vulnerability becomes known in an open-source library, the SBOM lets you quickly establish which products and versions contain it.

How often does an SBOM have to be updated?

With every shipped release. Because an SBOM describes the components of a specific version, each new version needs its own SBOM, archived with the artifact. BSI TR-03183-2 requires the same information that is available during the build, so the SBOM is best generated automatically in the build. As part of the technical documentation it is kept for at least ten years under Article 13(13) of the CRA.

Do I have to give the SBOM to customers?

Not under the CRA. Recital 77 makes clear that there is no duty to publish it. The SBOM is part of the technical documentation and has to be provided to the market surveillance authority on a reasoned request. Many customers still require it by contract, because they need it for their own vulnerability and supply chain management. If you provide it voluntarily, the user information has to state where it can be accessed.

SPDX or CycloneDX: which SBOM format should I choose?

Both are established and both are accepted by BSI TR-03183-2: CycloneDX from version 1.6 and SPDX from version 3.0.1, each as JSON or XML. The CRA itself only requires a commonly used, machine-readable format. What usually decides is which format your build tools produce reliably and which your customers and analysis tools can read. Under Article 13(24) the Commission may specify the format by implementing act.

What is the difference between an SBOM and VEX?

The SBOM says which components are in a product. A VEX document (Vulnerability Exploitability eXchange) says whether a known vulnerability in one of those components is actually exploitable in that specific product, for example because the affected function is never called. Together they spare customers from analyzing vulnerabilities that have no consequence for them.

What does Rizzqo carry around the SBOM?

The working frame around it: the CRA catalog is held in the platform, build environment, repositories and suppliers are recorded as assets with an assignable owner, and the requirements appear on those assets through category and subcategory. They are finalized with a name and a timestamp.

What is an SBOM? Software bill of materials

Key takeaways (as of October 2026)

An SBOM (software bill of materials) lists every component of a software release with supplier, name, version and dependencies in a machine-readable format.
The Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers of products with digital elements to draw up an SBOM from December 11, 2027 that covers at least the top-level dependencies (Annex I Part II point 1).
Manufacturers do not have to publish the SBOM (recital 77); as part of the technical documentation it must be kept for at least ten years or for the support period, whichever is longer.
The CRA prescribes no format; BSI TR-03183-2 (version 2.1.0) requires CycloneDX from version 1.6 or SPDX from version 3.0.1, as JSON or XML.
An organization that only uses software has no SBOM duty under the CRA, but it can request SBOMs from its suppliers.

What is an SBOM, and what does it contain?

An SBOM is the machine-readable list of the components that make up a specific software release. It lists every included component with its supplier, name, version and dependencies, covering in-house modules as well as open-source libraries and purchased parts. The Cyber Resilience Act defines the software bill of materials in Article 3(39) as a formal record of the details and supply chain relationships of the components included in the software elements of a product.

Required fields under BSI TR-03183-2

The CRA itself does not prescribe the individual fields. The BSI technical guideline TR-03183-2 (version 2.1.0, August 20, 2025) is more specific. At a minimum it requires:

Level	Required field under BSI TR-03183-2	What it is for
SBOM	Creator (email address, otherwise a URL)	Contact for questions about the SBOM
SBOM	Timestamp of compilation	Ties the SBOM to a build and a release
Component	Component creator	Who develops and maintains the component
Component	Name and version	Matching against vulnerability databases
Component	Filename	Locating the file in the delivered package
Component	Dependencies, with a statement on completeness	Tracing transitive risk
Component	Distribution licenses	License compliance
Component	Hash of the deployable component (SHA-512)	Proving exactly which file is meant
Component	Properties: executable, archive, structured	Classifying the file during analysis

Where available, further data is added, such as the source code URI and unique identifiers like Package URL (purl) or CPE, which let components be looked up in vulnerability databases.

Is an SBOM mandatory?

For manufacturers of products with digital elements, yes, from December 11, 2027. Article 13(8) of Regulation (EU) 2024/2847 requires manufacturers to handle vulnerabilities in their product, including its components, in line with Annex I Part II. Point 1 of that Part requires them to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies. Annex VII point 2(b) also lists the SBOM as part of the technical documentation. The BSI also describes the SBOM as mandatory under the CRA in TR-03183-2. How this duty fits into the rest of CRA implementation is set out in the guide to the CRA.

Three limits of the SBOM duty

The addressee is the manufacturer. An organization that only uses software has no SBOM duty under the CRA. It does, however, have a legitimate interest in getting SBOMs from its suppliers; how manufacturer and operator duties differ is covered in the comparison CRA vs NIS2.
The duty is not retroactive. Under Article 69(2), products placed on the market before December 11, 2027 are subject to the requirements only if they are substantially modified after that date. The exception in paragraph 3 covers only the reporting obligations under Article 14, which have applied since September 11, 2026.
What is required is a minimum. The Regulation asks for the top-level dependencies. An SBOM that shows only that level is of little help when a vulnerability sits deep in the dependency tree.

Publication: no duty, but disclosure on request

Recital 77 makes clear that manufacturers should not be obliged to make the software bill of materials public. Under Annex VII point 2(b) it is part of the technical documentation, and under Annex VII point 8 it has to be provided to the market surveillance authority on a reasoned request, where the authority needs it to check compliance. If the manufacturer makes the SBOM available to users voluntarily, Annex II point 9 requires it to state where the SBOM can be accessed.

EU-wide dependency assessments

In addition, under Article 13(25) the administrative cooperation group (ADCO) can decide to run an EU-wide dependency assessment for certain product categories; for that purpose market surveillance authorities can request SBOMs from manufacturers.

Formats: SPDX, CycloneDX and the BSI TR-03183-2 requirements

The CRA names no particular format; it asks for a commonly used, machine-readable one. Article 13(24) empowers the Commission to specify the format and elements of the SBOM by implementing acts. Two formats are in wide use, SPDX and CycloneDX, and BSI TR-03183-2 accepts both.

Aspect	Minimum under the CRA	BSI TR-03183-2 (version 2.1.0)
Legal nature	Regulation, directly binding	BSI technical guideline, not a legal act
Format	commonly used and machine-readable	CycloneDX from version 1.6 or SPDX from version 3.0.1, as JSON or XML
Depth	at least the top-level dependencies	recursive for every component in the scope of delivery, up to and including the first component outside it
Fields	not specified individually	required and additional fields for the SBOM and each component

Following the TR puts you above the legal minimum. That is a deliberate choice, not a duty, but it saves rework if the Commission later fixes format and elements by implementing act.

How do you create an SBOM in 6 steps?

An SBOM is produced in six steps, from generation in the build to a named owner for new vulnerabilities:

Generate it in the build. The SBOM is produced automatically by the build process, not maintained by hand afterwards. BSI TR-03183-2 requires the same information that is available during the build.
Version it per release. Every shipped version gets its own SBOM, archived together with the artifact. As part of the technical documentation it must be kept under Article 13(13) for at least ten years or for the duration of the support period, whichever is longer.
Match it against vulnerability data. The component list is checked continuously against vulnerability databases. Only this step turns the SBOM into a tool for vulnerability management.
Assess exploitability. Not every reported vulnerability in a component is exploitable in the product. That assessment can be recorded in a VEX document (Vulnerability Exploitability eXchange) and shared with customers.
Bring in suppliers. For purchased components, SBOMs are requested by contract. Article 13(5) already requires manufacturers to exercise due diligence when integrating third-party components.
Assign responsibility. Someone has to act when a new vulnerability affects a listed component. Without a named owner, the SBOM stays an archive document.

The order in which the other CRA duties fall due is set out in the article CRA compliance: what manufacturers must do now.

SBOM, asset inventory and vulnerability management: who uses what

The SBOM describes what is inside a product; the asset inventory describes what an organization runs. The two meet in vulnerability management: the manufacturer uses the SBOM to find affected releases, and the operator uses its suppliers' SBOMs to see which systems in use are affected. For operators the SBOM is therefore mainly a supply chain security tool that they can request in tenders and contracts, and a complement to IT asset management.

Rizzqo and the SBOM: the working frame

The Cyber Resilience Act is held in Rizzqo as a requirement catalog. Build environment, repositories, software libraries and suppliers can be modeled as supporting assets with category, subcategory and an assignable owner, and linked to one another. Requirements appear on the matching assets through category and subcategory. Answers are finalized with a name and a timestamp, and the fulfillment rate is computed from the finalized answers.

Browse all entries Back to top

Software Bill of Materials (SBOM)