Why SBOM is Critical for Compliance Under the EU Cyber Resilience Act (CRA)

Key Takeaways

• SBOM enhances transparency by providing a structured inventory of software components, supporting security by design
• The EU Cyber Resilience Act (CRA) mandates SBOM as part of security and compliance obligations for products with digital elements.
• TR-03183 requires SBOMs to be machine-readable (JSON/XML) and conform to SPDX or CycloneDX 1.5+, facilitating automated vulnerability handling.
• SBOMs do not contain vulnerability information but facilitate external vulnerability assessments (e.g., VEX, CSAF) as part of risk assessment
• Non-compliance penalties can reach €15 million or 2.5% of global annual turnover, with market surveillance authorities empowered to withdraw products from the market.
• CLOUDYRION helps organizations implement SBOMs, cryptographic signing, and compliance measures to meet EU CRA requirements.

---

The Challenge: Lack of Visibility into Third-Party Dependencies

One of the biggest challenges in software security is lack of visibility into third-party dependencies. Many organizations rely on third-party software components, yet they lack full visibility into what’s inside their applications. This makes it difficult to detect and respond to vulnerabilities, leading to increased risks of cyberattacks.

The EU CRA addresses these risks by enforcing transparent software security documentation, which includes mandatory SBOMs as a cornerstone of supply chain security. Without a structured SBOM, organizations struggle to:

• Detect and respond to vulnerabilities effectively, including actively exploited vulnerabilities
• Maintain compliance with regulatory requirements, such as those outlined in the NIS2 Directive
• Ensure software integrity and security, which are key aspects of secure by default principles

To tackle these issues, BSI’s TR-03183 mandates a machine-processable SBOM format that includes cryptographic integrity, metadata tracking, and structured dependencies. This approach aligns with the European cybersecurity certification scheme and supports the conformity assessment process required by the CRA.

CRA Compliance Timeline

Understanding the key dates is essential for planning your compliance journey:

Milestone	Date
CRA entered into force	10 December 2024
Reporting obligations apply	11 September 2026
Full obligations apply	11 December 2027

Important: The RED Delegated Act (EU 2022/30) is expected to be repealed with effect from December 11, 2027, leaving the CRA as the sole horizontal piece of legislation on product cybersecurity.

Enforcement and Penalties

The CRA introduces significant enforcement powers. Under Article 64, violations can result in:

Violation Type	Maximum Penalty
Serious infringements	€15 million or 2.5% of global turnover
Less serious infringements	€10 million or 2% of global turnover

In addition, market surveillance authorities may withdraw products from the market, prohibit their availability, or order recalls.

Which Products Are Affected? Understanding CRA Classification

The CRA applies to virtually all products with digital elements sold in the EU market. However, not all products face the same compliance requirements. The regulation introduces a risk-based classification system that determines the level of scrutiny and the type of conformity assessment required.

Standard Products (Default Category)

The majority of digital products fall into this category. Manufacturers can perform a self-assessment to demonstrate compliance – no third-party involvement required. This includes consumer applications, simple IoT devices, standard business software, and most connected products without critical security functions.

Class I – Important Products

Products in this category have elevated security relevance and require either internal control procedures based on harmonised standards or third-party assessment if standards are not applied. Class I products include:

• Password managers and authentication software
• VPN clients and remote access tools
• Network management and configuration tools
• Browsers and browser extensions
• Boot managers and BIOS/UEFI software

Class II – Critical Products

These products are essential to cybersecurity infrastructure and must undergo mandatory third-party conformity assessment by a notified body before market placement. Class II products include:

• Firewalls and intrusion detection/prevention systems (IDS/IPS)
• Hardware Security Modules (HSMs) and tamper-resistant hardware
• Operating systems (desktop, mobile, server)
• Hypervisors and container runtime environments
• Public Key Infrastructure (PKI) components
• Smart meters and critical infrastructure controllers

Products Excluded from the CRA

Certain product categories are explicitly excluded because they are already regulated under sector-specific legislation:

Exclusion	Applicable Regulation
Software-as-a-Service (SaaS)	NIS2 Directive (EU 2022/2555)
Automotive products	UN R155/R156
Medical devices	MDR/IVDR
Aviation systems	EU Aviation Safety Regulations
Defence and national security	Member State regulations
Open source software*	Exempt under certain conditions

*The open source exemption applies only to non-commercial, community-driven development without support obligations or direct financial compensation from users. Once integrated into a commercial product, open source components become the manufacturer’s responsibility.

Why Classification Matters

Correctly classifying your products is the critical first step in your compliance journey. Misclassification can lead to insufficient conformity assessment (risking non-compliance penalties) or unnecessary third-party costs. If you’re uncertain about your product’s classification, seek expert guidance early.

---

Understanding SBOM and Its Role in Compliance

A Software Bill of Materials is essentially a detailed inventory of software components, similar to an ingredient list for software. TR-03183 defines SBOM as a machine-readable document that supports automated security processing, which is crucial for managing the attack surface of products with digital elements.

Mandatory SBOM Elements (TR-03183-2)

A compliant SBOM MUST include:

• Component Name & Version – Ensuring traceability of dependencies
• Component Creator (Vendor/Supplier URL or Email) – Identification of software sources
• Licensing Information – Both declared and concluded licenses
• Cryptographic Hash (SHA-512) – Ensuring deployable component integrity
• File Properties – Whether the component is executable, an archive, or structured
• Timestamp – Date and time of SBOM creation
• Dependency Tracking – At least to the first external component

Without these mandatory fields, an SBOM does not meet compliance with TR-03183 and, by extension, the CRA requirements.

How TR-03183 Differs from US Standards

Organizations familiar with the US NTIA (National Telecommunications and Information Administration) minimum elements for SBOMs may wonder how European requirements compare. While both frameworks share common ground, TR-03183 imposes additional mandatory requirements that go beyond the US baseline.

SBOM Element	NTIA (USA)	TR-03183 (EU)
Supplier/Creator Name	✓	✓
Component Name	✓	✓
Component Version	✓	✓
Dependency Relationships	✓	✓
Timestamp	✓	✓
Unique Identifier	✓	✓
Cryptographic Hash (SHA-512)	–	✓ Required
License Information	–	✓ Required
SBOM URI/Document Namespace	–	✓ Required
File Properties (executable/archive)	–	✓ Required

Key Differences Explained

Cryptographic Hash: TR-03183 mandates SHA-512 hashes for all deployable components. This ensures integrity verification – you can prove that the component in production matches exactly what was documented in the SBOM.

License Information: European requirements explicitly include both declared and concluded licenses. This supports legal compliance and intellectual property management across the supply chain.

SBOM URI: Each SBOM must have a unique document namespace (URI), enabling unambiguous identification and cross-referencing across systems and organizations.

File Properties: Components must be classified by type (executable, archive, source code, or structured data), supporting more granular security analysis.

What This Means for Your Compliance Strategy

If your organization already produces SBOMs following NTIA guidelines, you have a solid foundation – but you’re not CRA-compliant yet. Upgrading to TR-03183 requires adding cryptographic hashes to all component entries, including comprehensive license data, implementing unique document identifiers, and classifying file properties for each component.

Most modern SBOM tools (Syft, Trivy, CycloneDX CLI) can generate TR-03183-compliant output with the right configuration. The key is updating your pipeline settings and validation checks before the 2027 deadline.

Common SBOM Formats

To ensure compatibility, SBOMs MUST be formatted in JSON or XML and follow one of these standards:

1. CycloneDX (Version 1.5 or higher) – Focused on security applications (preferred for CRA compliance)
2. SPDX (Version 2.2.1 or higher) – Widely used for software package descriptions and licensing
3. SWID Tags – Less common, but used in enterprise settings

SBOM and VEX (TR-03183 Compliance)

One common misconception is that SBOMs include vulnerability data. This is incorrect.

BSI TR-03183 explicitly states that SBOMs MUST NOT contain vulnerability information. This separation supports more effective vulnerability handling processes.

Instead, organizations should combine SBOMs with separate vulnerability reports using:

• VEX (Vulnerability Exploitability eXchange) – Provides context on whether a vulnerability is exploitable
• CSAF (Common Security Advisory Framework) – A standardized format for security advisories

