Part of our Cyber Resilience Act guide. Reviewed on 17 October 2026.
What an SBOM records
A software bill of materials (SBOM) is a formal, machine-readable record of the software components in a product and how they relate to each other: names, versions, suppliers and dependencies. For a hardware team, an SBOM is useful once you tie it to the exact firmware build and hardware revision it describes. Kept as a controlled document, it shows what shipped and what a new vulnerability affects.
What the Cyber Resilience Act says about SBOMs
The EU Cyber Resilience Act, Regulation (EU) 2024/2847, makes the SBOM part of the manufacturer's vulnerability handling obligations. The relevant points:
- Definition. An SBOM is "a formal record containing details and supply chain relationships of components" in the software elements of a product (Article 3(39)).
- Requirement. Manufacturers must identify and document components, including by drawing up an SBOM "in a commonly used and machine-readable format" covering at least the top-level dependencies (Annex I, Part II, point 1).
- Technical documentation. The SBOM belongs to the vulnerability handling information in the technical documentation (Annex VII, point 2(b)), and must be provided to a market surveillance authority on a reasoned request (Annex VII, point 8).
- Publication is optional. Manufacturers are not obliged to make the SBOM public (recital 77). If you do share it with users, the user information must say where it can be accessed (Annex II, point 9).
- Format may be specified later. The Commission may set the format and elements of the SBOM through implementing acts (Article 13(24)).
In practice, you must be able to produce the SBOM for a specific product years after it shipped; the retention rules are under "Managing SBOMs as controlled documents" below.
Minimum elements
The CRA itself does not list SBOM data fields; the Commission may specify them later (Article 13(24)). A widely referenced baseline is the US NTIA report The Minimum Elements for a Software Bill of Materials (2021), which defines seven data fields for each component:
| Data field | What it records |
|---|---|
| Supplier name | Who creates, defines and identifies the component |
| Component name | The name the original supplier gives it |
| Version | The supplier's identifier for this version |
| Other unique identifiers | Look-up keys such as CPE, SWID tags or Package URL (PURL) |
| Dependency relationship | That component X is included in software Y |
| Author of SBOM data | Who created the SBOM entry |
| Timestamp | When the SBOM data was assembled |
In Germany, the BSI's technical guideline TR-03183-2, written with the CRA in mind, goes further. Version 2.1.0 requires JSON or XML in CycloneDX 1.6 or later, or SPDX 3.0.1 or later, and states that a separate SBOM must be generated for each software version. TR-03183-2 is a national guideline, not part of the CRA, and a useful reference while EU-level specifications are pending.
SPDX and CycloneDX
Most SBOM guidance, including BSI TR-03183-2, points to two open, machine-readable and formally standardised formats.
| SPDX | CycloneDX | |
|---|---|---|
| Maintained by | Linux Foundation | OWASP |
| Formal standard | ISO/IEC 5962:2021 | Ecma International, ECMA-424 |
| Focus | Security, licence compliance and other supply chain data | Supply chain and cyber risk reduction |
| Beyond software | AI and data references | Also hardware BOMs (HBOM) and SaaS BOMs |
| Official site | spdx.dev | cyclonedx.org |
Choose the one your build tooling and your customers already use. Consistency counts for more: generate the SBOM from the build for every release.
Why an SBOM belongs to a specific revision
The same board revision ships with several firmware versions over its life, and one firmware version may run on more than one board revision. If your SBOM is not tied to both, you will struggle to use it during an incident.
Once someone publishes a vulnerability in a library, you need to know which firmware versions contain it, which hardware revisions run those versions, and which shipped units are affected. To answer, you need:
- one SBOM per released firmware or software version, as BSI TR-03183-2 requires
- a link from that SBOM to the firmware item and to each hardware revision it is released for
- product identification on the unit, which the CRA already requires as a type, batch or serial number (Article 13(15))
- the software versions affecting compliance recorded in the technical documentation (Annex VII, point 1(b))
Without those links, an SBOM tells you "what is in this build" and leaves "which customers have this build" open.
The gap between the engineering BOM and the SBOM
Your team probably maintains an engineering BOM already. It rarely connects to the SBOM.
| Engineering BOM | SBOM | |
|---|---|---|
| Describes | Parts, assemblies, materials | Software components and dependencies |
| Owned by | Mechanical and electrical engineering | Firmware and software teams |
| Lives in | PDM, PLM or spreadsheets | Build pipeline, repository or SBOM tool |
| Changes | Through change orders | With every build |
| Identifiers | Part numbers and revisions | Package names, versions, PURLs |
To bridge the two, treat each released firmware image as an item in the engineering BOM, with its own part number and revision, and attach the SBOM to that item. The hardware structure then shows its firmware, and the firmware item carries its SBOM. Release the firmware item through the same change process as hardware.
Firmware in the product structure. 1: SW Image is an item with its own number and revision, and the SBOM attaches to it.
Managing SBOMs as controlled documents
An SBOM used as compliance evidence needs the same control as a drawing or test report:
- Versioning. Keep every SBOM. Each firmware release gets a new SBOM alongside the old ones.
- Approval. Review and approve the SBOM as part of the firmware release, with a named approver and date.
- Linking to revisions. Link each SBOM to its firmware item and to the hardware revisions it ships on.
- Change traceability. Record why a component changed, through the change request that introduced it.
- Retention. Keep SBOMs with the technical documentation for at least 10 years after placing on the market, or the support period if longer (Article 13(13)).
- Controlled sharing. Give customers and authorities the SBOM for their revision, and nothing else. Recital 77 leaves publication to you, so you decide who gets access.
What neo does, and what it does not
neo manages SBOMs as controlled documents. You can store SBOM files, SPDX or CycloneDX, version them, route them through approval, and link them to the firmware and hardware revisions they describe. Change requests record why they changed, audit logs record who did what, and supplier and customer portals let you share one SBOM with the people who need it.
neo does not generate SBOMs and does not scan for vulnerabilities. Generate SBOMs in your build pipeline and monitor vulnerabilities with dedicated SBOM or software composition analysis tooling. Those tools produce and analyse the SBOM; neo keeps it approved, versioned and tied to the right product revision. For the rest of the CRA documents, see the CRA engineering checklist, or talk to us about your setup.