Do we have to hand the SBOM over to customers?

The CRA does not require that. The software bill of materials belongs to the technical documentation and must be provided to a market surveillance authority under point 8 of Annex VII further to a reasoned request, provided that it is necessary for that authority to check compliance with the essential cybersecurity requirements. No such statutory duty exists towards customers. Independently of that, more and more buyers ask for it contractually, particularly in the public sector and in regulated industries. If you maintain it in machine-readable form anyway, answering such requests costs nothing extra.

Do hardware components belong in the software bill of materials?

The legal definition explicitly covers components in the software elements of a product. Pure hardware parts therefore do not belong in the SBOM. The obligation in Annex I reaches further, though: manufacturers must identify and document vulnerabilities and components of the product as a whole. Hardware needs its own documentation, just not in the form of an SBOM.

Is our package manager’s dependency list enough as an SBOM?

As a starting point yes, as a finished bill of materials no. Package managers only know their own ecosystem and rarely emit supply chain relationships, unique identifiers or licence data in one of the common exchange formats. Most products span several ecosystems plus bundled binaries. Established SBOM tooling starts exactly there and merges the partial results into one document.

Cyber Resilience Act

Software Bill of Materials (SBOM)

Legal definition Art. 3(39) CRA

“a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements”

Regulation (EU) 2024/2847, Art. 3(39) CRA

A Software Bill of Materials answers a deceptively simple question: what is actually inside this product? Modern software consists largely of code written elsewhere, in libraries, frameworks and runtimes. If you do not know which components are built in, and in which versions, you cannot tell whether a newly published vulnerability affects your product.

That is why an SBOM is not a documentation exercise but the data foundation everything else builds on: vulnerability analysis, risk assessment and, when it matters, reporting on time.

What an SBOM contains

The Cyber Resilience Act (CRA) does not prescribe a list of fields, but a set of entries has become standard in practice:

Name and version of every component, with the version mattering most, because vulnerabilities are almost always version-bound
Origin, meaning the supplier or project behind the component
Licence, which governs legal usability alongside security
Dependency relationships recording which component pulls in which other one
Unique identifiers that allow automated matching against vulnerability databases

Supply chain relationships are explicitly part of the legal definition. A flat list without structure does not meet it.

What the Cyber Resilience Act actually requires

The obligation sits in Annex I, Part II, point 1. Manufacturers must identify and document vulnerabilities and components 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”.

Three details deserve a second look:

“Machine-readable” rules out PDFs and spreadsheets. An SBOM is meant to be processed, not read.
“Commonly used” deliberately names no specific format. The Commission may specify the format and elements later by implementing act.
“At the very least the top-level dependencies” is a floor, not a ceiling.

An SBOM does not have to be published. It belongs to the technical documentation, and a market surveillance authority may call for it under point 8 of Annex VII further to a reasoned request, provided that it is necessary to check the requirements of Annex I.

Formats: CycloneDX and SPDX

Not a single format is named in the regulation. Two have become established:

CycloneDX, which comes from the security world and is built around vulnerability context
SPDX, rooted in licence compliance and standardised as an ISO/IEC norm

Both qualify as “commonly used”. The choice is therefore less a compliance question than a tooling one: what matters is what your toolchain and your customers can process.

Top-level dependencies are only the start

“At the very least the top-level dependencies” is often read as permission to stop there. In practice that does not hold up: a substantial share of known vulnerabilities sits in transitive dependencies, that is, in components you never added yourself but which arrive through another component.

Recording only the top level satisfies the letter of the requirement while leaving much of your actual risk invisible. Most tools produce the full tree anyway; trimming it back saves nothing.

Common misconceptions

“One SBOM per product is enough.” An SBOM describes exactly one build. Every version with different components needs a new one, otherwise it documents a product you no longer ship.

“The SBOM is the vulnerability analysis.” It is the prerequisite for one. Only matching it against vulnerability databases turns the record into a statement about risk.

“We use no open-source components, so we do not need one.” The obligation attaches to components, not to their licence. Purchased and in-house building blocks belong in it too.

Practical questions

: The CRA does not require that. The software bill of materials belongs to the technical documentation and must be provided to a market surveillance authority under point 8 of Annex VII further to a reasoned request, provided that it is necessary for that authority to check compliance with the essential cybersecurity requirements. No such statutory duty exists towards customers. Independently of that, more and more buyers ask for it contractually, particularly in the public sector and in regulated industries. If you maintain it in machine-readable form anyway, answering such requests costs nothing extra.
: The legal definition explicitly covers components in the software elements of a product. Pure hardware parts therefore do not belong in the SBOM. The obligation in Annex I reaches further, though: manufacturers must identify and document vulnerabilities and components of the product as a whole. Hardware needs its own documentation, just not in the form of an SBOM.
: As a starting point yes, as a finished bill of materials no. Package managers only know their own ecosystem and rarely emit supply chain relationships, unique identifiers or licence data in one of the common exchange formats. Most products span several ecosystems plus bundled binaries. Established SBOM tooling starts exactly there and merges the partial results into one document.

This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.