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 draw up an SBOM in a commonly used, machine-readable format covering at least the product’s top-level dependencies, and keep it up to date in their technical 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.
Part of our guide to all 22 CRA essential requirements in Annex I.
What Are SBOM Requirements Under the Cyber Resilience Act?
The CRA SBOM requirements aim to ensure transparency and traceability of the software components included in a digital product. The CRA requires manufacturers to identify and document the components in their products, including by drawing up an SBOM in a commonly used and machine-readable format covering at the very least the top-level dependencies (Annex I, Part II, point 1). The SBOM belongs in the technical documentation (Annex VII), and market surveillance authorities can ask for it with a reasoned request. While the CRA does not currently mandate a specific SBOM format (the Commission may specify one by implementing act), the structure aligns closely with international SBOM standards such as SPDX, CycloneDX and SWID.
The legal minimum is short, but a useful SBOM helps you, and regulators when they ask, 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.
CRA DoC Generator
This generator asks for those fields and composes the declaration for you, ready to copy, download and put in front of whoever signs it.
Import your SBOM and keep it with the technical file
Regulus imports CycloneDX, tracks vulnerabilities against your components and puts the SBOM where Annex VII expects it. Free for manufacturers.
In Regulus, free for manufacturers: work through all 22 Annex I requirements, each with its evidence.
Why SBOMs Are Critical Under the CRA
Several CRA obligations depend directly on maintaining an up-to-date SBOM. For example:
- Annex I, Part II requires manufacturers to identify, assess and remediate vulnerabilities, and to draw up the SBOM.
- Annex VII Technical Documentation includes the SBOM, where applicable, among the information on vulnerability handling.
- 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 a breakdown of CRA SBOM requirements, separating what the final text of the regulation requires from what good practice adds.
1. A Complete Inventory of Software Components
The legal minimum is the top-level dependencies. Good practice is to 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
Don’t leave components out because they “seem low risk”: the CRA makes you responsible for not shipping vulnerable third-party components, and you can only track what you have documented.
2. Versioning and Update Tracking
Keeping historical and current versions for each component supports CRA vulnerability handling and update obligations. This requirement is aligned with the NIST SP 800-218 framework.
3. Supplier and Licensing Metadata
The CRA does not require these fields, but a good SBOM records:
- Component origin and supplier
- Licensing information (for open source)
- Security contact information when available
This supports supply-chain verification and license compliance.
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 requires the technical documentation, SBOM included, to be continuously updated where appropriate, at least during the support period. In practice, refresh the SBOM 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, it does require a commonly used, machine-readable format. 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
Many embedded manufacturers choose CycloneDX because it maps cleanly to embedded systems and firmware.
7. SBOM Distribution Requirements (On Request)
Under the CRA, the SBOM is not a public document. Manufacturers share it:
- With market surveillance authorities, on a reasoned request
- With notified bodies, as part of the technical documentation, where one is involved
- With customers only if they choose to (manufacturers are not obliged to make it public)
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, Part II 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
Third-party components are a major source of vulnerabilities in connected products, and 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 should document:
- Bootloader versions
- Firmware modules and microcontroller firmware
- Real-time operating systems (RTOS)
- Chipset drivers
- Security modules and cryptographic libraries
Firmware SBOM completeness deserves extra attention 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
- Stopping at top-level dependencies, the legal minimum, when transitive ones carry much of the risk
- 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 implement SBOM processes now to ensure full CRA compliance by December 2027.
To continue preparing for CRA conformity, explore additional Regulus resources:
