Regulations •

SBOM (software bill of materials) — what the Cyber Resilience Act requires

The Cyber Resilience Act makes a machine-readable SBOM an essential requirement from 11 December 2027. Formats, mandatory data fields, retention periods and how to build SBOM generation into a release process.

Author: myDPP Team

SBOM (software bill of materials) — what the Cyber Resilience Act requires

A software bill of materials is a boring artefact with an outsized consequence. It is a list: which components a product’s software is built from, in which versions, from which suppliers, under which licences. Until recently it was an internal engineering convenience. With Regulation (EU) 2024/2847 — the Cyber Resilience Act — it becomes an essential requirement, and one that market surveillance authorities can ask to see.

The reason is straightforward. When a vulnerability is published in a widely used library, the only question that matters is: are we affected? Without a bill of materials that question takes weeks of manual archaeology across repositories and build servers. With one it takes a query. The CRA turns that operational reality into a legal duty — and, like most product-data duties, it is far less about writing a document once than about keeping data true across every release for a decade. That is the same discipline the digital product passport demands elsewhere in EU product law.

Key takeaways

  • The SBOM obligation sits in Annex I Part II of the CRA, among the vulnerability-handling requirements. It applies in full from 11 December 2027.
  • The legal floor is modest: a commonly used, machine-readable format, covering at least the top-level dependencies, kept up to date. The regulation names no specific format.
  • In practice that means CycloneDX (OWASP, standardised as ECMA-424) or SPDX (Linux Foundation, ISO/IEC 5962:2021). SWID tags (ISO/IEC 19770-2) are an asset-management identifier, not a full dependency inventory.
  • There is no obligation to publish the SBOM to customers. It must be made available to market surveillance authorities on request, and it forms part of the technical documentation under Annex VII.
  • Technical documentation must stay at the disposal of the authorities for at least ten years after the product is placed on the market, or for the support period if that is longer.
  • Germany’s BSI TR-03183-2 goes well beyond the CRA floor — it requires recursive resolution of the whole dependency tree, SHA-512 hashes and a defined field set. It is not binding law, but it is the most concrete published reference and buyers increasingly cite it.
  • An SBOM that is not bound to a specific product version is evidence of nothing. Versioning, not overwriting, is the whole game.
  • The CRA does not require an SBOM in a digital product passport. What it does require is version-level product data that survives a decade — the same problem, solved with the same tooling.

What an SBOM actually is

Strip away the acronym and an SBOM is an inventory with provenance. For each component that ends up in the shipped product it records at minimum what the component is called, which version it is, and who supplied it. Better bills of materials add the licence, a cryptographic hash so the component can be identified unambiguously, and the dependency relationships — which component pulled in which other one.

The distinction that matters most is depth. A top-level SBOM lists what your code declares directly: the twelve libraries in your manifest file. A transitive SBOM resolves what those twelve pull in, and what those pull in, down to the leaves. Real applications routinely turn twelve declared dependencies into several hundred actual ones. Vulnerabilities are as likely to sit four levels down as at the top — which is exactly why the difference between the CRA’s floor and what a useful SBOM contains is not academic.

The second distinction is when it is produced. An SBOM generated from source code describes what the developers intended. An SBOM generated from the build output describes what actually shipped, including components injected by the build system, the base container image or a vendor’s binary blob. The two diverge more often than teams expect, and only the second one is evidence.

What the CRA requires — and what it does not

Annex I Part II of Regulation (EU) 2024/2847 sets out the vulnerability-handling requirements a manufacturer must satisfy throughout the support period. The first of them is the bill of materials: manufacturers must identify and document the components contained in the product, 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, and keep it up to date.

Three things are worth reading carefully in that sentence.

“Commonly used, machine-readable format.” The regulation deliberately names no format. This is standard practice in EU product law: the legal text states the property, and harmonised standards fill in the technical detail. In practice the field has consolidated around two formats, and choosing either is defensible.

“At the very least the top-level dependencies.” This is a floor, not a target. The law does not oblige you to resolve the full transitive tree. It also does not stop an authority, a certification body or a corporate customer from asking for more — and it does not make a top-level-only SBOM useful for the purpose it exists to serve. Treat the floor as the compliance minimum and the transitive tree as the operational requirement.

“Keep it up to date.” The obligation is continuous and runs across the support period. A bill of materials produced once for the technical file and never regenerated diverges from reality at the first patch release.

What the CRA does not require is equally important:

  • No duty to publish. Making the SBOM public is a commercial decision. The legal duty is to make it available to market surveillance authorities on request. Some sectors and some large buyers will demand it contractually; that is a different pressure, not a legal one.
  • No prescribed format or profile. No CycloneDX-versus-SPDX mandate, no minimum field list in the regulation itself.
  • No SBOM in a product passport. The CRA creates no passport, no data carrier and no registry.

Formats: CycloneDX, SPDX and SWID

CycloneDXSPDXSWID tags
OriginOWASPLinux FoundationISO/IEC
StandardECMA-424ISO/IEC 5962:2021ISO/IEC 19770-2
Designed forApplication securityLicence compliance and provenanceSoftware asset management
Typical strengthVulnerability workflows, CI/CD, VEXFile- and snippet-level detail, procurementInstalled-software identification
Full dependency inventoryYesYesNot its purpose

CycloneDX came out of the application-security community and was built for security use cases from the start. Its practical advantage is the ecosystem around it: it extends to hardware, SaaS, machine-learning and cryptographic bills of materials, and it carries VEX — Vulnerability Exploitability eXchange — which lets you state that a known vulnerability in a listed component is not actually exploitable in your product. For a manufacturer facing CRA vulnerability-handling duties, being able to say “present but not exploitable, here is why” in a machine-readable form is worth a great deal of avoided work.

SPDX originated in licence compliance and carries that heritage as depth: it can describe software down to individual files and snippets, and it is the natural choice where procurement, legal review and formal documentation drive the requirement.

SWID tags appear in most format comparisons and in some official guidance, but they solve a different problem — identifying installed software on a machine. They are not a substitute for a dependency inventory.

The honest answer on choice: both leading formats are converging, tooling supports both, and converters exist. Pick the one your existing toolchain generates most reliably and standardise on it. Generating a broken SBOM in the “better” format is worse than generating a correct one in either.

The data fields — three reference points

The CRA gives you a floor. Three published documents tell you what a serious SBOM actually contains.

The German reference: BSI TR-03183-2

Germany’s federal information security office publishes Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials. It is not binding law, but it is the most concrete public specification written explicitly against the CRA, and it is increasingly cited in German supplier questionnaires. Version 2.1.0 was published in August 2025.

It requires JSON or XML serialisation in CycloneDX version 1.6 or higher, or SPDX version 3.0.1 or higher. Its fields fall into three categories: required (always), additional (mandatory whenever the underlying data exists) and optional.

Required at document level:

  • Creator of the SBOM — an email address or URL identifying the producer
  • Timestamp, in ISO 8601 format

Required for each component:

  • Component name
  • Component version
  • Component creator, meaning the supplier
  • Filename of the component
  • Dependencies on other components — resolved recursively
  • Distribution licences
  • Hash of the deployable component, SHA-512
  • Whether the component is executable, whether it is an archive, whether it is structured

Note the gap between this and the CRA text. Recursive resolution of the whole dependency tree is materially more work than top-level dependencies, and the SHA-512 requirement forces the SBOM to be generated from real build artefacts rather than from a manifest file. If you are selling into the German market, plan against this rather than against the regulation’s floor.

The US baseline: NTIA minimum elements

The 2021 NTIA Minimum Elements for a Software Bill of Materials defined seven baseline data fields that most tooling still targets: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. US federal guidance has since been revised — CISA ran a public consultation on an updated set of minimum elements that adds fields such as component hash, licence and generation context. If you already produce SBOMs for US federal customers, you are close to the CRA floor; you are not yet at the German reference.

The harmonised standards, still in progress

The Commission’s standardisation request for the CRA was accepted by CEN, CENELEC and ETSI on 3 April 2025, covering a programme of horizontal and vertical standards. The horizontal EN 40000 series is the relevant one here — in particular the vulnerability-handling standard, which is where SBOM practice will be pinned down. At the time of writing these standards are still in the drafting and approval pipeline, and the Commission has floated pushing the delivery deadlines back.

The practical consequence: do not wait for the harmonised standard. Its content is being drafted against the same Annex I text, and the operational work — instrumenting your build to emit an SBOM per release — does not change based on which field list wins. What waiting costs you is the year of release history you would otherwise already have.

Where SBOMs go wrong in practice

Generated by hand, once

The most common failure is a spreadsheet compiled for the technical file, exported to JSON and never touched again. It is accurate on the day it is written and wrong at the first dependency bump. The CRA duty is to keep the bill of materials up to date, so a stale SBOM is not a partial compliance — it is a documented failure of a continuous obligation.

Not bound to a version

An SBOM without an unambiguous statement of which product, which version and which build it describes is evidence of nothing. When an authority asks whether the units shipped in March 2028 contained a vulnerable library, you need the bill of materials for that build, not the current one. This is the single most common structural mistake, and it is a data-modelling problem rather than a security one.

Built from source, not from the artefact

Manifest files describe intent. The shipped artefact contains what the build produced: the base image, the statically linked library, the vendor SDK dropped in as a binary. SBOMs generated only from source consistently under-report, and the components they miss are disproportionately the ones nobody is patching.

Third-party and embedded components missing

If a supplier ships you a module, its components are in your product. The CRA does not care that you did not write them. Getting SBOMs from suppliers is a procurement problem with a long lead time — contracts have to be amended, and small suppliers often have no capability at all. This is the item to start earliest.

Nowhere to keep it

