SBOM: what the CRA actually requires and how to prepare

What the CRA actually requires

The SBOM (Software Bill of Materials) appears in Regulation (EU) 2024/2847 in two distinct locations, corresponding to two different regulatory logics.

The first is in Annex VII, which describes the content of the technical documentation. Point 3f requires that the technical file contain, for each product, "a list of software dependencies, including third-party software components": the functional definition of an SBOM. This requirement becomes enforceable from 11 December 2027 for products newly placed on the market.

The second is in the market surveillance context. Article 13(14) specifies that the manufacturer must be able to make the SBOM available on request from market surveillance authorities. The SBOM is not a mandatory public document. It is communicated to authorities on request, not published online. This distinction has implications for protecting commercially sensitive information on components used.

The regulation does not prescribe a specific format for the SBOM: this detail is delegated to implementing or delegated acts not yet published at the time of writing. In practice, two formats have established themselves as recognised de facto standards, supported by the EUVD (European Vulnerability Database) and leading cybersecurity authorities: CycloneDX and SPDX.

The CRA also introduces a notable departure from other CE directives on the question of components. The general rule under classic directives is that only the finished product is evaluated. A component's conformity has no direct legal effect on the host product's conformity. Under the CRA, the conformity of a certified module (for example a modem or radio module with its own CRA conformity assessment) can contribute positively to the host product's conformity, provided the module is used in accordance with its documentation. The SBOM is the instrument that makes this traceability chain visible and auditable: it establishes which components are integrated into the product, in which version, and which ones carry their own conformity assessment. Without a structured SBOM, this traceability cannot be demonstrated during an inspection.

Why the SBOM is the prerequisite for Article 14

The regulatory value of the SBOM extends well beyond the documentation checkbox in the technical file. Without an up-to-date SBOM, the 24-hour deadline of Article 14 is, for most industrial organisations, simply unmanageable.

The reasoning is straightforward. When a vulnerability is published in the NVD, the EUVD or a CERT bulletin (say, a flaw in OpenSSL, in an RTOS component such as FreeRTOS, or in a Modbus communications library), the first question the manufacturer must resolve is: is this library in my products? And if so, in which version?

Without an SBOM, this answer requires manual analysis of firmware builds, product by product, version by version. For a manufacturer managing several product families across successive firmware generations, this exercise can take several days. This timeline is structurally incompatible with the 24-hour notification obligation.

With an up-to-date SBOM in a machine-readable format, the correlation is automatable. A short script (or a dedicated tool such as Dependency-Track (OWASP)) can compare the SBOM component list against EUVD vulnerability feeds and identify potentially affected products in minutes. This is not a convenience; it is the basic infrastructure that makes the regulatory deadline achievable.

CycloneDX or SPDX: which to choose?

The two formats have slightly different origins and use cases, but their functional coverage for CRA requirements is equivalent.

SPDX (Software Package Data Exchange) is an ISO standard (ISO/IEC 5962:2021), originally developed by the Linux Foundation with a strong focus on open-source licence traceability. Its structure is more rigid, which favours interoperability, but can make it less natural for proprietary components or embedded systems without a standard package manager.

CycloneDX is an OWASP standard, maintained by the application security community. It has a stronger orientation towards vulnerability analysis and correlation with databases like the NVD. Its schema natively supports pedigree and provenance information (for supply chain tracking), component hashes (for integrity verification), and standardised identifiers (CPE, PURL). These characteristics make it the reference format for automatic EUVD correlation.

For a manufacturer whose immediate priority is Article 14 compliance (the capacity for rapid correlation with CVE feeds), CycloneDX is the pragmatic choice. Its tooling ecosystem for embedded firmware generation is more developed (Yocto integrations, Buildroot plugin, Microsoft sbom-tool). SPDX is preferable where open-source licence compliance is a significant additional constraint, notably for manufacturers whose products incorporate GPL or LGPL components.

The two formats are interconvertible via tools such as cdx2spdx or CycloneDX CLI. The initial choice is not irreversible, but long-term consistency and maintainability argue for a single format.

The embedded firmware challenge

SBOM generation for web applications or native software based on package managers (npm, pip, Maven, NuGet) is a largely solved problem. The toolchain is mature: syft, cdxgen, CycloneDX CLI, Trivy: these tools parse a lock file or dependency manifest and produce an SBOM in seconds.

The situation for embedded firmware is structurally different, for several reasons:

• Absence of a standard package manager: most embedded firmware projects manage dependencies manually: libraries copied into the source tree, integrated archives, components supplied by the SoC or RTOS manufacturer. There is no package-lock.json or requirements.txt that a tool can read directly;
• BSP and HAL components: Board Support Packages and Hardware Abstraction Layers supplied by SoC manufacturers (STMicroelectronics, NXP, Microchip, etc.) frequently contain proprietary libraries and open-source components mixed together, for which a vendor-supplied SBOM is not always available;
• Components lacking standardised identifiers: libraries specific to embedded systems (radio protocol stacks, lightweight cryptographic libraries for microcontrollers) do not always have a defined CPE (Common Platform Enumeration) or PURL (Package URL), complicating automatic CVE correlation;
• Undocumented legacy: for firmware developed before SBOM practice was widespread, the component list must be reconstructed from source files, commit histories, and build archives, labour-intensive but unavoidable.

For Yocto or Buildroot projects (the most widely used embedded Linux build environments), SBOM generation extensions exist (Yocto meta-cve-check, CycloneDX Buildroot plugin). They produce an SBOM from the build dependency graph, including BSP component recipes. This is the least costly solution for well-structured embedded Linux projects.