Best Practice: Use SBOM for component transparency and VEX for vulnerability impact analysis.

---

2025 Developments: Standardization and Infrastructure

Since the CRA entered into force in December 2024, significant progress has been made on implementation infrastructure:

European Standardization

On 3 April 2025, the Standardization Request for the CRA was officially accepted by CEN, CENELEC, and ETSI. These European standardization organizations are developing:

• Type A standards: Horizontal standards covering general cybersecurity requirements
• Type B standards: Generic security requirements applicable across product categories
• Type C standards: Product-specific requirements (targeted for publication by October 2026)

In September 2025, ETSI published the first draft European Standards (EN) for public consultation, covering technical standards for product categories such as password managers, network interfaces, and operating systems.

ENISA Infrastructure

• European Vulnerability Database (EUVD) – Launched 13 May 2025, serving as a centralized platform for actionable vulnerability information across the EU
• Single Reporting Platform (SRP) – Currently under development for Article 16 vulnerability and incident reporting
• EUCC-CRA Alignment – ENISA has published studies analyzing how certification through EUCC could demonstrate CRA compliance, with pilot projects underway

BSI Technical Guideline Updates

The BSI is developing a comprehensive technical guideline in three parts:

• Part 1: General Requirements – Guidance for manufacturers and products aligned with CRA articles and annexes
• Part 2: Software Bill of Materials (SBOM) – Formal and substantive requirements for SBOMs
• Part 3: Vulnerability Reports and Notifications – Procedures for handling incoming vulnerability disclosures

---

Integrating SBOMs into CI/CD Pipelines

SBOMs should be integrated into the software lifecycle, ensuring they are generated and updated automatically at each build stage. By continuously monitoring dependencies and validating SBOMs with tools like Syft and Trivy, organizations can prevent security risks before deployment. Secure build pipelines play a critical role in mitigating software supply chain threats and supporting the product lifecycle.

BSI TR-03183 guideline requires that SBOMs be integrated into secure software development pipelines to ensure end-to-end traceability.

Best Practices for SBOM Integration

Effective SBOM implementation starts with automation. Organisations should generate SBOMs automatically at each build stage, ensuring that every release captures an accurate snapshot of all components. Dependency tracking tools such as Syft, Grype, and OWASP Dependency-Check help detect vulnerabilities before deployment reaches production. To further strengthen the integrity of your software supply chain, adopt the Supply Chain Levels for Software Artifacts (SLSA) framework for secure builds, and sign all SBOMs cryptographically using tools like Sigstore’s Cosign.

From Commit to Deployment: An Example Workflow

A well-designed pipeline weaves SBOM generation seamlessly into the development lifecycle. When developers commit code, the CI/CD pipeline automatically triggers SBOM generation. During the build process, this SBOM is integrated and validated, ensuring full transparency of all dependencies. Security tools then analyse the SBOM to identify potential risks before the build progresses. Once approved, both the final build artifacts and the accompanying SBOM are cryptographically signed. At deployment, the signed SBOM travels with the release, enabling regulatory audits and providing a verifiable record of exactly what was shipped.

This approach ensures compliance while minimising security risks and supporting long-term software resilience.

Cryptographic Hashing and Signing for SBOM Integrity

Ensuring the integrity of an SBOM is as important as having one. Without proper safeguards, an SBOM could be tampered with, undermining the trust it’s meant to provide. Code signing allows developers to use cryptographic signatures to verify software authenticity, while checksum validation ensures files remain unchanged using hash functions like SHA-256. For the SBOM itself, tools like Sigstore’s Cosign enable organisations to apply digital signatures that prove the document hasn’t been modified since creation. Together, these techniques align with the secure by default principles embedded in the CRA.

Secure Software Build Pipelines and SBOM Integration

For an SBOM to be truly effective, it must be embedded within secure development pipelines rather than bolted on as an afterthought. Reproducible builds ensure that the same source code always produces identical output, making it possible to verify that distributed binaries match their claimed origins. Build provenance tracking, supported by frameworks like SLSA, provides an auditable record of where and how software was built. Finally, ephemeral build environments—temporary, clean environments spun up for each build and destroyed afterwards—prevent persistent threats from compromising the pipeline over time.