An SBOM per release, retained for ten years or the support period, across product families, is a versioned data set that has to survive tooling migrations, repository moves and the departure of whoever set it up. A build artefact in a CI system that gets replaced in three years is not a retention strategy.

Building SBOM generation into the release process — five steps

  1. Generate from the build, automatically. Add SBOM generation to the pipeline stage that produces the shippable artefact, so an SBOM cannot exist without a build and a build cannot exist without an SBOM. Manual generation always drifts.
  2. Bind the SBOM to an identity. Product, version, build identifier, timestamp. This is what turns a file into evidence, and it is the step teams most often skip.
  3. Fix the depth and the format, and write it down. Decide on CycloneDX or SPDX, decide whether you resolve transitively (you should), and record the decision so that six release cycles later nobody quietly changes it.
  4. Push the requirement up your supply chain. Amend supplier agreements to require an SBOM per delivered version, in your chosen format. Start with the suppliers of components you cannot inspect.
  5. Store it where it will still be readable in a decade. Versioned, indexed by product and release, retrievable without the original build system. Retention is the requirement that outlives every tool you use to satisfy it.

The wider data programme this sits inside is covered in our DPP implementation checklist.

What this means for product data

Be clear about the boundary: the CRA does not put an SBOM into a digital product passport. There is no passport obligation in the regulation, and no reading of it makes a bill of materials a public-facing field. Passport obligations come from ESPR and from sectoral acts that mandate them expressly.

What the two regimes share is a shape. Both demand data that is:

  • Attached to a version rather than to a product line. The SBOM changes with every release, exactly as passport data changes with every specification revision. Systems that overwrite the current record cannot answer a question about a unit sold three years ago.
  • Machine-readable by design. Not a PDF that happens to contain a table — a structured document another system can parse without a human in the loop.
  • Retained for a decade. Ten years of technical documentation under the CRA is the same infrastructure commitment as long-term passport availability under ESPR.
  • Consistent across channels. The end-of-support date, the vulnerability contact point and the update information have to say the same thing in your shop, at a distributor and in the documentation.

For electronics the argument compounds. The same product sits inside ESPR, the RoHS directive, WEEE and the CRA at once. A company keeping substance data in one system, repairability data in another and software component data in a third is maintaining four registers about one product. The starting point for consolidating them is our complete list of DPP data requirements, and the underlying argument for treating product data as infrastructure is in DPP and PIM.

An honest note on where a passport platform stops: myDPP does not generate SBOMs, does not scan code or containers, does not validate a bill of materials against a build, does not perform vulnerability analysis and does not assess CRA conformity. Those belong to your engineering toolchain and, where required, to a notified body. What a passport platform does is store versioned product data, keep it retrievable for years and publish the parts that are meant to be public. Responsibility for compliance stays with the manufacturer.

Timeline

DateWhat happens
10 December 2024Regulation (EU) 2024/2847 enters into force
3 April 2025CEN, CENELEC and ETSI accept the standardisation request
11 June 2026Notified body provisions apply
11 September 2026Reporting obligations apply — including for products already on the market
11 December 2027Full application — the SBOM requirement in Annex I becomes binding

The reporting duty arrives more than a year before the SBOM duty, and that ordering is instructive. From September 2026 you may have to report an actively exploited vulnerability within 24 hours. Answering “which of our products contain this component” inside that window is the problem an SBOM exists to solve — which makes the practical deadline for having one considerably earlier than the legal one.

Frequently asked questions

Do I have to publish my SBOM?

No. The CRA obliges you to draw one up, keep it current and make it available to market surveillance authorities on request. It becomes part of the technical documentation. Publishing it to customers is a commercial choice — and increasingly a contractual demand from large buyers, which is a separate matter from the legal duty.

Is a top-level dependency list enough?

It satisfies the letter of Annex I Part II. It does not satisfy Germany’s BSI TR-03183-2, which requires recursive resolution of the dependency tree, and it will not answer the question you actually need answered when a vulnerability lands in a component four levels down. Treat top-level as the floor and transitive as the target.

CycloneDX or SPDX?

Either is defensible under the CRA, which names no format. CycloneDX has the stronger security ecosystem and carries VEX; SPDX has more depth for licence and provenance work. BSI TR-03183-2 accepts CycloneDX 1.6+ or SPDX 3.0.1+. The decisive factor should be which your existing toolchain produces reliably.

How long do I have to keep SBOMs?

The SBOM is part of the technical documentation, which must be kept at the disposal of market surveillance authorities for at least ten years after the product is placed on the market, or for the duration of the support period if that is longer. Since a new SBOM is produced with every release, this is a versioned archive rather than a single file.

Does an SBOM belong in a digital product passport?

Not as a matter of law. The CRA creates no passport obligation, and no current passport act requires a bill of materials as a data field. The overlap is in the infrastructure: both need version-level, machine-readable product data retained for a decade and reachable through a stable identifier.

Sources

Back to Knowledge Base