The European Union's Cyber Resilience Act (CRA) was making its way through the legislative process in early 2023, and the software industry was starting to pay attention. The CRA proposes mandatory cybersecurity requirements for all products with digital elements sold in the EU market — which means essentially all software, from operating systems to IoT firmware to SaaS platforms.
For the first time, selling software in Europe would come with legally binding security obligations, complete with significant fines for non-compliance. By mid-2023, the specifics were becoming clear enough to assess the impact.
What the CRA Requires
Security by Design
Manufacturers must ensure that products are designed and developed with security from the start:
- Products must be delivered without known exploitable vulnerabilities
- Default configurations must be secure
- Data stored within and transmitted by the product must be protected
- Products must limit attack surfaces, including external interfaces
- Products must be designed to reduce the impact of security incidents
Vulnerability Handling
Manufacturers must establish and maintain processes for:
- Identifying and documenting vulnerabilities, including through testing
- Addressing vulnerabilities without delay through security updates
- Applying regular testing and review of security
- Publicly disclosing information about fixed vulnerabilities
- Maintaining a coordinated vulnerability disclosure policy
SBOM Requirements
Manufacturers must identify and document components and dependencies in their products. The CRA specifically mentions SBOMs as the mechanism for this, requiring:
- Documentation of all third-party components
- Identification of known vulnerabilities in components
- Updating this documentation throughout the product lifecycle
Incident Reporting
Manufacturers must report actively exploited vulnerabilities to ENISA (the EU's cybersecurity agency) within 24 hours of becoming aware of them.
Lifecycle Requirements
Security support must be provided for a minimum of five years, or the expected product lifetime, whichever is longer. This includes:
- Providing security updates for the support period
- Making security updates available free of charge
- Providing clear information about the support timeline
The Open Source Question
The CRA's most controversial aspect has been its potential impact on open source software. Initial drafts of the legislation didn't adequately distinguish between commercial software and non-commercial open source development, raising fears that volunteer maintainers could be held liable for security issues in their code.
The Concern
Under a strict reading of early CRA drafts:
- A solo developer who publishes a library on npm that gets widely adopted could be classified as a "manufacturer"
- That developer would need to comply with all CRA requirements: vulnerability handling, SBOM maintenance, incident reporting, and five years of security updates
- Non-compliance could result in fines of up to 15 million euros or 2.5% of global annual turnover
For obvious reasons, this sent shockwaves through the open source community.
The Response
The open source community pushed back forcefully. Major organizations including the Linux Foundation, Eclipse Foundation, Apache Software Foundation, and Python Software Foundation provided feedback arguing that:
- Open source is a development methodology, not a business model
- Imposing commercial obligations on volunteer maintainers would discourage open source development
- The EU benefits enormously from open source software and should protect, not burden, its contributors
- The existing open source ecosystem provides security through transparency and community review
The Evolving Language
Through 2023, the CRA text was revised to address some of these concerns. Key clarifications included:
- Non-commercial open source development is explicitly excluded from the "manufacturer" definition
- However, if an open source project is developed in a "commercial context" (by a company, with commercial intent), it falls under the CRA
- Open source stewards (foundations and organizations that support open source development) have a lighter set of obligations
The line between commercial and non-commercial open source remains blurry. A startup that releases its core product as open source — is that commercial? A solo developer who accepts donations on GitHub — is that commercial? These questions were still being debated.
Impact on Software Companies
Compliance Cost
Companies selling software in the EU will need to:
- Implement formal vulnerability management processes
- Generate and maintain SBOMs for all products
- Report exploited vulnerabilities within 24 hours
- Provide security updates for at least five years
- Undergo conformity assessments (self-assessment for most products, third-party assessment for "critical" products)
Product Classification
The CRA classifies products into tiers based on risk:
- Default category: Self-assessment against essential requirements
- Important products, Class I: Identity management systems, VPNs, network management tools, etc. — require conformity assessment using harmonized standards
- Important products, Class II: Operating systems, firewalls, hardware security modules, etc. — require third-party assessment
- Critical products: Smart cards, hardware tokens, smart meter gateways — require European cybersecurity certification
Timeline
The CRA is expected to apply 36 months after entering into force, with the vulnerability reporting obligation applying after 21 months. Companies should begin preparing now.
What Developers Should Do Now
Start Generating SBOMs
If you sell software in the EU, SBOMs will be required. Start generating them now:
- Choose a format (SPDX or CycloneDX)
- Integrate SBOM generation into your build pipeline
- Establish processes for maintaining and updating SBOMs
Formalize Vulnerability Management
Document your processes for:
- Vulnerability discovery and triage
- Patch development and testing
- Security update distribution
- Customer notification
Plan for Long-Term Support
Five years of security support is a significant commitment. Plan your product lifecycle accordingly.
Track the Legislation
The CRA is still evolving. Monitor the legislative process and prepare to adapt as the final text is published.
How Safeguard.sh Helps
Safeguard.sh is built to help organizations meet CRA requirements:
- SBOM Generation and Management: Safeguard.sh generates CRA-compliant SBOMs in standard formats, automatically updating them as your software evolves.
- Vulnerability Monitoring: Safeguard.sh provides continuous vulnerability monitoring against your SBOMs, helping you identify and address vulnerabilities in compliance with CRA timelines.
- Compliance Reporting: Safeguard.sh generates reports documenting your software composition, vulnerability status, and security practices, supporting CRA conformity assessments.
- Supply Chain Transparency: Safeguard.sh provides the end-to-end supply chain visibility that the CRA's documentation requirements demand.
The CRA represents a fundamental shift in how the EU regulates software security. Organizations that build compliant practices now will have a competitive advantage when the requirements take effect. Those that wait will face a scramble.