The role of regulation in driving global adoption for software bill of materials (SBOM) may have started with U.S. Executive Order 14028, but make no mistake; this is not a U.S.-only initiative. We have seen regulations from the Payment Card Industry (PCI DSS 4.0), signals from the Australian government, and other global initiatives along with U.S. requirements (like the aforementioned Executive Order along with guidelines from the Food and Drug Administration).
The Cyber Resilience Act (CRA) — Regulation (EU) 2024/2847, which sets horizontal cybersecurity requirements for products with digital elements sold in the European Union, is the most significant of these. It includes a clear SBOM requirement.
The CRA applies to manufacturers of products with digital elements placed on the EU market, as well as importers and distributors (and any entity that markets a product under its own brand). Manufacturers must draw up an SBOM covering at least the product's top-level dependencies, keep it in the product's technical documentation, and provide it to market surveillance authorities on request. SBOMs do not need to be made public.
The regulation is now in force, and its first operational obligations for vulnerability and incident reporting became binding on 11 September 2026. The SBOM requirement, along with the rest of the regulation's essential requirements and conformity assessment obligations, applies from 11 December 2027.
Some of the details of the CRA’s SBOM requirements are still being worked out through a standards drafting process. But, at this stage, we know that SBOMs will not need to be publicly shared nor include all dependencies.
Editor's Note: This post has been updated several times since its initial publication. The most recent update was on 18 September, 2026.
CRA Background
The Cyber Resilience Act is a regulation aimed at bolstering cybersecurity across the EU. It sets cybersecurity requirements for hardware and software products with digital elements and requires manufacturers to address security throughout the product lifecycle.
The CRA applies to laptops, smartphones, consumer IoT devices, peripherals, graphics cards, firmware, operating systems, and software of nearly every kind. It also covers the "remote data processing solutions" that a product depends on to perform its functions, so a cloud back-end that a device can't work without is in scope even though it's a service.
There are, however, a few notable exclusions:
- Products already regulated for cybersecurity under sector-specific EU law: medical devices and in vitro diagnostics, motor vehicles covered by type-approval rules, civil aviation, and marine equipment.
- Products developed exclusively for national security or defence purposes are also out of scope.
- Pure services, including standalone software-as-a-service that isn't a remote data processing solution for a product. These fall under the NIS 2 Directive (Directive (EU) 2022/2555) instead. NIS 2 does not explicitly require SBOMs, but it does call for "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers."
- Free and open source software that is not supplied in the course of a commercial activity. However, it's important to note that this exclusion is narrower than "open source is exempt." Open source that is monetised, or that a manufacturer integrates into a commercial product, is fully in scope for that manufacturer. The CRA also creates a lighter-touch regime for "open-source software stewards" (foundations and similar organisations that support open source projects without commercialising them).
Notably, although although all types of products that are in scope for the CRA must meet the requirements (including the SBOM obligation), there are different conformance paths depending on product classification. (You can see more details on product classification on our blog.)
Breaking Down the CRA’s SBOM-Related Provisions
The SBOM requirement itself is short. Annex I, Part II (vulnerability handling requirements), point (1) requires manufacturers to:
"... identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products".
Recital 77 makes clear that vulnerability management is the primary use case:
"In order to facilitate vulnerability analysis, manufacturers should identify and document components contained in the products with digital elements, including by drawing up an SBOM. An SBOM can provide those who manufacture, purchase, and operate software with information that enhances their understanding of the supply chain, which has multiple benefits, in particular it helps manufacturers and users to track known newly emerged vulnerabilities and cybersecurity risks. It is of particular importance that manufacturers ensure that their products with digital elements do not contain vulnerable components developed by third parties."
CRA SBOM Formats and Data Fields
At the time of writing, the specific requirements for SBOM formats and elements remain unclear. Until it does, the binding requirement remains what's in Annex I: a commonly used, machine-readable format, covering at least top-level dependencies.
We can fairly interpret the CRA's text that refers to a "commonly used and machine-readable" as either CycloneDX (now standardised as ECMA-424) or SPDX (standardised as ISO/IEC 5962:2021 at version 2.2.1, with 2.3 and 3.0 released since).
Two tracks will fill in the detail the regulation leaves open (such as which specific SBOM data fields must be included in the document shared with surveillance authorities).
-
Harmonised European standards. CEN/CENELEC is developing harmonised standards covering the CRA's essential requirements, including Annex I Part II vulnerability handling. Applying a harmonised standard gives a manufacturer a presumption of conformity. As of September 2026, no harmonised standard has yet been cited in the Official Journal, and the Commission proposed in July 2026 to push delivery of the horizontal (Type A and B) standards to the end of October 2026 and the product-specific (Type C) standards to the end of December 2026.
-
The Commission can specify SBOM format and elements under Article 13(24). None has been adopted yet.
In the meantime, the most concrete public reference for what a CRA-grade SBOM should contain is Germany's BSI Technical Guideline TR-03183-2, Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials (SBOM).
BSI published the first version of TR-03183-2 in August 2023, while the CRA was still moving through the legislative process. The guideline has been revised several times since; the current version is 2.1.0, released in August 2025.
While the document is non-binding German national guidance, not EU laws, it's the most detailed SBOM specification issued by any EU member state authority, and it's widely expected to influence the harmonised standards and any Commission implementing act.
Highlights from v2.1.0 include:
- Formats: SBOMs must be CycloneDX (v1.6 or higher) or SPDX (v3.0.1 or higher). Version 2.1.0 added field-by-field mappings for both formats.
- Dependency depth: Recursive dependency resolution must be performed at least until the first component outside the scope of delivery on each path, substantially deeper than the CRA's top-level floor.
- Licences and hashes are mandatory, using SPDX licence identifiers/expressions and a cryptographic checksum of each component's deployable form.
- Vulnerability data stays out of the SBOM. BSI rejects embedding vulnerability information in the SBOM because it changes far faster than component data, and instead points to standalone VEX or CSAF documents.
- One SBOM per software version, regenerated only to correct errors or add newly available component information.
What's Next for the CRA's SBOM Requirement
As mentioned, we expect technical details of the SBOM requirement's implementation to be made available in the coming months. However, we have enough information at this point to feel confident recommending that organisations prioritise building a system that enables reliable (and ideally automated) SBOM generation for all products within the CRA scope. The system should also be comprehensive enough to surface the sorts of data fields proposed by the BSI.
FOSSA has extensive experience helping organizations navigate SBOM-related regulatory requirements, and our SBOM management solutions make compliance easier at multiple stages. You can import SBOMs from third-party suppliers, generate application-level SBOMs, analyze and act on vulnerabilities surfaced in your SBOMs, and securely share SBOMs with market surveillance authorities.
For more information on FOSSA SBOM management, reach out to our team.
Editor's note: FOSSA's Andy Drukarev contributed to this article.