Short answer: yes. The Cyber Resilience Act, Regulation (EU) 2024/2847, requires every manufacturer of a product with digital elements in scope to draw up a software bill of materials. It is one of the eight vulnerability-handling requirements in Annex I, Part II, which apply to every product in scope with no "where applicable" and no size threshold, from 11 December 2027.

The longer answer is three sentences in the Regulation, and each one settles a question people keep asking.

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".

Four things are fixed by that sentence.

It is mandatory. The SBOM is the named means of identifying and documenting components. There is no route to point 1 without one.

The format is "commonly used and machine-readable". The Regulation does not name CycloneDX or SPDX, and it does not need to: both are commonly used and machine-readable, and either satisfies the text. A spreadsheet is machine-readable in a weak sense and is not commonly used for the purpose; do not rely on it.

The depth is "at the very least the top-level dependencies". That is the floor, not the recommendation. Top-level means the packages your product declares directly. Transitive dependencies are where most known vulnerabilities actually sit, so a top-level-only SBOM meets the letter and leaves the vulnerability identification half of point 1 weak. Most tooling produces the full graph anyway.

It covers "the products", plural, per product. One SBOM per product with digital elements, per version that affects compliance (Annex VII, point 1(b) asks for the versions). A single organisation-wide SBOM does not satisfy it.

Where it goes: Annex VII, points 2(b) and 8

The SBOM is part of the technical documentation. Annex VII, point 2(b), lists "the software bill of materials" among the vulnerability-handling specifications the file must contain. It is a document you keep, dated, with the file, for ten years or the support period, whichever is longer.

Point 8 of the same annex answers the question everyone asks next: do we have to publish it? No. The SBOM is provided "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". It is disclosed to an authority, on request, with a reason. Nothing in the Regulation requires publishing it to customers or the public, though nothing forbids it either: Annex II, point 9, says that if the manufacturer decides to make the SBOM available to users, the user information must say where it can be accessed. A customer's security questionnaire may ask for it regardless.

What it does not settle

Format details. The Commission can specify the format and elements of the SBOM by implementing act (Article 13(24)). Until it does, "commonly used and machine-readable" is the standard and the two open formats meet it.

Depth beyond top level. The Regulation sets a floor. Whether an authority, a notified body or a customer will accept top-level only is a practical question with a predictable answer: the deeper the SBOM, the fewer questions.

Hardware components. Point 1 says "vulnerabilities and components", and the SBOM is a software bill. For a hardware product the file still has to identify components (Annex VII, point 1(c) wants the internal layout), but the machine-readable requirement is stated for software.

What to do

Generate the SBOM from the build, not by hand, in CycloneDX or SPDX, for each product and each compliance-relevant version, and store it with the technical file. Keep the generation in the release pipeline so the file's SBOM is the shipped product's SBOM and not last quarter's. Write a one-page SBOM procedure that says which tool, which format, which depth, where it is stored and who answers a reasoned request; that procedure is one of the four operating documents Part II presumes exist, and it is what an auditor asks to see before the SBOM itself.

And keep the vulnerability side in view: point 1 is "identify and document vulnerabilities and components". The SBOM is the components half. The vulnerabilities half is the scanning that reads it, and the moment that scanning shows an exploited vulnerability, Article 14's 24-hour clock is the next thing to think about.

What the Regulation then asks of you for each component on that list, due diligence under Article 13(5), reporting upstream under Article 13(6) and the 'known exploitable vulnerabilities' test at release, is the companion article, from the Commission's guidance.

Sources

  • Regulation (EU) 2024/2847, Annex I, Part II, point 1 (quoted); Annex II, point 9; Annex VII, points 1(b), 1(c), 2(b) and 8; Article 13(24) on the implementing act for SBOM format; Article 71(2) for the dates. Read from the Official Journal text on EUR-Lex on 11 September 2026.

This is not legal advice. The three sentences above are short enough to read in the Regulation itself, which is where a decision about your product should rest.