For bare-metal or RTOS firmware projects without a structured build framework, the approach is necessarily more manual initially: inventory of included libraries (by analysis of the Makefile or build scripts), version identification from headers or vendor release notes, and manual entry into an SBOM management tool. The goal is not immediate perfection, but an initial SBOM sufficiently complete to cover the components most likely to be subject to CVEs: networking libraries, cryptographic components, and protocol parsers.

Minimum content and a viable SBOM for an industrial SME

Annex VII §3f of the CRA does not specify a precise level of detail: it requires "a list of software dependencies, including third-party software components." The prEN 40000-1-3 standard (§5.3.6, vulnerability handling) adds completeness requirements dependent on the product's risk level.

A viable SBOM for an industrial SME should cover, at minimum:

• Significant direct dependencies: third-party libraries included in the firmware or software, with their full name, exact version, supplier (or upstream project), and licence if available;
• Critical infrastructure components: cryptographic libraries, network stacks (TCP/IP, TLS, radio protocols), application protocol parsers, components whose vulnerability would have the greatest security impact on the product;
• A clear product identifier: internal product reference, firmware version, and if possible a product-level PURL or CPE to enable direct EUVD correlation;
• Component hashes (recommended in prEN 40000-1-3 §5.3.6 [PRE-7-RQ-07-RE] for higher-risk products): allows verification of the integrity of the component included in the build against the referenced upstream source.

What is not strictly required by the regulation but adds significant value: transitive dependencies (dependencies of dependencies), hardware supply chain supplier information, and the generation tool used (for analysis reproducibility).

Organisation size does not determine the actual complexity of the SBOM. An industrial embedded system with a 200 KB firmware may have fewer identifiable components than a lightweight web application. The actual complexity is determined by the number of integrated third-party libraries and the development team's existing documentation practices.

Integration with the EUVD

The EUVD (European Vulnerability Database), managed by ENISA, is the reference vulnerability database for the European market. It aggregates vulnerability data from recognised sources (NVD, national databases) and enriches it with information on measures applied by Member States and CSIRTs.

The EUVD's value for manufacturers lies in its role in the vulnerability monitoring process required by Article 14. A manufacturer must maintain an active monitoring process for vulnerabilities affecting its components: SBOM/EUVD correlation is the mechanism that automates this monitoring for CVEs documented in the database.

In practice, correlation works as follows:

1. The SBOM lists components with their identifiers (CPE or PURL);
2. The monitoring tool (Dependency-Track, Grype, or a script against the EUVD API) compares these identifiers against new database entries;
3. Any match triggers an internal alert with the CVSS severity level and exploitation status (known exploited, etc.);
4. If the vulnerability is flagged as "actively exploited," the Article 14 process is triggered.

This chain only works if the SBOM contains standardised identifiers. A component listed only by its internal name ("crypto_lib_v2.3") without reference to its upstream equivalent cannot be automatically correlated with CVEs.

For a small manufacturer without a dedicated security team, the minimum viable vulnerability management package under the CRA comprises four elements: active monitoring of the EUVD (correlated against the product SBOM), an up-to-date SBOM for each product in service, a formalised contact point for receiving vulnerability reports (the security@ address and CVD policy are the two faces of this requirement), and a documented procedure for notifying an actively exploited vulnerability to ANSSI and ENISA within the Article 14 timelines. A highly detailed remediation procedure is not necessarily expected at this stage. What matters is that the company can execute it and that it documents the effective distribution of security updates. It is on this package, not on the technical file alone, that inspections will focus from September 2026.

Timeline and prioritisation for manufacturers starting today

The deadline is clear: Article 14 applies from 11 September 2026. For a manufacturer beginning in late April 2026, approximately five months remain. A realistic sequence:

• Month 1 (May 2026): Inventory of products within the Article 14 perimeter (including generations no longer actively commercialised but still in service). Assessment of existing documentation. Is there a component list, even partial, for each firmware? Choice of SBOM format (CycloneDX recommended) and tools;
• Months 2–3 (June–July 2026): Generation of initial SBOMs: priority on currently commercialised products and high-risk components (network, cryptography, parsers). For Yocto/Buildroot projects, integration of the generation plugin into the pipeline. For bare-metal projects, manual inventory and entry into the management tool;
• Month 4 (August 2026): Setup of the CVE/EUVD monitoring process and correlation testing. Verification that CPE/PURL identifiers in SBOMs generate matches in correlation tools. Resolution of components lacking standardised identifiers;
• Before 11 September 2026: SBOM and monitoring process operational. CVD published. PSIRT designated. Reporting channel active.

This timeline is tight but achievable for a mid-sized manufacturer with dedicated resources. For an SME of fewer than fifty people without in-house product cybersecurity capability, external support on SBOM methodology and PSIRT process setup is a realistic assumption to budget for.

What the SBOM does not do

The SBOM is a component register, not a security assessment. Its presence does not mean that listed components are secure, or that the product complies with Annex I essential requirements. A complete SBOM may list components with known vulnerabilities. That is precisely the point: making them visible.

Equally, the SBOM does not replace the risk assessment required by prEN 40000-1-2 and Annex I. Risk assessment evaluates threats, attack vectors, and the likelihood and impact of exploitation in the specific use context of the product. A component with a critical CVE in the NVD may carry reduced severity in a specific operational context: for instance, a networking interface vulnerability that is not exposed in the product's nominal configuration. It is the risk assessment, not the SBOM alone, that enables this contextual evaluation.

The SBOM is the ingredients list. The risk assessment is the toxicological evaluation. Both are necessary. Neither substitutes the other.