The Cyber Resilience Act (Regulation (EU) 2024/2847) is the single largest cybersecurity regulation ever enacted for commercial products. It applies to virtually every hardware and software product sold in the EU—an estimated tens of billions of products. Non-compliance penalties reach up to €15 million or 2.5% of global turnover. The vulnerability reporting deadline is September 2026—which means your clock is already ticking.
What Is the Cyber Resilience Act?
The CRA is a European Union regulation that establishes mandatory cybersecurity requirements for all products with digital elements placed on the EU market. Unlike directives (which require national transposition), the CRA is a regulation—it applies directly and uniformly across all 27 EU member states.
"Products with digital elements" is deliberately broad. It covers:
- Standalone software: Operating systems, applications, firmware, mobile apps, desktop software, libraries, SDKs
- Connected hardware: IoT devices, routers, smart home products, industrial controllers, medical devices (unless covered by sector-specific regulation)
- Software components: APIs, microservices, and containerized services that form part of a larger product
- Cloud-connected products: If the product includes remote data processing essential to its functionality, those processing components are in scope
The CRA fills a critical gap: until now, EU cybersecurity regulation focused on organizations (NIS2 Directive) and financial entities (DORA), but left products themselves largely unregulated. The CRA closes that gap by holding manufacturers responsible for the security of what they ship.
Key Timeline: What's Due When
The CRA has a phased implementation schedule. Mark these dates:
The CRA was published in the Official Journal of the EU and entered into force. The clock starts. Organizations should begin gap analysis and planning immediately.
This is the first hard deadline. Manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware. A full vulnerability notification (including technical details and mitigation measures) must follow within 72 hours. This requirement alone demands a mature vulnerability handling process, CSIRT coordination, and clear internal escalation paths.
All products with digital elements placed on the EU market after this date must comply with all CRA requirements: security-by-design, vulnerability handling, SBOM provision, technical documentation, CE marking declaration of conformity, and ongoing security update obligations for the entire support period (minimum 5 years or the expected product lifetime, whichever is shorter).
The Six Essential Requirements
The CRA defines essential cybersecurity requirements in Annex I. Here's what they mean in practice for software organizations:
Security by Design & Default
Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on their risk profile. This means: no known exploitable vulnerabilities at the time of release, secure default configurations (no default passwords, no unnecessary open ports), protection against unauthorized access, and confidentiality and integrity of stored/transmitted data. In practice, this requires threat modeling as a standard part of your SDLC, not an afterthought.
Vulnerability Handling Process
Manufacturers must implement and document a vulnerability handling process that includes:
- A publicly accessible contact point for vulnerability reports
- A coordinated vulnerability disclosure (CVD) policy
- Timely identification, documentation, and remediation of vulnerabilities
- Free security updates distributed without delay
- Regular testing and review of the product's security throughout its lifecycle
- Public disclosure of fixed vulnerabilities, including CVE identifiers and advisories
SBOM — Software Bill of Materials
Every product must include a machine-readable Software Bill of Materials identifying at minimum the top-level dependencies. The SBOM must be maintained and updated throughout the product's support period. This is where organizations with mature software supply chain security practices gain a significant advantage—if you're already generating SBOMs in your CI/CD pipeline, you're halfway there. If not, this is a major build process change.
Security Updates & Support Period
Manufacturers must provide free security updates for the entire support period of the product—at minimum 5 years from the date the product is placed on the market. Security patches must be delivered "without delay" and through a secure update mechanism that prevents unauthorized modification. For organizations building air-gapped or disconnected systems, this means designing an authenticated, integrity-verified offline update path from day one.
Technical Documentation & CE Marking
Before placing a product on the market, manufacturers must prepare comprehensive technical documentation including: a product description, design and development documentation, a risk assessment, a description of how essential requirements are met, the SBOM, the EU declaration of conformity, and evidence of the conformity assessment. The product then receives CE marking—the same marking used for physical product safety, now extended to cybersecurity.
Incident & Vulnerability Reporting to ENISA
When a manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting the security of the product, they must notify the designated CSIRT and ENISA. The reporting timeline mirrors NIS2: early warning within 24 hours, full notification within 72 hours, final report within 14 days. This requires a mature incident response capability and pre-established reporting channels.
Product Classification: Default vs. Important vs. Critical
The CRA classifies products into three categories, each with different conformity assessment requirements:
┌─────────────┬──────────────────────────────────────────┬──────────────────────┐
│ Category │ Examples │ Assessment │
├─────────────┼──────────────────────────────────────────┼──────────────────────┤
│ Default │ Most software products, apps, │ Self-assessment │
│ (~90%) │ games, productivity tools │ (internal) │
├─────────────┼──────────────────────────────────────────┼──────────────────────┤
│ Important │ Identity management, VPNs, firewalls, │ Harmonised standard │
│ Class I │ SIEM, password managers, boot managers, │ or third-party audit │
│ │ microcontrollers, industrial IoT │ │
├─────────────┼──────────────────────────────────────────┼──────────────────────┤
│ Important │ Hypervisors, container runtimes, │ Third-party audit │
│ Class II │ firewalls for industrial use, HSMs, │ (mandatory) │
│ │ tamper-resistant microprocessors, CPUs │ │
├─────────────┼──────────────────────────────────────────┼──────────────────────┤
│ Critical │ Hardware security modules, smart meter │ European │
│ │ gateways, smartcards, secure elements │ cybersecurity │
│ │ │ certification │
└─────────────┴──────────────────────────────────────────┴──────────────────────┘For most software companies, products will fall into the Default category, allowing self-assessment. However, if you build security-critical infrastructure software (VPNs, firewalls, SIEM, identity management, container runtimes), you're in Important Class I or II territory—requiring either conformity with harmonised standards or third-party assessment.
The Open-Source Question
One of the CRA's most debated provisions concerns open-source software. The final regulation includes important clarifications:
- Non-commercial open source is exempt: If you develop and distribute OSS outside of commercial activity, the CRA does not apply to you. Community-driven projects like Linux kernel contributions, Apache Foundation projects, or personal GitHub repos are out of scope.
- Commercial integration triggers CRA: If you take open-source components and integrate them into a commercial product sold in the EU, you (the manufacturer) are responsible for CRA compliance—including the security of the OSS components you consume.
- Open-Source Software Stewards: The CRA creates a new category for organizations that "systematically provide support" for OSS used in commercial products (e.g., foundations that maintain critical libraries). Stewards have lighter obligations— primarily a cybersecurity policy and cooperation with market surveillance authorities.
The practical implication: your SBOM and supply chain security practices are now legally required, not just best practices. Every OSS dependency you ship becomes your regulatory liability.
How the CRA Interacts with NIS2 and DORA
The CRA is the third pillar of the EU's cybersecurity regulatory framework. Understanding how these regulations complement each other is essential:
- CRA — Product Security: Ensures that products with digital elements are secure by design and throughout their lifecycle. Targets manufacturers.
- NIS2 — Organizational Security: Requires essential and important entities to implement cybersecurity risk management measures, incident reporting, and supply chain security. Targets operators of critical infrastructure.
- DORA — Financial Sector ICT Risk: Mandates ICT risk management, incident reporting, digital operational resilience testing, and third-party risk management specifically for financial entities.
If you're a software manufacturer selling to EU financial institutions or critical infrastructure operators, you may need to comply with all three. The products you build must meet CRA requirements. Your organization may be classified as an "important entity" under NIS2. And your financial sector clients will require DORA-compliant ICT risk management evidence from you as a third-party provider.
Preparing Your Organization: A Practical Roadmap
With the vulnerability reporting deadline just months away, here's what software organizations should be doing now:
Phase 1: Assessment (Now)
- Product inventory: Catalog every product you place on the EU market. Classify each as Default, Important (Class I/II), or Critical.
- Gap analysis: Compare your current security practices against the CRA's essential requirements. Where are the gaps?
- OSS audit: Identify all open-source components in your products. Do you have SBOMs? Can you track vulnerabilities in your dependencies?
- Support period review: For each product, can you commit to 5 years of security updates? What's the cost?
Phase 2: Build Capabilities (By September 2026)
- Vulnerability handling: Establish a PSIRT (Product Security Incident Response Team) with defined processes for receiving, triaging, and fixing vulnerabilities.
- CVD policy: Publish a coordinated vulnerability disclosure policy and a
security.txtfile (RFC 9116) on your website. - ENISA reporting: Register with the ENISA single reporting platform and establish internal escalation paths that can meet the 24-hour early warning deadline.
- SBOM automation: Integrate SBOM generation into your CI/CD pipeline using CycloneDX or SPDX format. Every build should produce an updated SBOM automatically.
Phase 3: Full Compliance (By December 2027)
- Security-by-design integration: Embed threat modeling and security testing into every stage of your SDLC.
- Technical documentation: Prepare the full conformity dossier—risk assessment, design documentation, SBOM, test reports, and EU declaration of conformity.
- Conformity assessment: For Default products, complete self-assessment. For Important/Critical products, engage an accredited third-party assessment body.
- CE marking: Apply CE marking to compliant products and maintain the dossier for 10 years after the product is placed on the market.
- Secure update mechanism: Ensure you can deliver authenticated, integrity-verified security updates to all deployed instances—including air-gapped environments.
Penalties and Enforcement
The CRA has teeth. Market surveillance authorities in each EU member state can:
- Order product withdrawal from the EU market
- Require recalls of products already sold
- Prohibit or restrict making a product available on the market
- Impose fines based on the severity of non-compliance:
┌────────────────────────────────────────────┬─────────────────────────┐
│ Violation │ Maximum Fine │
├────────────────────────────────────────────┼─────────────────────────┤
│ Essential cybersecurity requirements │ €15M or 2.5% of global │
│ (Annex I) │ annual turnover │
├────────────────────────────────────────────┼─────────────────────────┤
│ Other CRA obligations │ €10M or 2% of global │
│ │ annual turnover │
├────────────────────────────────────────────┼─────────────────────────┤
│ Incorrect/misleading information to │ €5M or 1% of global │
│ market surveillance authorities │ annual turnover │
└────────────────────────────────────────────┴─────────────────────────┘For SMEs and micro-enterprises, authorities are instructed to consider the economic impact of fines—but the regulation makes no formal exceptions. If you sell in the EU, you comply.
CRA and Defense: Special Considerations
The CRA explicitly excludes products developed for national security, military, or defense purposes. However, defense contractors should pay attention for several reasons:
- Dual-use products: If your product has both civilian and defense variants, the civilian version sold on the EU market is fully subject to the CRA.
- Supply chain ripple: Your commercial suppliers and COTS components must be CRA-compliant. Non-compliant components can't legally be part of your supply chain if they're sold in the EU.
- Best practice alignment: The CRA's requirements closely mirror defense security standards like NIST 800-171 and CMMC 2.0. Organizations already meeting these standards will find significant overlap with CRA requirements.
- Export compliance: Products with CE marking under the CRA may interact with export control regulations—particularly for cryptographic components subject to dual-use export controls.
Frequently Asked Questions
Does the CRA apply to SaaS?
Pure SaaS (fully cloud-hosted with no client-side component) is generally out of scope for the CRA. However, if your SaaS product includes a downloadable client, mobile app, browser extension, or any local component, that component is in scope. Additionally, if remote data processing is essential to a product's core functionality, those processing functions may be considered part of the product.
What about products already on the market before December 2027?
Products placed on the EU market before the compliance deadline are not retroactively subject to the CRA's essential requirements. However, if you substantially modify the product after December 2027 (e.g., a major version update that changes its intended purpose or risk profile), it becomes a "new" product placement subject to full CRA requirements.
How does the CRA affect my CI/CD pipeline?
Significantly. Your pipeline must now produce: machine-readable SBOMs for every release, evidence of security testing (SAST, DAST, SCA), signed build artifacts with integrity verification, and conformity documentation that can be provided to market surveillance authorities on demand. This is effectively mandating what mature DevSecOps practices already look like.
Alterra Solutions' Perspective
At Alterra, we've been building security-by-design into our products long before the CRA mandated it—because our defense and enterprise clients demanded it. Our software includes automated SBOM generation, supply chain integrity verification, and vulnerability handling processes that meet both CRA and defense-grade standards.
If you're preparing for CRA compliance and need help building the technical foundation—SBOM automation, vulnerability handling workflows, secure update mechanisms, or conformity documentation—we can help.