The European Commission published its proposal for the Cyber Resilience Act (CRA) in September 2022, and it represents the most significant regulatory shift for software security since the executive orders and SBOM mandates emerging from the United States. But where the US approach has been largely focused on government procurement, the EU is going further — applying mandatory cybersecurity requirements to virtually all products with digital elements sold in the European market.
This isn't limited to European companies. Any organization selling software or connected products to EU customers will need to comply. The extraterritorial reach mirrors GDPR's impact on data privacy: if you serve the European market, European rules apply.
What the CRA Requires
The Cyber Resilience Act establishes cybersecurity requirements across the entire product lifecycle — from design through end-of-life. The obligations fall into several categories.
Security by Design and Default
Products with digital elements must be designed, developed, and produced with cybersecurity in mind. This isn't aspirational guidance — it's a legal requirement. Specific obligations include:
- Products must be delivered with secure default configurations
- Known vulnerabilities must not be present at the time of placement on the market
- Security updates must be provided for the expected product lifetime (minimum five years)
- Authentication mechanisms must be appropriate to the risk level
- Data stored, transmitted, or processed must be protected with state-of-the-art encryption
The "no known vulnerabilities" requirement is particularly significant. This doesn't mean zero CVEs in your dependency tree — that's often impossible. It means no exploitable vulnerabilities in the context of the product as deployed. Vendors will need to demonstrate they've assessed and addressed known vulnerabilities before shipping.
Vulnerability Handling Requirements
The CRA mandates a structured approach to vulnerability management:
- Vendors must identify and document vulnerabilities, including in third-party components
- Security updates must be made available without delay and free of charge
- Vendors must apply regular testing and review of product security
- Exploited vulnerabilities must be reported to ENISA (the EU Agency for Cybersecurity) within 24 hours of becoming aware
- A coordinated vulnerability disclosure policy must be in place
The 24-hour reporting requirement for actively exploited vulnerabilities is aggressive. Most organizations today take days or weeks to confirm exploitation, let alone report it to a regulatory body. Building the detection and reporting infrastructure to meet this timeline is a significant investment.
Software Bill of Materials
The CRA explicitly requires documentation of software components. Manufacturers must identify and document components and vulnerabilities of the product, "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 product."
Several aspects of this SBOM requirement deserve attention:
"Commonly used and machine-readable format" — This almost certainly means SPDX or CycloneDX. Proprietary or non-standard formats won't satisfy the requirement.
"At the very least the top-level dependencies" — The floor is direct dependencies, but the phrase "at the very least" signals that deeper dependency documentation may be expected, especially for higher-risk product categories.
Documentation, not publication — The initial proposal requires creating the SBOM and making it available to market surveillance authorities, not necessarily publishing it publicly. However, this could evolve as the legislation is finalized.
Product Categories and Risk Classification
The CRA classifies products into three categories:
- Default category — Most software products. Self-assessment by the manufacturer is sufficient.
- Class I (important) — Products with specific cybersecurity functions (identity management, VPNs, firewalls, etc.) or products that meet certain criteria. Third-party assessment or conformity with a harmonized standard is required.
- Class II (critical) — Operating systems, hardware security modules, smart card readers, and similar. Third-party conformity assessment is mandatory.
The classification determines the conformity assessment procedure, but the essential requirements — including the SBOM obligation — apply across all categories.
Impact on Open Source
The CRA's treatment of open source software generated substantial debate during the drafting process. The concern: would volunteer open source maintainers be subject to the same obligations as commercial software vendors?
The proposal includes an exemption for open source software that is not placed on the market "in the course of a commercial activity." A hobbyist publishing a package on npm for free wouldn't be subject to CRA requirements. But the lines blur quickly:
- A company that contributes to and distributes open source as part of its commercial offering is likely in scope
- Open source foundations that provide software for commercial use may face obligations
- Companies that bundle open source into commercial products bear the obligations for the entire product, including the open source components
The practical effect is that CRA obligations will be met primarily by commercial vendors who integrate open source. Those vendors will need to perform vulnerability management, generate SBOMs, and ensure security updates for the open source components they ship — whether or not the upstream project provides those things.
This shifts the economics of open source consumption. Companies can no longer treat open source as free in the operational sense. The cost of CRA compliance for open source components — vulnerability tracking, SBOM generation, security update management — becomes a direct business cost.
How This Differs from US SBOM Mandates
The US approach to software supply chain transparency has been primarily driven by Executive Order 14028 and subsequent guidance from CISA and NIST. The differences from the CRA are meaningful:
Scope: US mandates apply primarily to software sold to the federal government. The CRA applies to all products sold in the EU market.
Enforcement: US compliance is enforced through procurement requirements — non-compliant vendors lose government contracts. The CRA includes fines up to 15 million euros or 2.5% of global annual turnover, whichever is higher.
Lifecycle: US requirements focus on SBOM provision at the point of sale. The CRA mandates ongoing vulnerability management and security updates for the product's expected lifetime.
Reporting: The CRA's 24-hour vulnerability exploitation reporting has no direct equivalent in US federal requirements.
The CRA essentially takes the concepts from US executive orders and applies them more broadly, with stronger enforcement mechanisms and longer-term obligations.
Preparing for Compliance
Organizations selling into the EU market should begin preparation now, even though the CRA is still being finalized and implementation timelines include transition periods.
Establish SBOM Generation
If you're not already generating SBOMs for your products, start now. The tooling is mature, the formats are standardized, and the practice of SBOM generation is a prerequisite for virtually every other CRA obligation.
Generate SBOMs that include:
- All direct dependencies with exact versions
- Transitive dependencies to the extent feasible
- License information for each component
- Known vulnerability status at the time of generation
Build Vulnerability Handling Processes
The CRA requires ongoing vulnerability management, not point-in-time scanning. You need:
- Continuous monitoring of vulnerabilities in your components
- A process for assessing exploitability in the context of your product
- Rapid security update development and distribution capabilities
- A coordinated vulnerability disclosure policy
Document Security Design Decisions
The security-by-design requirement means documenting how security was considered during development. This includes threat models, security architecture decisions, testing methodologies, and the rationale for security-relevant configuration defaults.
Assess Your Open Source Dependencies
For every open source component in your product, evaluate:
- Is the project actively maintained?
- Does the project have a vulnerability handling process?
- Can you obtain or generate an SBOM for the component?
- Can you provide security updates if the upstream project becomes inactive?
Components where the answer is "no" to multiple questions are compliance risks that need to be addressed — either through upstream engagement, alternative components, or accepting the maintenance burden internally.
The Transparency Trajectory
The CRA sits on a clear trajectory: governments worldwide are moving from encouraging software transparency to mandating it. The US started with federal procurement. The EU is extending it to the entire market. Other jurisdictions — the UK, Japan, Australia, Singapore — are developing their own frameworks.
For software vendors, the question isn't whether transparency requirements will apply to them, but when. Investing in software transparency infrastructure now — SBOM generation, vulnerability management, security documentation — reduces the compliance scramble when regulations arrive and, more importantly, improves the security posture of the products you ship.
How Safeguard.sh Helps
Safeguard's platform is built for the software transparency future that regulations like the CRA are driving. Automated SBOM generation in both CycloneDX and SPDX formats ensures compliance with the CRA's machine-readable documentation requirements. Continuous vulnerability monitoring maps your dependency landscape against emerging threats, supporting the CRA's ongoing vulnerability handling obligations. Safeguard's compliance dashboards give teams a clear view of their CRA readiness across the entire product portfolio, making it possible to identify gaps and track remediation progress without drowning in spreadsheets. As regulation tightens, having this infrastructure already in place is the difference between measured compliance and last-minute scrambling.