What the CRA Actually Requires of an SBOM, Clause by Clause

· Yunus Yildiz

The short answer

  • What: a software bill of materials "in a commonly used and machine-readable format covering at the very least the top-level dependencies" of the product (Annex I, Part II, point 1).
  • When: from 11 December 2027, with the rest of the Regulation (Article 71(2)). Only the Article 14 reporting obligation applies earlier, since 11 September 2026.
  • Publish it? No. "Manufacturers should not be obliged to make the SBOM public" (Recital 77).
  • Which format? None is mandated yet. Article 13(24) lets the Commission specify format and elements later, by implementing act.
  • Who can ask for it: market surveillance authorities, through the technical documentation (Annex VII) and, for Union dependency assessments, directly (Article 13(25)).

Everything beyond that floor comes from your customers, not from the Regulation. That distinction is the whole design problem.

The requirement, read closely

The SBOM appears in the CRA as the first of eight vulnerability handling requirements. 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;

Article 3(39) defines an SBOM as "a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements".

Five things follow from the text, and most of them run against common assumptions.

1. Depth: top-level dependencies are the floor

"At the very least the top-level dependencies" sets a minimum, not a target. The Regulation does not require the full transitive tree.

That does not make a top-level-only SBOM a good idea. The same point requires you to "identify and document vulnerabilities", and point 2 requires you to remediate them "without delay". A vulnerability three levels down in your dependency tree is still in your product. An SBOM that stops at the top level documents the minimum and leaves you blind to most of what you will have to fix.

2. Format: commonly used and machine-readable, nothing more specific

The text does not name a format. CycloneDX and SPDX are both commonly used and machine-readable; a spreadsheet is neither in the sense that matters.

Article 13(24) allows the Commission to "specify the format and elements of the software bill of materials" by implementing act, "taking into account European or international standards and best practices". Recital 118 lists the same power among the Commission's implementing powers. At the time of writing we have not found such an act. Until one exists, pick a format your tooling produces reliably and your customers can read, and keep the ability to convert.

3. Publication: not required

Recital 77 is explicit: "Manufacturers should not be obliged to make the SBOM public." Annex II, point 9 confirms the choice is yours: the user information must say where the SBOM can be accessed only "if the manufacturer decides to make available the software bill of materials to the user".

Publishing can still make commercial sense. It is a decision, not an obligation.

4. Audience: authorities

The SBOM belongs in the technical documentation. Annex VII, point 2(b) lists "the software bill of materials" among the vulnerability handling information that documentation must contain. Under Article 31, that documentation is drawn up before the product is placed on the market and "continuously updated, where appropriate, at least during the support period".

Article 13(25) adds a second route: for a Union-wide dependency assessment, market surveillance authorities "may request manufacturers of such categories of products with digital elements to provide the relevant software bills of materials", and pass on only "anonymised and aggregated information about software dependencies" (Recital 22).

5. Purpose: vulnerability handling

The SBOM is not a transparency deliverable in the CRA. It sits inside Part II, and Recital 77 states the reason: to "facilitate vulnerability analysis" and to help manufacturers and users "track known newly emerged vulnerabilities and cybersecurity risks". It is the input to the other seven vulnerability handling requirements and to your Article 13(5) due diligence on third-party components.

What the official interpretation adds: very little

If you are waiting for the Commission to settle the details, the current documents will not do it.

  • The Commission's implementation FAQ (version 1.4, 4 September 2026) mentions an SBOM once, as an example of due diligence on a component you integrate: "when available, reviewing the SBOM of that component" (FAQ 4.4.2).
  • The Commission's guidance of 27 July 2026, C(2026) 5252, which covers scope, substantial modification, support periods and reporting, does not use the term.

So for now the Regulation's own text, read with its recitals, is the reference. That is an argument for building to the text rather than to a rumoured future format.

Where your customers go further

The CRA floor and what your customers ask for are two different specifications.

Customers that fall under NIS2 must secure their supply chain, including their relationships with direct suppliers (Directive (EU) 2022/2555, Article 21(2)(d)), and must take into account "the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures" (Article 21(3)). In the Netherlands that duty has applied since 15 August 2026 under the Cyberbeveiligingswet (our Dutch article on what that means for suppliers).

In practice that turns into questionnaires that ask for more than the CRA does: the full dependency tree rather than the top level, a statement of which listed vulnerabilities are actually exploitable in your product, a specific format, and an SBOM per release rather than per product. None of those is in Annex I. All of them are reasonable for a customer to ask.

One SBOM per build, many exports

The mistake is trying to produce the SBOM: one document that satisfies an authority, a customer's security team and a procurement template at once. It does not exist, because they want different depths, formats and levels of disclosure.

What works is separating generation from presentation:

  1. Generate at build time, from the build. An SBOM produced later from whatever sits in a registry describes an artifact, not necessarily the one you shipped.
  2. Bind it to the artifact digest. Attach or attest it to the exact image or package it describes, so "which SBOM belongs to release 2.4.1" is a lookup, not a reconstruction.
  3. Record the full tree internally. The law's floor is the top level; your vulnerability handling needs everything.
  4. Sign it. An SBOM your customer cannot verify is an assertion, not evidence.
  5. Treat depth, format and redaction as export options. Top-level for the technical documentation minimum, full tree for a customer under NDA, CycloneDX or SPDX as requested. These are views of one record, not separate jobs.

That last point is where most of the recurring effort goes. Every customer asking in a different shape is manageable when each answer is an export of the same record, and unmanageable when each one is a new investigation.

Eurtifact applies this to the artifacts you pull from upstream: each version is scanned, given a CycloneDX SBOM, signed and attested to its digest, and recorded in an audit log. You can see it on real images in the demo.

Limits

  • The format may change. An implementing act under Article 13(24) could specify format and elements. Keep conversion cheap.
  • Top-level is a legal minimum, not a safe harbour. Remediation obligations reach vulnerabilities wherever they sit in the tree.
  • Products already on the market. Products placed on the market before 11 December 2027 are subject to the Regulation's requirements only if they are substantially modified after that date (Article 69(2)). The Article 14 reporting obligation is the exception and already applies to them (our Article 14 guide).
  • This is not legal advice. Classification of your product and the extent of your obligations need a qualified review.

Sources

  • Regulation (EU) 2024/2847 (Cyber Resilience Act): Article 3(39); Article 13(5), (24) and (25); Article 31; Article 69(2); Article 71(2); Annex I, Part II, points (1) and (2); Annex II, point 9; Annex VII, point 2(b); Recitals 22, 77 and 118. On-site OJ text, EUR-Lex
  • European Commission, CRA implementation FAQ, version 1.4, 4 September 2026, FAQ 4.4.2
  • European Commission, guidance C(2026) 5252, 27 July 2026: announcement
  • Directive (EU) 2022/2555 (NIS2), Article 21(2)(d) and 21(3): EUR-Lex

This article reflects the Eurtifact platform team's reading of the Cyber Resilience Act, checked against the sources above on 26 September 2026. Article, annex and recital references link to the on-site CRA explorer. It is not legal advice.