The Cyber Resilience Act (Regulation (EU) 2024/2847) makes a software bill of materials (SBOM) a mandatory part of the technical documentation for every "product with digital elements" placed on the EU market from 11 December 2027. If you manufacture software or hardware with embedded software — from SaaS-connected devices to embedded firmware — the SBOM is how you prove you know what is inside your product. This guide covers what the obligation actually demands: scope, content, format, depth, and who sees the result.
What the CRA Actually Requires
The obligation lives in Annex I Part II of the regulation: manufacturers must "identify and document components of the product with digital elements" — including, where relevant, drawing up an SBOM covering at least the top-level dependencies of the product. The inventory feeds three duties:
- Vulnerability handling: you cannot triage whether a published CVE affects your product without knowing which components and versions you ship. Annex I Part I requires an effective mechanism to identify and remediate vulnerabilities — the SBOM is the lookup table.
- Incident reporting: the 24/72-hour ENISA reporting duties (live since September 2026) assume you can say which component is exploited.
- Market surveillance: authorities can request the component inventory as part of technical documentation — it is shared on request, not published.
What Must the SBOM Contain?
The CRA sets the floor at direct (top-level) dependencies — every third-party library, framework, or component your product ships, with its version. In practice, a usable SBOM records per component:
- Name and version — the resolved version, not the semver range from your manifest.
- Identifier — a
purl(package URL) or CPE so scanners can match components to CVE databases. - Supplier/publisher — who produces the component.
- License — needed for the separate license-compliance story auditors also check.
- Dependency relationship — direct vs transitive, and where in the product it is used.
Direct dependencies are the legal minimum — but remember the exploitable vulnerability is usually transitive: your product does not import log4j, your logging framework does. A manifest-level SBOM (package.json → components) is the compliance floor; a lock-file or build-level SBOM is the security-relevant artifact. Generate both if you can.
Format: CycloneDX or SPDX
The CRA requires the inventory to be machine-readable but does not mandate one serialization. Two formats dominate:
- CycloneDX — OWASP's JSON/XML format, built for security workflows: components, services, hashes, license IDs, and VEX extension for communicating "affected / not affected" statements. Default choice for vulnerability-management pipelines.
- SPDX — the Linux Foundation format, ISO-standardized (ISO/IEC 5962), stronger on license and provenance metadata; the tag-value variant diffs well in version control.
Either satisfies the CRA. Pick the one your customers and tooling already consume — generate a first draft with our free SBOM generator, which emits both from a package manifest.
Who Must Produce It — and for What
- Manufacturers — the entity placing the product on the market under its name. If you ship a smart device with a companion app and backend, the SBOM covers the product boundary: firmware, app, and the cloud components integral to product function.
- Importers and distributors — must verify the manufacturer has done the work; they don't generate SBOMs but they inherit consequences of a missing one.
- Open-source stewards — foundations get a lighter regime (cybersecurity policy, cooperation with authorities); purely non-commercial OSS development is exempt.
- Pure SaaS — out of scope (NIS2 territory), unless the service is an integral part of a product's functionality.
Is the SBOM Public?
No — and this is the most common misconception. The SBOM sits in your technical documentation, provided to market-surveillance authorities on request and shareable with customers under your own terms. What is public is the CE marking and the declaration of conformity. Several manufacturers nonetheless publish SBOMs voluntarily as a security-transparency signal — that is a choice, not an obligation.
A Pragmatic Path to December 2027
- Now: generate a manifest-level SBOM per product (our SBOM generator does this in-browser — nothing uploaded). Add SBOM generation to CI so it cannot drift.
- Next: wire the SBOM into vulnerability triage — feed it to a scanner (Grype, OSV-Scanner, Dependency-Track) so new CVEs map to shipped components automatically.
- Before the deadline: fold the SBOM into the technical file alongside the risk assessment, secure-development evidence, and update policy the conformity assessment requires.
For the full CRA picture — scope, CE marking, support periods, and the reporting duties already in force — see our Cyber Resilience Act guide.
Frequently Asked Questions
Does the CRA require transitive dependencies in the SBOM?
The legal floor is top-level dependencies. But Annex I's vulnerability-handling duties are transitive in effect — you need to know whether a CVE in a nested dependency affects you. Generate the deepest inventory your tooling allows; lock-file-level SBOMs cover transitives for free.
Which SBOM format does the CRA mandate?
None specifically — the requirement is a machine-readable component inventory. CycloneDX and SPDX are the two formats everyone produces and consumes; CycloneDX is the usual pick for security-driven use, SPDX for license-driven supply chains.
Does the SBOM duty apply to open-source components only, or proprietary too?
All components — OSS libraries, commercial SDKs, firmware blobs, embedded OS images. The inventory is about everything inside the product boundary, not just the open-source parts.
When does the SBOM obligation start?
With the main body of obligations: 11 December 2027, for products placed on the market from that date. The vulnerability and incident-reporting duties (which the SBOM supports) already apply since September 2026.
Can I generate an SBOM without installing CLI tooling?
Yes — for a manifest-level inventory, paste package.json, package-lock.json, requirements.txt, or go.mod into our SBOM generator and download CycloneDX or SPDX. For build-level SBOMs with file hashes, CLI tools like syft or cdxgen remain the standard.
