The digital landscape is rapidly evolving, and with it, the regulatory environment. For businesses operating in or selling to the European Union, the upcoming European Union Cyber Resilience Act (EU CRA) represents a seismic shift in how software and hardware products with digital elements must address cybersecurity. If your organization relies on open source software (OSS) or secure containers – and let’s be honest, almost every modern business does – understanding the CRA is no longer optional. It’s critical for continued market access and avoiding significant penalties.
At ActiveState, we’ve been at the forefront of open source security for decades. We understand the complexities of managing vulnerabilities across vast dependency trees, and we know the EU CRA introduces new layers of legal responsibility. This post will break down the essentials of the CRA, its direct impact on your open source usage and container strategies, and how to proactively prepare for compliance.
What is the EU Cyber Resilience Act (EU CRA)?
The Cyber Resilience Act is a new European Union regulation designed to strengthen cybersecurity for “products with digital elements” (PDEs) throughout their entire lifecycle. PDEs are software or hardware products and their remote data processing solutions, including software and hardware components being placed in the market separately. Essentially, it places the burden of cybersecurity squarely on the shoulders of manufacturers, importers, and distributors who place these products on the EU market.
Key Goals of the EU CRA:
- Security by Design: Mandating that cybersecurity is integrated into products from the very beginning of their development.
- Lifecycle Security: Ensuring continuous security maintenance and vulnerability management for the product’s expected lifetime.
- Transparency: Requiring manufacturers to provide clear information about product security and handle vulnerabilities responsibly.
- Market Access: Products that don’t comply will not be allowed to be sold in the EU.
This mandate lays out how suppliers must secure their offerings and the financial consequences if they don’t.
Is Open Source Software Covered by the EU CRA?
Here’s where the CRA directly impacts virtually every software development team:
If your commercial product incorporates open source software, you become legally responsible for the security of that open source component.
This is the CRA’s most significant implication for developers. While purely non-commercial, community-driven open source projects are generally exempt, the moment you integrate an open source library, framework, or tool into your commercial product, you assume legal liability for its cybersecurity posture. This includes:
- Vulnerability Management: You must establish robust processes to continuously monitor, identify, and fix vulnerabilities in all your open source dependencies “without delay.”
- Software Bill of Materials (SBOM): You are required to generate and maintain a detailed, machine-readable SBOM for your product, listing all open source components, their versions, and their licenses.
- 24-Hour Reporting: You must report any actively exploited vulnerability in your product (including those originating from open source) to ENISA (the EU’s cybersecurity agency) within 24 hours of becoming aware of it.
- Security by Default: Ensuring that your product, inclusive of its OSS components, is configured securely by default.
The Container Conundrum: Secure Builds and Supply Chain Integrity
The CRA’s focus on “products with digital elements” extends directly to how you build and deploy your applications, especially within containerized environments. If your application, built within a container, is part of a PDE, then the container itself and all its contents fall under CRA scrutiny. Container security must be top of mind.
This means:
- Base Image Security: The operating system, libraries, and tools within your base container images must be secure and free from known vulnerabilities.
- Dependency Auditing: Every dependency you package into your container, particularly open source ones, must be accounted for in your SBOM and subject to continuous vulnerability monitoring.
- Reproducible Builds: To ensure supply chain integrity and verifiable security, your container builds need to be reproducible and auditable, proving that only trusted components are included.
- “Golden Image” Management: The practice of creating and maintaining a set of “golden” secure container images becomes essential for CRA compliance, ensuring every deployment starts from a trusted baseline.
Simply pulling arbitrary images from public registries or building containers without rigorous security practices will no longer suffice under the CRA.
Key CRA Deadlines You Need to Know
The CRA is not far off. Businesses need to act now.
- September 11, 2026: All manufacturers must be ready to comply with the 24-hour vulnerability reporting obligation.
- December 11, 2027: All other CRA obligations, including security-by-design, continuous vulnerability management, SBOM generation, and conformity assessments (leading to CE marking), become mandatory.
Missing these deadlines can lead to severe consequences, including fines of up to €15 million or 2.5% of your company’s total worldwide annual turnover, whichever is higher, and the prohibition of your products from the EU market (Article 64, Paragraph 2).
Preparing for the CRA: A Proactive Approach
To effectively address the CRA’s requirements, you need a strategy that integrates security throughout your entire SDLC, from code inception to deployment and maintenance.
Here’s how to start:
- Comprehensive Asset Inventory: Know exactly what open source components you’re using, where they came from, and how they interact. This is the foundation of your SBOM.
- Automated Vulnerability Scanning & Management: Manual processes won’t scale. Implement tools that continuously scan your codebases, dependencies, and containers for vulnerabilities and help you prioritize remediation. There are free tools like Trivy or Grype as well as commercial tools like Wiz or Snyk that provide continuous monitoring.
- Secure Supply Chain Practices: Harden your build processes, verify component origins, and minimize attack surfaces in your development pipeline.
- Defined Reporting Procedures: Establish clear internal protocols for identifying and reporting actively exploited vulnerabilities within the 24-hour window.
- Documentation & Evidence: Be prepared to demonstrate your compliance efforts to auditors.
ActiveState: Your Partner in EU CRA Compliance
This is where ActiveState becomes an invaluable partner. For decades, we’ve specialized in managing the complexities of open source security, providing verifiable, secure builds for critical applications. Our platform is uniquely positioned to help you meet and exceed the EU CRA’s demands:
- A Secure Catalog of 40M+ Open Source Components: We offer a curated, vulnerability-managed catalog of open source packages across multiple languages. Each component is built from source under controlled conditions, ensuring integrity and reducing the risk of hidden malicious code. This helps you start with a more secure foundation, making SBOM generation and vulnerability management significantly easier.
- Secure Containers: ActiveState creates containers built from the base up to be CVE free. By ensuring that every dependency within your container is secure, accounted for, and built from a trusted source, we help you establish the “golden images” required for CRA compliance and robust supply chain security.
- Automated SBOM Generation: ActiveState automatically generates comprehensive, machine-readable SBOMs for all your projects, including their open source dependencies. No more manual tracking; just accurate, auditable documentation ready for regulatory scrutiny.
- Proactive Vulnerability Monitoring & Remediation: We provide continuous monitoring of your component usage against known vulnerabilities, offering clear paths for remediation and helping you stay ahead of the CRA’s “without delay” mandate and the critical 24-hour reporting window.
- “Security by Default” Enablement: By providing secure, trusted components and enforcing best practices throughout the build process, we help you embed security by design and default, a core tenet of the CRA.
The Cyber Resilience Act presents a new challenge, but also an opportunity to elevate your cybersecurity posture and solidify trust with your customers. Don’t view it as a roadblock; view it as a catalyst for building more secure, resilient products.
Ready to ensure your open source software and containers are CRA compliant?
Don’t wait until the deadlines loom. Contact one of our OSS security experts today to learn how ActiveState can help you navigate the European Union’s Cyber Resilience Act, de-risk your open source usage, and secure your containerized applications. Get ahead of the regulations and focus on innovation with confidence.
Frequently Asked Questions (FAQs)
Who must comply with the EU CRA?
Companies who must comply with the EU CRA are those that provide products with digital elements, or PDEs.
What are the EU CRA fines?
Non-compliance can lead to fines of up to €15 million or 2.5% of a company’s total worldwide annual turnover, whichever is higher. It can also lead to the prohibition of your products from the EU market (Article 64, Paragraph 2)
What are the key dates for EU CRA compliance?
There are two upcoming critical deadlines for the CRA:
- September 11, 2026: All manufacturers must be ready to comply with the 24-hour vulnerability reporting obligation.
- December 11, 2027: All other CRA obligations, including security-by-design, continuous vulnerability management, SBOM generation, and conformity assessments (leading to CE marking), become mandatory.
Is open source covered by the EU CRA?
Yes, open source is covered by the EU CRA. If your commercial product incorporates open source software, you become legally responsible for the security of that open source component.
