SBOM: producing and maintaining it for the Cyber Resilience Act

The Cyber Resilience Act requires manufacturers of products with digital elements to identify and document the software components they ship. The reference tool is the SBOM (Software Bill of Materials), the inventory of a software’s components.

What an SBOM is for

When a vulnerability is published in an open-source library, the first question is: “which products, and which versions, ship it?”. Without an SBOM, the answer takes days. With an up-to-date SBOM for every shipped version, it takes minutes. It is also what makes the CRA reporting deadlines workable (early warning within 24 hours, notification within 72 hours), in force since 11 September 2026.

Two standard formats

• SPDX, backed by the Linux Foundation and standardised as ISO/IEC 5962.
• CycloneDX, backed by OWASP, widely used in DevSecOps pipelines.

Both work; what matters is choosing one and producing it systematically.

Good practices

• Generate the SBOM in the build pipeline, for every release, not by hand.
• Cover all embedded software: OS (embedded Linux, RTOS), libraries, third-party firmware, not just the application.
• Archive the SBOM of every shipped version for the whole support period.
• Match it automatically against vulnerability databases to get alerted.
• Document exploitability: a present vulnerability is not always exploitable in your product; the VEX format lets you state it.

An SBOM is not enough

It fits within a whole: risk analysis, secure boot, over-the-air updates, vulnerability handling and reporting. Our CRA compliance support starts with a gap analysis on one representative product.

Information current as of 29 September 2026. Regulations and timelines change: this article is not legal advice.