EU Cyber Resilience Act: Final Text Analysis and Compliance Roadmap

The European Union's Cyber Resilience Act (CRA) completed its legislative journey in 2024, with the final text published in the Official Journal of the European Union. This regulation establishes mandatory cybersecurity requirements for products with digital elements placed on the EU market, representing the most comprehensive product cybersecurity regulation to date.

For software vendors, hardware manufacturers, and importers selling into the EU market, the CRA is not optional. Understanding its requirements and planning for compliance is now a business necessity.

Scope: What the CRA Covers

The CRA applies to "products with digital elements," which it defines as any software or hardware product and its remote data processing solutions. In practical terms, this covers:

• Commercial software (desktop, mobile, server, cloud-delivered)
• IoT devices and smart products
• Operating systems and firmware
• Hardware products with embedded software
• SaaS solutions where the software component is inseparable from the service

Notable exclusions:

• Open-source software developed outside of a commercial context (with significant caveats, see below)
• Medical devices (covered by the Medical Device Regulation)
• Aviation equipment (covered by existing EU aviation safety regulations)
• Motor vehicles (covered by existing type-approval regulations)
• SaaS and cloud services where the service is the product (covered by NIS2 instead)

The open-source exemption has been carefully scoped. Open-source software that is provided in the course of a commercial activity, for example, an open-source library maintained by a company as part of its product ecosystem, is within scope. The intent is to exclude volunteer-driven community projects while still covering commercially backed open-source.

Key Requirements

Essential Cybersecurity Requirements

Products must meet a set of essential cybersecurity requirements, including:

1. Security by design: Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on the risks.
2. No known exploitable vulnerabilities: Products must be delivered without known exploitable vulnerabilities. This does not mean zero CVEs, it means no vulnerabilities that can be exploited in the product's intended deployment context.
3. Secure default configuration: Products must be delivered with secure default settings. Users should not need to harden the product to achieve basic security.
4. Access control: Products must support access control mechanisms appropriate to their context.
5. Data protection: Confidentiality, integrity, and availability of data must be protected through appropriate mechanisms.
6. Minimized attack surface: Products must minimize their attack surface, disabling unnecessary features by default.
7. Security updates: Manufacturers must provide security updates for the product's expected lifetime, free of charge.

Vulnerability Handling Requirements

Manufacturers must establish and maintain:

• A coordinated vulnerability disclosure policy.
• Processes for identifying and remediating vulnerabilities in a timely manner.
• The ability to distribute security updates to users.
• A contact point for vulnerability reports.
• A mechanism for users to report vulnerabilities.

SBOM Requirements

The CRA requires manufacturers to identify and document components contained in their products, including:

• A machine-readable SBOM identifying at a minimum the top-level dependencies of the product.
• Documentation must cover at least direct dependencies and, where feasible, transitive dependencies.
• SBOMs must be maintained and updated as the product evolves.

The specific SBOM format is not mandated in the regulation itself, but the European Commission is expected to publish implementing guidelines that will likely reference CycloneDX and SPDX as acceptable formats.

Vulnerability Reporting to ENISA

This is one of the CRA's most impactful requirements. Manufacturers must:

• Report actively exploited vulnerabilities to ENISA (European Union Agency for Cybersecurity) within 24 hours of becoming aware.
• Report severe incidents affecting the security of the product within 24 hours.
• Provide follow-up reports within 72 hours with additional details.
• Submit a final report within 14 days.

This reporting timeline is aggressive and will require manufacturers to have mature incident response processes in place.

Product Classification and Conformity Assessment

The CRA establishes categories of products based on their criticality:

Default category (self-assessment): Most products can demonstrate compliance through self-assessment using harmonized standards. This is the least burdensome path and will apply to the majority of software products.

Important products - Class I: Products that perform critical security functions, including identity management, VPNs, network management tools, SIEM systems, and boot managers. These require conformity assessment by an accredited notified body or adherence to harmonized standards.

Important products - Class II: Products with higher criticality, including operating systems, hypervisors, firewalls, hardware security modules, and smart meters. These require third-party conformity assessment.

Critical products: The most critical category, including smart cards, hardware tokens, and secure elements. Third-party assessment is mandatory.

For software companies, most products will fall into the default or Class I categories. The self-assessment path for the default category is manageable, but it still requires documented compliance with all essential requirements.

Timeline and Enforcement

• Publication: Official Journal of the EU, 2024.
• Entry into force: 20 days after publication.
• Vulnerability reporting obligations: Apply from September 2026 (21 months after entry into force).
• Full application of all requirements: December 2027 (36 months after entry into force).

Penalties for non-compliance:

• Up to 15 million EUR or 2.5% of total worldwide annual turnover (whichever is higher) for failure to meet essential cybersecurity requirements.
• Up to 10 million EUR or 2% of turnover for other non-compliance.
• Up to 5 million EUR or 1% of turnover for providing incorrect, incomplete, or misleading information.

Compliance Roadmap

Now - Q2 2025: Assessment and Gap Analysis

1. Determine if your products are in scope. Map your product portfolio against the CRA's scope definitions and categorization criteria.
2. Conduct a gap analysis against the essential cybersecurity requirements. Identify where your current practices fall short.
3. Assess your vulnerability handling maturity. The 24-hour reporting requirement to ENISA demands a well-oiled vulnerability response process.
4. Evaluate your SBOM capabilities. Can you generate accurate, machine-readable SBOMs for all products?

Q3 2025 - Q1 2026: Process Implementation

1. Implement secure development lifecycle practices that align with the CRA's security-by-design requirements.
2. Establish vulnerability handling processes including coordinated disclosure, response, and reporting to ENISA.
3. Deploy SBOM generation as part of your build pipeline, producing SBOMs automatically for every release.
4. Develop conformity documentation including technical documentation, EU declaration of conformity, and supporting evidence.

Q2 2026 - September 2026: Vulnerability Reporting Readiness

1. Establish ENISA reporting workflows and test them. The 24-hour timeline for reporting actively exploited vulnerabilities leaves no room for figuring out the process during an incident.
2. Integrate vulnerability intelligence to ensure you are aware of exploitation of vulnerabilities in your products' dependencies.
3. Conduct tabletop exercises simulating vulnerability disclosure and reporting scenarios.

October 2026 - December 2027: Full Compliance

1. Complete conformity assessment for all products.
2. Apply CE marking where required.
3. Maintain ongoing compliance including continuous SBOM updates, vulnerability monitoring, and security update distribution.

How Safeguard.sh Helps

Safeguard.sh provides the technical foundation for CRA compliance.

• Automated SBOM generation produces machine-readable SBOMs in CycloneDX and SPDX formats, meeting the CRA's documentation requirements with minimal manual effort.
• Vulnerability monitoring and alerting ensures you are aware of vulnerabilities in your products' dependencies, supporting the 24-hour reporting requirement to ENISA.
• Compliance documentation generates the technical evidence needed for conformity assessment, including dependency listings, vulnerability management records, and security update histories.
• Policy enforcement codifies CRA requirements as automated checks, ensuring that products meet essential cybersecurity requirements before release.

The CRA compliance clock is ticking. Organizations that start building capabilities now will be ready when enforcement begins. Those that wait until 2027 will find the deadline impossible to meet.