SBOM evidence for the EU Cyber Resilience Act

The Cyber Resilience Act is Regulation (EU) 2024/2847, on horizontal cybersecurity requirements for products with digital elements. It sets cybersecurity rules for the design, development and lifecycle of hardware and software placed on the EU market, and is enforced through CE marking and conformity assessment. See the European Commission overview.

A "product with digital elements" covers software and hardware that connects to a device or network, which is why it squarely affects embedded and IoT vendors. Obligations fall mainly on manufacturers, with related duties for importers and distributors.

The SBOM obligation sits in the vulnerability-handling requirements of Annex I. The text requires manufacturers to:

Three things follow directly from that wording:

• Top-level dependencies are the floor, not the ceiling.The regulation says "at the very least" the top-level dependencies. Deeper, transitive components are where most known vulnerabilities actually live, so a fuller SBOM is better evidence even though it is not the legal minimum.
• Machine-readable. A PDF or a spreadsheet is not enough; the SBOM has to be in a format tools can parse.
• Not public. The CRA does not require you to publish the SBOM. It belongs in the technical documentation and is provided to market surveillance authorities on request.

The SBOM is one item in a list of vulnerability-handling requirements that run for the whole support period. Under Annex I, Part II, manufacturers must, among other duties:

• Identify and document components and vulnerabilities (the SBOM point above).
• Address and remediate vulnerabilities without delay, including by providing security updates.
• Apply effective and regular security tests and reviews.
• Once a security update is available, share and publicly disclose information about fixed vulnerabilities.
• Put in place a coordinated vulnerability disclosure policy and a contact address for reporting.
• Distribute security updates securely, and where feasible without delay and free of charge, with advisory messages.

Source: Regulation (EU) 2024/2847, Annex I, Part II. The SBOM exists to make these duties possible: you cannot patch or report on a component you have not inventoried.

Separately from the essential requirements, Article 14 sets mandatory reporting for actively exploited vulnerabilities and severe incidents, through the ENISA Single Reporting Platform:

To know whether a vulnerability is actively exploited, you need an authoritative exploitation catalog. SBOM Total cross-checks every component against both the US CISA Known Exploited Vulnerabilities catalog and the ENISA European Union Vulnerability Database (EUVD), the EU source aligned with the CRA regime, and carries the European EUVD identifier next to the CVE where one is assigned. When a project is affected by an exploited vulnerability, SBOM Total can pre-fill an Article 14 early-warning draft from the scan data; the legal submission stays the manufacturer's responsibility.

These obligations apply from 11 September 2026. Source: European Commission: CRA reporting, Regulation (EU) 2024/2847, Article 14.

The CRA does not enumerate SBOM fields, so the working baselines come from national guidance. The NTIA Minimum Elements (2021) defined seven data fields that every SBOM should carry. These are the fields SBOM Total scores for quality and NTIA conformance.

In July 2026, CISA and international partners published the 2026 Minimum Elements for an SBOM, which updates and replaces the NTIA 2021 baseline. It adds four new elements, a component hash, a component license, the SBOM tool name and the SBOM generation context, and renames three: Supplier Name becomes Component Producer, Author of SBOM Data becomes SBOM Author, and Version becomes Component Version. SBOM Total scores every build against this 2026 baseline as well, so both the NTIA and the CISA 2026 view appear side by side in the report. For the full field-by-field comparison, see the NTIA 2021 vs CISA 2026 minimum elements guide.

Germany's BSI covers the same ground for the CRA in Technical Guideline TR-03183-2, which sets per-component requirements (name, version, supplier, dependencies, license and checksum) and maps them onto CycloneDX and SPDX. SBOM Total runs a TR-03183 completeness check alongside the NTIA and CISA 2026 checks, so an SBOM headed for the European market is measured against the European reference too.

Because the CRA only says "commonly used and machine-readable," the two formats that satisfy it in practice are CycloneDX and SPDX. Both encode the NTIA fields and the dependency graph. For why the dependency graph matters to security, the OWASP Dependency Graph SBOM cheat sheet is a good reference: it lets you show why a vulnerable transitive component is present.

SBOM Total does not certify anything. What it does is run every upload through 17 independent analyses and turn the SBOM into the verifiable facts the obligations above call for:

The SBOM and these reports are inputs to several CRA obligations. They do not by themselves make a product compliant: conformity is a broader assessment. This tool documents facts and prioritizes risk, and makes no certification claims.

• Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
• European Commission: Cyber Resilience Act
• European Commission: CRA reporting obligations
• NTIA: The Minimum Elements For a Software Bill of Materials (2021)
• CISA: 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• BSI: Technical Guideline TR-03183-2, Software Bill of Materials (SBOM)
• ENISA: European Union Vulnerability Database (EUVD)
• endoflife.date: component end-of-life catalog
• CycloneDX · SPDX
• OWASP Dependency Graph SBOM cheat sheet