SBOM: the parts list the Cyber Resilience Act asks for
Updated 1 November 2026 · This guide explains the law in plain words. It is not legal advice.
An SBOM, or software bill of materials, is a list of the components inside your software, with their versions and where they came from, written in a format a computer can read. The Cyber Resilience Act (CRA) requires you to draw one up for every product, in a commonly used machine-readable format, covering at least the top-level dependencies (Annex I, Part II, (1)). CycloneDX and SPDX are the two formats most teams use.
What the law actually says
The CRA defines an SBOM as a formal record containing details and supply chain relationships of components included in the software elements of a product (Article 3(39)).
The duty sits in the vulnerability handling part of Annex I. You must identify and document the vulnerabilities and components in your product, "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" (Annex I, Part II, (1)).
Three things follow from that wording:
- Machine-readable. A spreadsheet export or a PDF table won't do. Tools must be able to read it.
- Commonly used. A format you invented yourself won't do either.
- Top-level dependencies at least. The parts you pull in directly. Going deeper is allowed and usually wise, since a flaw in a part of a part is still your flaw.
Who sees it
The SBOM goes into your technical documentation as part of your vulnerability handling processes (Annex VII, point 2(b)). A market surveillance authority can ask you for it, with a reasoned request, when it needs it to check your product (Annex VII, point 8).
You don't have to publish it. If you choose to share it with users, your user information must say where to find it (Annex II, point 9).
What a typical entry looks like
The CRA doesn't list the fields. Here's what one component usually carries in practice, using a fictional sensor hub firmware as the example:
| Field | Example |
|---|---|
| Name | openssl |
| Version | 3.0.13 |
| Supplier | OpenSSL Project |
| Identifier | pkg:generic/openssl@3.0.13 |
| Licence | Apache-2.0 |
| Hash of the file | a SHA-256 value |
| Relationship | used by the web admin service |
The identifier line is a package URL, a standard way of naming a component so tools can match it against vulnerability databases. Without a clear name and an exact version, nobody can tell whether a CVE affects you.
CycloneDX or SPDX
Both are open standards and both are machine-readable, so either should meet the "commonly used" test.
| CycloneDX | SPDX | |
|---|---|---|
| Started by | OWASP, the open web security community | The Linux Foundation |
| Grew out of | Security and vulnerability tracking | Licence compliance |
| Common files | JSON, XML | JSON, tag-value, RDF |
| Good at | Linking components to vulnerabilities and services | Licence detail and file-level records |
If a customer or auditor asks for one, give them that one. If nobody has asked, pick either and stick with it across releases so you can compare versions.
Is there an official format
Not yet. The Commission has the power to set the format and elements of the SBOM by implementing act (Article 13(24)), and when we checked on 31 October 2026 it hadn't used it. ENISA published a technical advisory on SBOMs, version 1.10, in October 2026. It's guidance, not law, but it's the closest thing to an official view so far. You can read it on ENISA's website.
Making an SBOM for firmware
For a web app you can generate an SBOM from the lock file at build time. Firmware is harder. Device makers often ship a Linux image built by a chip vendor's SDK, a BusyBox from years ago, and a closed binary blob nobody on the team has the source for.
So there are two ways in:
- From the build. Tools in Yocto or Buildroot can write an SBOM as they build. It's accurate for what the build system knows about, and blind to anything copied in by hand.
- From the finished file. Unpack the firmware image and identify components from what's inside: package databases, version strings, library names. It catches the hand-copied parts, but some components show no version at all.
Many teams use both and compare. Whichever you use, write down the limits: which parts had no version, and which you couldn't identify.
Keeping it current
An SBOM describes one version of one product. Each new firmware release needs its own, and you keep identifying vulnerabilities in it for the whole support period (Annex I, Part II, (1), with Article 13(8)). A list made once and never updated tells you nothing in 2029.
What Proofsheet does here
Upload one firmware image, Android app, or Windows, Linux or Apple program. The app unpacks it (gzip, tar, zip, cpio and MBR partitions), lists the parts and versions it can see, and generates the parts list as CycloneDX 1.5 and SPDX 2.3 files, in minutes. It matches exact versions against the NVD; family matches are labelled as such, and parts without a version are listed as unversioned rather than guessed. Encrypted firmware can't be opened: the report says so and you aren't charged.
No human reviews your file, and it is deleted within 24 hours. The SBOM is technical evidence, not a legal certificate, and it covers what the file shows. Parts your build adds elsewhere won't appear.
Generate a report to get your first parts list. Then see what goes around it in the technical documentation guide, or how it helps with reporting.