---

Why SBOM Matters for Critical Industries

With the CRA, SBOMs are no longer optional – sectors like energy, healthcare, finance, and transportation rely on digital products that must meet strict regulatory standards. Without SBOM compliance, organizations risk non-compliance penalties. SBOM enhances resilience by:

• Providing visibility into third-party components to reduce supply chain risks
• Supporting proactive vulnerability management through automated security scans
• Facilitating incident response by quickly identifying affected components
• Ensuring software provenance and authenticity with cryptographic signing

These practices are particularly crucial for all companies offering products with digital elements in the EU market, regardless of their location.

---

Who Does the CRA Apply To?

The CRA has a broad scope, covering nearly all hardware and software products that can be connected to another device or network:

• All hardware and software products with digital elements sold in the EU
• Includes remote data processing solutions
• Applies regardless of where the product is manufactured
• Covers both B2C and B2B products
• Products made available for remuneration or free of charge

Open Source Software and the CRA

Using open source software does not exempt a commercial product from CRA requirements. If you integrate open source components into a product with digital elements that you place on the EU market, you are still responsible for ensuring compliance, including vulnerability management and SBOM.

Some purely community-driven open source projects without commercial activity are outside direct CRA obligations. However, once integrated in a commercial product with digital elements, they become part of the manufacturer’s responsibility.

Notable Exclusions

The CRA has some notable exceptions for heavily regulated industries that already have stringent cybersecurity requirements, including automotive, medical devices, and aviation. Additionally, SaaS falls under the NIS2 Directive rather than the CRA.

---

FAQ – People Also Ask

Q1: Does the SBOM need to be publicly available?

No. The CRA does not explicitly require public disclosure of the SBOM. However, it must be maintained as part of the technical documentation and be available for submission to market surveillance authorities upon request. This protects sensitive information about software composition from competitors and prevents attackers from more easily identifying vulnerabilities.

Q2: What SBOM format is required for CRA compliance?

TR-03183 requires a machine-readable format – either CycloneDX (version 1.5 or higher) or SPDX (version 2.2.1 or higher) in JSON or XML format. CycloneDX is preferred for CRA compliance due to its security focus and native VEX support. Both formats are internationally recognized and enable automated security analysis.

Q3: When does the SBOM requirement take effect?

Full applicability of the CRA, including the SBOM requirement, begins on 11 December 2027. The reporting obligation for actively exploited vulnerabilities starts as early as 11 September 2026. Organizations should begin implementation now, as integrating SBOM processes into existing development pipelines typically requires considerable time.

Q4: Does the CRA also apply to SaaS applications?

No. Pure Software-as-a-Service (SaaS) without local components falls under the NIS2 Directive (EU 2022/2555), not the CRA. NIS2 does not contain an explicit SBOM requirement but does mandate supply chain security. However, hybrid solutions with local components – such as desktop apps with cloud connectivity – may fall under the CRA.

Q5: Must vulnerabilities be documented in the SBOM?

No. BSI TR-03183 clarifies that SBOMs do not need to contain vulnerability information. Instead, separate formats such as VEX (Vulnerability Exploitability eXchange) or CSAF (Common Security Advisory Framework) should be used. This separation enables more efficient updating of vulnerability data without modifying the entire SBOM.

Q6: Which products are exempt from the SBOM requirement?

Exemptions apply to SaaS applications (covered by NIS2), automotive products (already regulated by UN R155/R156), medical devices (MDR/IVDR), aviation and defense products, and open source software under certain conditions. The open source exemption only applies to non-commercial development without support obligations or financial compensation from users.

Q7: How deep must SBOM dependency tracking go?

The CRA requires at least top-level dependencies. However, TR-03183 recommends tracking down to the first external component. For effective vulnerability management – as demonstrated by the Log4j incident – we recommend complete capture of all transitive dependencies to identify hidden risks in the supply chain.

---

Useful External Resources

• EU Commission CRA Implementation Page
• BSI Cyber Resilience Act Overview
• OpenSSF Free CRA Course (LFEL1001)
• European Vulnerability Database (EUVD)