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. 
• BSI’s TR-03183-2 v1.0 implementation guideline requires machine-readable SBOMs in CycloneDX 1.4+ or SPDX 2.3+, supporting automated vulnerability handling. The CRA itself leaves SBOM format and elements to Commission implementing acts and harmonized standards. 
• 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 address these challenges, BSI’s TR-03183 (implementation guidance) recommends 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. 

BSI TR-03183 is a German implementation guideline that supports CRA-aligned SBOM practices. It is not itself binding EU law: the CRA’s binding requirements come from the Regulation, harmonized standards cited in the OJEU, and Commission implementing acts. TR-03183 is a strong reference profile, particularly for vendors selling into the German market and German public sector. 

CRA Compliance Timeline 

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

Milestone	Date
CRA enters into force	10 December 2024
Chapter IV (notification of conformity assessment bodies) applies	11 June 2026
Article 14 reporting obligations begin	11 September 2026
Sufficient notified bodies expected operational	11 December 2026
Full CRA application	11 December 2027

Important: Commission Delegated Regulation (EU) 2026/339 of 16 February 2026 has formally repealed the RED Delegated Regulation (EU) 2022/30, with effect from 11 December 2027 — the date the CRA becomes fully applicable. Until then, RED cybersecurity requirements continue to apply to in-scope radio equipment placed on the EU market from 1 August 2025. Market surveillance under the RED remains enforceable for equipment placed on the market between 1 August 2025 and 10 December 2027, even after the repeal takes effect. 

Enforcement and Penalties Under Article 64 

CRA penalties are three-tiered: 

• Tier 1 — up to €15 million or 2.5% of total worldwide annual turnover (whichever is higher) for non-compliance with the essential cybersecurity requirements in Annex I or the manufacturer obligations in Articles 13 and 14. 
• Tier 2 — up to €10 million or 2% for other economic-operator and conformity-assessment breaches (importer, distributor, EU declaration of conformity, technical documentation, CE marking, conformity assessment procedures, cooperation with market surveillance). 
• Tier 3 — up to €5 million or 1% for providing incorrect, incomplete, or misleading information to notified bodies or market-surveillance authorities. 

In practice, market-surveillance measures may be more commercially painful than the fine itself. National authorities can require corrective action, restrict availability, or order withdrawal, recall, or prohibition of placing a product on the EU market. 

Two important derogations under Article 64(10): 

• Microenterprises and small enterprises are exempt from administrative fines for failing to meet the 24-hour early-warning deadline under Article 14(2)(a) (and the equivalent severe-incident deadline under Article 14(4)(a)). Other obligations and other deadlines still apply. 
• Open-source software stewards are exempt from CRA administrative fines for any infringement. Their underlying obligations (cybersecurity policy, vulnerability handling, cooperation with market surveillance, reporting) still apply, but no monetary penalty can be imposed for non-compliance. 

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 harmonized 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 
• Operating systems (desktop, mobile, server) 
• Public Key Infrastructure (PKI) and digital certificate issuance software 

Class II — Important Products (higher-risk) 

Class II products listed in Annex III have higher cybersecurity relevance and are subject to stricter conformity assessment procedures under Article 32(3). Class II Important Products are an exhaustive list of four categories: 

• Hypervisors and container runtime systems that support virtualized execution of operating systems and similar environments 
• Firewalls, intrusion detection and prevention systems 
• Tamper-resistant microprocessors 
• Tamper-resistant microcontrollers 

For Class II products, manufacturers must demonstrate conformity using one of the following Article 32(3) procedures (the simpler internal control route available for default and certain Class I products is not permitted for Class II): 

• EU-type examination (Module B) followed by conformity to type based on internal production control (Module C) 
• Conformity assessment based on full quality assurance (Module H) 
• Where available and applicable, a European cybersecurity certification scheme at assurance level at least ‘substantial’ 

Critical Products (Annex IV) 

A separate, narrower category. Under Article 8(1), Critical Products may be required to obtain a European cybersecurity certificate at assurance level at least ‘substantial’. Where no such scheme is available or mandated, manufacturers follow the same Article 32(3) procedures as Class II Important Products. Critical Products listed in Annex IV include: 

• Hardware devices with security boxes (e.g. tamper-resistant security modules used in critical applications) 
• Smart meter gateways within smart metering systems 
• Smartcards and similar devices, including secure elements 

Most products in this category are sector-critical infrastructure components, not general enterprise IT. 

Class II and Critical Products: Conformity Planning Is a 2026 Workstream 

If your product is Class II or Critical, treat conformity-route selection and notified-body / Module H planning as a 2026 workstream, not a 2027 afterthought. 

Three CRA dates make this concrete: 

• 11 June 2026 — Chapter IV (notification of conformity assessment bodies) becomes applicable. Member States designate notifying authorities; conformity assessment bodies start formal notification procedures. 
• 11 December 2026 — sufficient notified bodies should be designated to ensure capacity and avoid bottlenecks. 
• 11 December 2027 — full CRA application; products requiring third-party conformity assessment cannot be placed on the EU market without it. 

The window between June 2026 and December 2027 is when notified-body engagement, Module H quality-system audits (where chosen), or European cybersecurity certification scheme participation has to happen. Engaging late means competing with every other Class II/Critical manufacturer for limited notified-body capacity in 2027. 

Products Excluded from the CRA 

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

Exclusion	Applicable Regulation
Automotive products	UN R155/R156
Medical devices	MDR/IVDR
Aviation systems	EU Aviation Safety Regulations
Defense 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. 

What about SaaS and Cloud Services? 

SaaS is not a clean exclusion. The CRA distinguishes between standalone services and remote data processing solutions: 

• Standalone SaaS — software delivered as a service that is not necessary for any product with digital elements to function — generally falls outside the CRA product framework. 
• Remote data processing solutions that are necessary for a product with digital elements to perform one or more of its functions are explicitly in scope of the CRA, and the manufacturer of the connected product remains responsible for them. 

NIS2 is not a categorical substitute for the CRA either. NIS2 applies to specific entity types (cloud computing providers, data centers, managed service providers, MSSPs, online marketplaces, search engines, social platforms, and others) based on sector, size, and role — it does not ‘replace’ the CRA for SaaS in general. 

Practical takeaway: if your SaaS supports a connected product, parts of your stack are likely in CRA scope. If you operate a qualifying SaaS entity, NIS2 obligations may apply in parallel — not instead. 

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. 

Legal Floor vs Implementation Benchmark 

Two layers, often conflated: 

• The CRA legal floor — the Regulation requires manufacturers to identify and document the components and vulnerabilities of their products with digital elements, including by drawing up an SBOM in a commonly used machine-readable format covering at least the top-level dependencies. That is the binding minimum. The exact format and elements will be specified by Commission implementing acts and harmonized standards over time. 
• The BSI TR-03183 implementation benchmark — TR-03183 is a non-binding BSI implementation guideline that goes considerably further: it specifies SBOM fields, formats, hash algorithms, and a separation between SBOM and vulnerability data via VEX/CSAF. It is structured in three parts: Part 1 (general requirements), Part 2 (SBOM), and Part 3 (vulnerability reports and notifications), and is continuously updated. 

For German and EU manufacturers, the safest planning assumption is to treat the CRA as the legal floor and TR-03183 as a practical quality benchmark — while monitoring harmonized standards and Commission implementing acts as they mature. Following TR-03183 does not create a presumption of conformity; following an OJEU-cited harmonized standard does. 

Availability ≠ Public Publication 

The CRA does not generally require manufacturers to publish SBOMs publicly. Technical documentation under Annex VII — including SBOM-related elements — must be created, maintained, and made available to market surveillance authorities and conformity assessment bodies on request. Manufacturers may also share SBOMs (typically under NDA) with enterprise customers as part of vendor risk processes. 

There is one notable exception: the Commission’s FAQ identifies a specific situation involving certain free and open-source software where self-assessment publication may apply. For the typical commercial product manufacturer, plan for SBOM availability to regulators and contractually-bound customers — not for public release. 

Required SBOM Elements under the TR-03183-2 BSI Profile 

Under BSI TR-03183-2 v1.0 (12 July 2023), an SBOM intended to satisfy this implementation guideline must include the elements below. (CRA-binding requirements may differ once the relevant implementing acts and harmonized standards are finalized — TR-03183-2 itself is BSI implementation guidance, not binding EU law.) 

• 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 of the executable component (SHA-256) — a cryptographically secure checksum of the component in its executable form, ensuring you can verify the deployable component matches what is documented in the SBOM (per TR-03183-2 v1.0 Section 5.2.2) 
• 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 elements, an SBOM does not satisfy the TR-03183-2 v1.0 implementation profile. Note that TR-03183-2 is a BSI implementation guideline; CRA legal compliance ultimately follows from the Regulation itself, harmonized standards once cited in the OJEU, and Commission implementing acts. 

How Deep Should the SBOM Go? 

The CRA legal floor (Annex I, Part I) requires an SBOM covering at least the top-level dependencies of the product. The BSI TR-03183-2 v1.0 implementation profile goes further: it requires a delivery-scope SBOM (“Liefergegenstands-SBOM”), generated as part of the build process, that recursively resolves dependencies on every path at least up to and including the first component that is no longer part of the delivery (Section 5.1). 

In practical terms: top-level dependencies satisfy the regulation as currently written; following TR-03183-2 means resolving deeper, with every in-delivery component fully described before the SBOM stops at the first external boundary. This is one of the clearest examples of why CRA-aligned ≠ TR-03183-aligned, and why German manufacturers in particular plan to follow the BSI profile rather than just the bare CRA wording. 

How the TR-03183-2 BSI Profile Differs from US (NTIA) Minimum Elements 

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, the TR-03183-2 BSI profile recommends additional elements that go beyond the US baseline. 

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

Note: TR-03183-2 is a BSI implementation profile. The CRA itself leaves SBOM elements to Commission implementing acts and harmonized standards. 

Key Differences Explained 

Cryptographic Hash: TR-03183-2 v1.0 requires SHA-256 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 

BSI TR-03183-2 v1.0 (Section 4) requires SBOMs to be in one of the following formats: 

1. CycloneDX, version 1.4 or higher— security-oriented format, well-suited to CRA-aligned workflows 
2. SPDX (Software Package DataeXchange), version 2.3 or higher— widely used for software package description and licensing 

Note on SWID: SWID Tags do not appear in TR-03183-2 v1.0 and are not part of the BSI implementation profile. SWID may still be useful in enterprise asset-management contexts that already use it, but should not be relied on as a CRA / TR-03183 compliance path. CycloneDX and SPDX are the formats the BSI guideline is built around. 

SBOM and VEX (TR-03183 Compliance) 

One common question is whether SBOMs themselves should carry vulnerability data, or whether vulnerability information should be transmitted separately. 

BSI TR-03183-2 v1.0 (Section 3.1) is direct on this: an SBOM does not contain vulnerability information. The standard explicitly notes that the SBOM formats themselves offer the option to include vulnerability data — but states that doing so is not advisable. To establish whether a product is affected by a vulnerability, BSI recommends matching the SBOM’s component list against vulnerability information sources (CVE, security advisories) and using VEX (Vulnerability Exploitability eXchange) or security advisories to communicate exploitability. 

Practical takeaway: under the TR-03183-2 profile, keep component inventory in the SBOM and ship vulnerability/exploitability information separately via VEX or CSAF (Common Security Advisory Framework). This is BSI’s design recommendation, not a blanket prohibition by the SBOM formats themselves — CycloneDX supports multiple BOM types and SPDX 3.0 has a security profile. 

2025/26 Developments: Standardization and Infrastructure 

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

Don’t Wait for Harmonized Standards — But Track Them Closely 

The CRA’s harmonized standards are being developed under Commission standardization request M/606, covering 41 horizontal and product-specific standards. The request was officially accepted by CEN, CENELEC, and ETSI on 3 April 2025. Once individual standards are cited in the Official Journal of the EU (OJEU), they can provide presumption of conformity with the CRA’s essential cybersecurity requirements. 

Until then, manufacturers should plan with the CRA text itself, the European Commission’s CRA guidance and FAQ, BSI TR-03183, and emerging CEN/CENELEC/ETSI drafts as the practical implementation stack. Waiting for harmonized standards before starting CRA work is not a viable strategy — most timelines suggest only a subset of M/606 standards will be OJEU-cited before December 2027. 

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 14 vulnerability and incident reporting 
• EUCC-CRA Alignment — ENISA has published studies analyzing how certification through EUCC could demonstrate CRA compliance, with pilot projects underway 

EUVD and SRP Are Different Systems 

The European Vulnerability Database (EUVD) and the CRA Single Reporting Platform (SRP) are often confused. They serve different purposes: 

• EUVD — vulnerability transparency and intelligence infrastructure. ENISA-operated, public-facing, and analogous in function to NVD or CVE Details. Treat it as an inbound intelligence source. 
• SRP — the regulatory reporting channel manufacturers must use for Article 14 obligations. Notifications submitted via the SRP are routed to the designated CSIRT coordinator and ENISA. Treat it as the outbound regulatory reporting channel. 

In a CRA program, EUVD feeds your monitoring and triage. SRP receives your notifications when an actively exploited vulnerability or severe incident is confirmed. 

Article 14 Reporting: the 24h / 72h / Final-Report Clock 

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through the ENISA Single Reporting Platform (SRP). The cadence is fixed: 

• Early warning — within 24 hours of the manufacturer becoming aware. 
• Vulnerability/incident notification — within 72 hours. 
• Final report — for actively exploited vulnerabilities, no later than 14 days after a corrective or mitigating measure becomes available; for severe incidents, within one month of the 72-hour notification. 

Crucially, Article 14 reporting applies to legacy products as well. Article 69(3) carves out a derogation: even though substantive CRA obligations only attach to products placed on the market before 11 December 2027 if those products undergo a substantial modification, the Article 14 reporting obligations apply to all in-scope products on the market — including those shipped years ago. Practically, this means manufacturers need SBOM and vulnerability-handling capability for the existing product portfolio by September 2026, not December 2027. 

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 

How SBOM Fits Into the Broader CRA Obligation Set 

SBOM is one piece of CRA compliance — visible because it’s tangible and tooled, but far from the whole picture. A complete CRA program also covers: 

• CE marking — products with digital elements must carry the CE mark, supported by an EU Declaration of Conformity (Annex V). 
• Technical documentation (Annex VII) — a structured docset including risk assessment, design and development information, vulnerability handling procedures, and component inventory (where SBOM lives). 
• Vulnerability handling (Article 13) — manufacturers must establish and operate a vulnerability handling process, akin to a PSIRT function: intake, triage, fix, disclosure, customer notification. 
• Reporting obligations (Article 14) — when an actively exploited vulnerability is discovered, manufacturers must submit an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report within 14 days, via the ENISA Single Reporting Platform. Severe incidents follow a similar cadence. 
• Support period — manufacturers must define a support period that reflects the expected use time of the product. The support period is at least five years unless the product is reasonably expected to be used for less than five years, in which case it can match the expected use time. SBOM directly underpins this: you cannot patch what you cannot inventory. 
• Role split — distinct obligations attach to manufacturers, importers, distributors, and authorized representatives. Mis-identifying your role is a frequent compliance error in EU product law. 
• Open Source Steward — a new CRA category. Stewards (organizations that systematically support development of OSS used in commercial products) carry a lighter, but real, set of obligations distinct from manufacturers. 

SBOM is the foundation that makes vulnerability handling, reporting, and the support period operational. It is necessary, but not sufficient, for CRA compliance. 

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 (implementation guidance) recommends integrating SBOMs into secure software development pipelines to ensure end-to-end traceability. 

Best Practices for SBOM Integration 

Effective SBOM implementation starts with automation. Organizations 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 analyze 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 minimizing 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 organizations 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 afterward — 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 carves out sectors that are already governed by their own cybersecurity-relevant regimes — notably automotive (UN R155/R156), medical devices (MDR/IVDR), aviation, and defense. SaaS is more nuanced: standalone SaaS generally sits outside the CRA product framework, but remote data processing solutions integral to a product with digital elements remain in scope. NIS2 may apply in parallel to qualifying SaaS providers based on entity type, sector, and size — it is not a blanket replacement for the CRA. 

Why This Matters Beyond CRA Fines 

CRA compliance is not just a regulatory checkbox. The revised Product Liability Directive — Directive (EU) 2024/2853, adopted 23 October 2024 — must be transposed into national law by 9 December 2026 and applies to products placed on the market or put into service after that date. The Directive explicitly includes software within the definition of “product”, and its recitals make clear that cybersecurity vulnerabilities and the failure to supply necessary security updates can render a product defective for liability purposes. 

Practical consequence: poor SBOM quality, weak vulnerability handling, and missed security updates may create exposure on two fronts simultaneously — CRA administrative fines and market-surveillance remedies under public law, and civil-liability claims under national product liability law as transposed from PLD 2024/2853. SBOM and vulnerability handling are not just regulatory hygiene; they are evidence in a defective-product claim. 

What the CRA Means for the German Market Specifically 

For products placed on the German market, three additional layers matter alongside the CRA itself: 

• BSI Marktaufsicht — the BSI is positioning itself as a market surveillance authority for parts of the CRA. Its existing TR-03183 work signals where its enforcement attention will likely concentrate. 
• BNetzA’s role — the Bundesnetzagentur retains market surveillance for radio equipment under the RED, and that responsibility carries over for products in the RED-to-CRA transition window (1 August 2025 to 10 December 2027). 
• IT-SiG 2.0 / KRITIS interaction — operators of critical infrastructure in Germany already carry obligations under the IT-Sicherheitsgesetz 2.0 and BSIG. CRA-regulated products supplied into KRITIS environments will face a stacked obligation set: product-level CRA conformity at the manufacturer plus operator-level KRITIS obligations downstream. Vendor selection and contractual flow-down become decisive. 

CLOUDYRION advises German manufacturers on the practical interaction of these regimes — particularly where products with digital elements are sold into KRITIS sectors. 

Procurement Checklist: What to Ask Suppliers for CRA-Ready SBOMs 

When evaluating or onboarding suppliers of products with digital elements, ask for the following as part of the contractual deliverables: 

• Machine-readable SBOM per release (CycloneDX or SPDX) 
• Clear component identification: name, version, supplier, dependency relationship 
• Stated dependency depth (top-level only vs full transitive graph) 
• Cryptographic hashes for deployable components 
• License metadata for each component 
• Vulnerability-handling SLAs (triage, fix, disclosure timeframes) 
• VEX or CSAF status feeds for ongoing exploitability assertions 
• Notification commitments that allow you to meet the CRA’s 24-hour reporting clock for actively exploited vulnerabilities discovered downstream 
• For critical suppliers: a contractual right to validate SBOM quality against the TR-03183-2 profile or, once available, the applicable harmonized standard 

These clauses translate the CRA’s manufacturer obligations into supplier obligations, which is what enterprise procurement and CISOs need to operationalize before September 2026. 

Useful External Resources 

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