The Software Bill of Materials (SBOM) is becoming a central requirement for global cybersecurity compliance frameworks, and the Cyber Resilience Act (CRA) is no exception. Under the CRA, manufacturers of products with digital elements must maintain a complete, accurate and regularly updated SBOM as part of their cybersecurity documentation. This guide provides the most comprehensive explanation to date of the CRA SBOM requirements, how they differ from U.S. SBOM initiatives, and what manufacturers must implement to achieve compliance before 2027.
For context, an SBOM is a structured inventory of all software components within a product, including dependencies, libraries, open-source packages, firmware modules and third-party code. SBOMs play a critical role in vulnerability management, supply-chain security and regulatory transparency. Similar initiatives have already been adopted by the U.S. Department of Commerce (NTIA), NIST (NIST), and CISA (CISA SBOM Program), meaning CRA SBOM obligations follow an international trend toward greater software transparency.
This guide explains everything you need to know to comply with SBOM obligations under the Cyber Resilience Act.
What Are SBOM Requirements Under the Cyber Resilience Act?
The CRA SBOM requirements aim to ensure transparency and traceability of every software component included in a digital product. The CRA explicitly requires manufacturers to maintain a comprehensive set of technical documentation, including an inventory of software components, third-party libraries and dependencies. While the CRA does not mandate a specific SBOM format, the structure aligns closely with international SBOM standards such as SPDX, CycloneDX and SWID.
Under the Cyber Resilience Act, an SBOM must help regulators and customers understand:
- What software components are included in a product
- Which components are open-source or third-party
- Known vulnerabilities associated with each component
- Licensing requirements of included components
- Update history and versioning
- Supplier dependency chains
In short, the SBOM becomes the backbone of CRA vulnerability handling, documentation, and post-market surveillance requirements.
Why SBOMs Are Critical Under the CRA
Several CRA obligations depend directly on maintaining an up-to-date SBOM. For example:
- Annex I Section 2 requires manufacturers to identify, assess and remediate vulnerabilities.
- Annex II Technical Documentation requires providing information about product architecture, components and dependencies.
- Post-market surveillance obligations rely on awareness of component-level vulnerabilities.
- Supply-chain security requires understanding which third-party elements may introduce risk.
This means manufacturers cannot comply with the Cyber Resilience Act without a functioning SBOM practice, updated throughout the lifecycle of the product.
CRA SBOM Requirements in Detail
Below is the most detailed breakdown of CRA SBOM requirements currently available, based on the final text of the regulation and authoritative interpretations from ENISA and EU cybersecurity experts.
1. A Complete Inventory of Software Components
The SBOM must list every software element included in a product, including:
- Proprietary code
- Open-source libraries
- Firmware modules
- Third-party binaries
- Dynamic or runtime-loaded modules
- Build-time dependencies
The CRA does not allow manufacturers to exclude components because they “seem low risk.” If it is in the product, it must be documented.
2. Versioning and Update Tracking
Manufacturers must maintain historical and current versions for each component to support CRA vulnerability handling and update obligations. This requirement is aligned with the NIST SP 800-218 framework.
3. Supplier and Licensing Metadata
An SBOM under the CRA must document:
- Component origin and supplier
- Licensing information (for open source)
- Security contact information when available
This supports supply-chain verification and license compliance—two areas regulators consider critical.
4. Link to Known Vulnerabilities (EPSS, CVE, NVD)
The CRA requires manufacturers to identify vulnerabilities affecting their product. An SBOM is the tool that enables automatic correlation between included components and vulnerability databases such as:
Without an SBOM, CRA-compliant vulnerability management is impossible.
5. Lifecycle Updates (Not a One-Off SBOM)
The CRA SBOM requirements clearly state that documentation must be updated throughout the product lifecycle, especially after:
- Firmware or software updates
- Component upgrades or replacements
- Third-party library patching
- Security incident remediation
This requirement aligns with CISA’s position that SBOMs must reflect “software as built” and “software as deployed.”
6. Format Requirements: SPDX, CycloneDX or SWID
The CRA does not mandate a specific SBOM format. However, European regulators strongly recommend using standardized, machine-readable formats. The three dominant standards are:
- SPDX – Supported by the Linux Foundation
- CycloneDX – Widely used in IoT and embedded products; supported by OWASP
- SWID tags – NIST-backed, used for enterprise environments
Most manufacturers choose CycloneDX because it maps cleanly to embedded systems and firmware.
7. SBOM Distribution Requirements (On Request)
Under the CRA, manufacturers must provide an SBOM:
- To authorities upon request
- To conformity assessment bodies
- To customers when needed for security purposes
This mirrors U.S. practices where SBOMs are increasingly required by enterprise customers for procurement processes.
How SBOMs Support CRA Vulnerability Handling Requirements
SBOMs are directly tied to Annex I Section 2 of the CRA, which defines vulnerability handling rules. An SBOM enables:
- Automatic detection of vulnerable dependencies
- Impact assessment of new CVEs
- Faster patch prioritization
- Evidence for CRA documentation and audits
According to ENISA, 72% of IoT vulnerabilities originate in third-party components. SBOMs offer the transparency required to address this problem.
SBOMs serve as the foundation for CRA vulnerability management and post-market surveillance.
SBOM Requirements for Embedded Systems Under the CRA
Embedded and firmware-driven products are among the most impacted by CRA SBOM requirements. These manufacturers must document:
- Bootloader versions
- Firmware modules and microcontroller firmware
- Real-time operating systems (RTOS)
- Chipset drivers
- Security modules and cryptographic libraries
CRA assessors often scrutinize firmware SBOM completeness because firmware vulnerabilities pose higher systemic risk.
Common Mistakes Manufacturers Make with CRA SBOM Requirements
- Creating a single SBOM snapshot instead of continuous updates
- Excluding “internal” or proprietary modules
- Failing to track transitive dependencies
- Using unstructured lists instead of machine-readable SBOM formats
- Not linking SBOM updates with release management
A non-compliant SBOM can jeopardize the entire CRA conformity assessment.
Recommended Tools for Generating SBOMs
Although the CRA does not mandate specific tools, popular options include:
Manufacturers should select tools that support continuous integration and automated build pipelines.
SBOMs connect directly to CRA documentation, classification and conformity requirements.
Conclusion
SBOMs are not optional under the Cyber Resilience Act—they are a foundational requirement that enables vulnerability management, regulatory documentation, supply-chain visibility and post-market cybersecurity controls. Manufacturers should begin implementing SBOM processes in 2025 to ensure full CRA compliance by 2027.
To continue preparing for CRA conformity, explore additional Regulus resources:
