CRA SBOM requirements
Format, scope, and per-version rules for a product Software Bill of Materials that satisfies the EU Cyber Resilience Act.
The CRA requires manufacturers to produce and maintain a Software Bill of Materials (SBOM) for the product you place on the market, as part of technical documentation. The rules are specific about format, scope, and how the SBOM must stay current.
The six SBOM rules under the CRA
Machine-readable, standard format
The SBOM must use a commonly used, machine-readable format: SPDX, CycloneDX, or SWID, typically serialized as JSON or XML.
At least top-level dependencies
As a minimum, list each top-level component with its name, version, and supplier; ideally include dependency relationships.
One SBOM per software version
A separate SBOM must be generated for each software version. If a component changes, a new version, and a new SBOM, is required.
Kept current, not stale
As the product receives updates and patches, the SBOM must track the current state of the software.
In the technical documentation
You do not have to publish the SBOM, but you must keep it in the technical documentation and provide it to market-surveillance authorities on request.
No vulnerability data inside
SBOMs must not contain vulnerability information. Communicate vulnerabilities separately using VEX or CSAF.
Product SBOM first: vendor and firmware-derived
Start with the vendor CycloneDX/SPDX document for each release. When you have the binary, generate a derived inventory on demand and compare, trust but verify. Continuous rescan keeps findings current across the support period.
Toolchain and build-environment SBOMs are useful depth for technical docs and long-support rebuilds. They are not the September 2026 lead. Read the build-environment spoke →
CRA compliance hub
CRA overview for embedded & firmware
What the Cyber Resilience Act requires, the deadlines, and how manufacturers of products with digital elements comply.
CRA for embedded & firmware
Why firmware needs vendor SBOM plus binary-derived inventory, and how HEX/encrypted images differ.
CRA compliance checklist
A practical checklist mapping each CRA obligation to what your team must do.
Vulnerability handling & Article 14
24h / 72h / 14-day reporting, KEV/EUVD, awareness clock, and what Sep 2026 actually requires.
Build-environment SBOM
Toolchain and build-time dependencies for technical docs: useful depth, but not what Sep 2026 reporting requires.
This page provides general information about the EU Cyber Resilience Act and is not legal advice. The regulation and its harmonised standards are still evolving: consult the official EU, ENISA, and BSI sources and qualified counsel for your specific product. alloy-it helps with product inventory, SBOM monitoring, triage, Article 14 evidence, and the rebuild path; it is not CE-marking software, not a notified body, and does not submit reports to ENISA or national CSIRTs.
Stand up a living product SBOM
Per-version vendor and firmware-derived inventories, continuous scan, and triage, start free.