What the Cyber Resilience Act requires of an SBOM

Last updated: 2026-09-29

The Cyber Resilience Act (Regulation (EU) 2024/2847) asks manufacturers to draw up a software bill of materials (SBOM) as part of vulnerability handling. The text asks for a commonly used, machine-readable format that covers at least the top-level dependencies, and it places the SBOM in the technical documentation. The requirement applies from 11 December 2027, with the main obligations of the regulation.

What the text says

The definition, Article 3, point (39):

"‘software bill of materials’ means a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements;"

The requirement, Annex I, Part II, point (1). Manufacturers shall:

"identify and document vulnerabilities and components contained in products with digital elements, 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;"

Where it is filed, Annex VII, point 2(b):

"necessary information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for the reporting of the vulnerabilities and a description of the technical solutions chosen for the secure distribution of updates;"

Who may ask for it, Annex VII, point 8:

"where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority provided that it is necessary in order for that authority to be able to check compliance with the essential cybersecurity requirements set out in Annex I."

The format, Article 13(24):

"The Commission may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials referred to in Part II, point (1), of Annex I."

Publication, recital 77:

"Manufacturers should not be obliged to make the SBOM public."

What this means in practice

The text names no format. Its words are "commonly used and machine-readable"; neither CycloneDX nor SPDX appears in the regulation. As of 29 September 2026 the Commission has not adopted an implementing act under Article 13(24) on the SBOM format and elements.
As written, the minimum depth is the top-level dependencies. The words "at the very least" set a floor, not a ceiling.
The SBOM belongs to vulnerability handling. Article 13(8) asks that vulnerabilities are handled when the product is placed on the market and for the support period.
The text does not ask for one SBOM per release in so many words. On a plain reading, a record of the components of each version placed on the market is what lets a manufacturer say which versions contain a given component.
The SBOM is part of the technical documentation, which Article 13(13) asks manufacturers to keep "for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer".
Publishing is the manufacturer's choice. Where the manufacturer decides to give users the SBOM, Annex II, point 9, asks for information on where it can be accessed.
Authorities may ask for it: on a reasoned request (Annex VII, point 8) and for a Union-wide dependency assessment (Article 13(25)).

What to keep as evidence

The SBOM of every version placed on the market, as the file your build produced.
A hash and a timestamp for each file, to show that it has not changed.
The name and version of the tool that generated it, and the format.
The vulnerabilities found in each version, when you learned of them and what was done. Article 13(7) asks manufacturers to "systematically document" relevant cybersecurity aspects.
Where the SBOM can be accessed, if you give it to users.

Where DevKit Dossier fits

DevKit Dossier keeps an SBOM archive per release. Your CI generates a CycloneDX or SPDX JSON file with Syft or Trivy and uploads it; DevKit Dossier is not a scanner, and it stores the file byte for byte with a hash and an upload timestamp. Every day it checks each release's current SBOM against OSV and GitHub advisories, CISA KEV, EPSS and NVD scores; it also builds a license inventory and an evidence pack (a ZIP with pack.json, pack.pdf, the SBOMs byte for byte and a README.txt) to attach to Annex VII technical documentation. It supports your evidence: it gives no legal advice, does not certify anything and submits nothing to ENISA's single reporting platform. It is hosted in the EU and self-serve, at a flat price per organisation of 49, 99 or 249 EUR per month with a 14-day trial.

Join the waitlist

Sources

Regulation (EU) 2024/2847 (Cyber Resilience Act)

This guide is general information, not legal advice.