EU Cyber Resilience Act (CRA) Requirements Guide

The regulatory clock is ticking. The Cyber Resilience Act is no longer a distant policy discussion - it's a live regulation with real deadlines, real penalties, and real operational consequences for any company selling software or hardware in the European Union. If you're not already preparing, you're falling behind.
Key Takeaways
- The CRA is already in force. It entered into force in December 2024, with vulnerability reporting obligations starting September 2026 and full enforcement by December 2027. The window to prepare is now - not when the deadline is six months away.
- It covers nearly every digital product. If your software or hardware connects to a device or network and is sold in the EU, you're almost certainly in scope. Don't assume sector exemptions apply without verifying.
- Compliance is a lifecycle commitment, not a one-time project. The CRA demands ongoing vulnerability management, SBOM maintenance, incident reporting, and technical documentation - continuously, not just at launch.
- The costs are significant - benchmark against FedRAMP. With FedRAMP compliance running $500K–$2M+ in initial investment plus $150K–$500K+ annually, the CRA demands comparable financial and operational commitment. Early planning is the best cost-reduction strategy available.
- Container-level security is foundational. Hardened images, CVE management, and SBOM generation aren't optional add-ons for CRA compliance - they're core requirements. Using a secure-by-design foundation like Echo gives teams a meaningful head start on all three fronts.
What Is the CRA and Why Does It Exist?
The cyber resilience act (formally Regulation (EU) 2024/2847) is the EU's first horizontal regulatory framework establishing mandatory cybersecurity requirements across hardware and software products. Unlike sector-specific rules that apply to medical devices or aviation, the CRA applies broadly to any product with a "digital element" - meaning most software, connected hardware, and their supporting services.
The motivation is straightforward: consumers and businesses have been routinely exposed to security flaws in digital products, often without any knowledge of the risks. The CRA closes this gap by making manufacturers legally responsible for the security of their products - not just at launch, but throughout the entire product lifecycle. Research shows that cybersecurity threats circulating via open source package repositories grew by more than 1,300% between 2020 and 2023, which underscores exactly why regulators felt compelled to act.
The Timeline: key dates you cannot afford to miss
Understanding the phased rollout is critical for planning:
- December 10, 2024 - The CRA entered into force, starting the clock on phased obligations.
- June 11, 2026 - Conformity assessment bodies begin notifying under CRA rules.
- September 11, 2026 - Reporting obligations take effect. Manufacturers must report, without undue delay, any actively exploited vulnerability in their products, as well as any severe incident impacting product security.
- December 11, 2027 - All CRA requirements become fully enforceable across all 27 EU member states.
That gives most organizations roughly 18 months from today to reach full compliance. For complex software platforms, that's not a lot of runway.
What Does the CRA Actually Require?
The CRA establishes a "secure by design and by default" baseline. It's not about ticking boxes once - it's about embedding security into every phase of the product lifecycle. Key obligations include:
- Vulnerability management: Manufacturers must actively identify, track, and remediate vulnerabilities throughout a product's support period.
- SBOM (Software Bill of Materials): Companies must maintain a complete, up-to-date inventory of all software components - including open source dependencies - in a commonly used, machine-readable format.
- Incident reporting: Manufacturers must report actively exploited vulnerabilities to ENISA and national CSIRTs within 24 hours of awareness, with a final remediation report due within 14 days of a fix becoming available.
- CE marking: Products must carry CE marking demonstrating compliance with CRA essential cybersecurity requirements before going to market.
- Technical documentation: Detailed records - including product descriptions, risk assessments, test results, and proof of conformity - must be maintained and available for audits.
- Supply chain accountability: Organizations must govern third parties and maintain market-readiness throughout the supply chain.
Products are categorized into four risk classes - default, important (Class I & II), and critical - with stricter conformity assessment procedures for higher-risk categories such as operating systems, password managers, and smartcards.
The Three Foundational Pillars
To meet the CRA's essential requirements, organizations must focus on three areas:
1. SBOM generation and maintenance The CRA mandates that SBOMs cover "at the very least the top-level dependencies of the product." Automating SBOM generation through tools that integrate with your development workflows is the only scalable approach at pace.
2. Vulnerability management and remediation The regulation instructs organizations to "address and remediate vulnerabilities without delay, including by providing security updates." Products must also protect the integrity of stored and transmitted data and be designed to reduce the impact of an incident.
3. Asset inventory and rapid reporting Having full visibility into all products with digital elements (PDEs), software versions, and dependencies is essential to pinpointing affected assets the moment a new vulnerability is disclosed.
What Are the Penalties for Non-Compliance?
- Up to €15 million or 2.5% of worldwide annual turnover for failing to meet core essential cybersecurity requirements, whichever is higher.
- Up to €10 million or 2% of annual turnover for procedural violations such as missing technical documentation or improper CE marking.
- Up to €5 million or 1% of annual turnover for providing incorrect or misleading information to regulators.
What Does CRA Compliance Actually Cost?
This is where it gets real for most companies. Compliance isn't just a legal exercise - it's an engineering, documentation, and operational investment that spans years, not months.
To benchmark the cost, it's useful to look at FedRAMP - the U.S. government's cloud security authorization framework and one of the most rigorous compliance programs in the world. As we explored in our guide to leading FedRAMP advisory and assessment vendors, FedRAMP compliance typically ranges from $500,000 to $2 million or more in initial investment, with annual assessments running $50,000–$150,000 and continuous monitoring adding another $100,000–$400,000 per year.
The CRA operates under a different framework, but the cost parallels are instructive. For the european cyber resilience act, the key cost drivers include:
- Engineering time to redesign products for secure-by-default principles
- SBOM tooling and maintenance across the software supply chain
- Legal and documentation costs for conformity assessments and CE marking
- Ongoing vulnerability monitoring throughout the product's support lifecycle
- Staff training and potential new compliance hires
Companies that wait until late 2027 to begin will face compressed timelines and inflated costs. The earlier you start, the more efficiently you can spread the investment.
How Echo helps you get CRA-Ready
Echo is purpose-built for teams that need to meet rigorous security compliance requirements - without rebuilding their stack from scratch. The same capabilities that accelerate FedRAMP compliance translate directly to CRA obligations.
Clean, hardened base images Echo provides pre-hardened, continuously updated container images and libraries that ship with minimal attack surface and zero known CVEs at the point of delivery. This directly satisfies the CRA's "secure by design and by default" principle, as well as its requirement that products must not be placed on the market with known vulnerabilities.
CVE management with a 7-day SLA The CRA requires organizations to monitor for vulnerabilities and deliver remediations "without delay." Echo commits to a 7-day SLA for patching any newly disclosed CVE affecting its images - well ahead of what the regulation demands. That means your base layer stays clean throughout your product's entire support lifecycle, not just at launch. For a deeper look at how automated patch SLAs reduce enterprise risk, see our dedicated post on the topic.
Audit-ready documentation The CRA requires manufacturers to maintain a technical file that authorities may request at any time during market surveillance or incident investigations. Every Echo image comes with provenance metadata, a verifiable SBOM, and a full history of CVE patches and remediation dates. When auditors come asking, your team has the paper trail ready - not scrambling to reconstruct it.
Here's how Echo's capabilities map directly to CRA obligations:
- Secure by default at launch → Hardened base images with zero known CVEs
- Remediate vulnerabilities without delay → 7-day CVE remediation SLA
- Maintain SBOM → Built-in SBOM generation per image
- Technical documentation for audits → Provenance signing, patch history, and remediation records
For more on how the same foundation applies to the U.S. compliance landscape, see our posts on FedRAMP compliance and container security and automating FedRAMP container scanning.
FAQ
What products are covered by the Cyber Resilience Act? The CRA applies to any hardware or software product with a "digital element" placed on the EU market - meaning it connects directly or indirectly to a device or network. This covers consumer electronics, IoT devices, software applications, operating systems, and cloud-connected components. Exceptions exist for products already governed by sector-specific legislation, such as medical devices, vehicles, and aviation equipment. If your product touches a network and ships to EU customers, assume you're in scope.
When do CRA obligations actually kick in for my company? The first hard deadline is September 11, 2026, when mandatory vulnerability reporting and severe incident notification requirements go live. Full compliance with all CRA requirements - including CE marking, technical documentation, and conformity assessments - is required by December 11, 2027. Organizations with complex product portfolios should begin compliance programs now, as 18 months is tighter than it sounds when engineering and documentation work is factored in.
What is an SBOM and why does the CRA require one? A Software Bill of Materials (SBOM) is a structured inventory of all software components in a product, including open source libraries and third-party dependencies. The CRA requires manufacturers to maintain an up-to-date SBOM to support vulnerability tracking and supply chain transparency. It enables faster response when a component vulnerability is disclosed - which is central to the CRA's continuous security obligations and its 24-hour reporting window.
How does the CRA relate to other EU cybersecurity regulations like NIS2? The CRA and NIS2 Directive are complementary but distinct. NIS2 focuses on the cybersecurity posture of organizations operating critical infrastructure and essential services. The CRA focuses on the security of the products themselves - regardless of which industry uses them. A company can be subject to both simultaneously, depending on its sector and what it sells. Neither regulation supersedes the other.
What are the penalties for non-compliance with the CRA? Penalties are tiered based on the nature of the infringement. Failing to meet core essential cybersecurity requirements can result in fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. Procedural violations carry fines up to €10 million or 2% of turnover. Providing misleading information to regulators can result in fines of up to €5 million or 1% of turnover.
How does Echo help with CRA compliance? Echo addresses three of the CRA's most operationally demanding requirements. First, Echo's hardened base images ship with zero known CVEs, satisfying the secure-by-default standard at the container layer. Second, Echo's 7-day CVE remediation SLA keeps your base layer well within the CRA's "without delay" obligation throughout the product lifecycle. Third, every Echo image includes a verifiable SBOM, provenance metadata, and a full patch history - giving your team audit-ready documentation from day one, with no additional effort required.



.avif)
.avif)