The EU Cyber Resilience Act Enters Its Critical Phase

From Legislation to Enforcement: The CRA Timeline

After years of drafting, negotiation, and political compromise, the European Union’s Cyber Resilience Act (Regulation (EU) 2024/2847) is transitioning from paper to practice. The regulation — which establishes the first comprehensive cybersecurity requirements for all hardware and software products with “digital elements” sold in the EU market — entered into force on December 10, 2024. But 2026 is the year when its most consequential provisions begin to activate.

The CRA operates on a phased implementation timeline designed to give manufacturers and software publishers time to adapt. But the pace of these deadlines has caught many organizations off guard, and the compliance requirements are more demanding than initial readings suggested.

Three critical milestones define 2026 and 2027. On June 11, 2026, the framework for notification of conformity assessment bodies takes effect — meaning EU member states must designate the notifying authorities responsible for assessing, designating, and notifying the bodies that will evaluate product compliance. On September 11, 2026, the obligation for manufacturers to report actively exploited vulnerabilities and severe security incidents takes effect via ENISA’s Single Reporting Platform, introducing tight notification windows that will test organizational readiness. And on December 11, 2027, the main obligations — including full conformity assessment requirements — apply, after which non-compliant products cannot be placed on the EU market.

What the CRA Covers — and Who It Affects

The CRA’s scope is deliberately broad. It applies to “products with digital elements” — defined as any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately. This encompasses everything from consumer IoT devices and operating systems to industrial control systems and enterprise software platforms.

The regulation divides products into three categories based on risk. The default category covers approximately 90% of products and allows manufacturers to self-assess compliance. “Important” products are split into two classes: Class I includes identity management systems, password managers, VPNs, network management tools, routers, and smart home virtual assistants; Class II covers firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors, and operating systems — all requiring third-party conformity assessment or application of harmonized standards. “Critical” products — hardware security modules, smart meter gateways, secure elements, and smartcards — face the most stringent assessment requirements, including mandatory third-party evaluation by notified bodies.

The regulation applies to manufacturers, importers, and distributors, creating obligations throughout the supply chain. Manufacturers bear the primary compliance burden, but importers and distributors must verify that the products they bring to market meet CRA requirements, effectively creating a chain of accountability that extends from the original developer to the point of sale.

Crucially, the CRA applies to any company that places products on the EU market, regardless of where the company is headquartered. This gives the regulation global reach — a software company in the United States, India, or China that sells products to EU customers must comply or withdraw from the market.

The Vulnerability Reporting Mandate

Perhaps the most operationally challenging requirement is the CRA’s mandatory vulnerability and incident reporting regime, which activates on September 11, 2026.

Manufacturers must report actively exploited vulnerabilities to the designated national Computer Security Incident Response Team (CSIRT) and to the European Union Agency for Cybersecurity (ENISA) via a new Single Reporting Platform within aggressive timelines. The reporting structure follows a multi-stage process.

The first stage requires an “early warning” within 24 hours of becoming aware that a vulnerability in a product is being actively exploited. This early warning must include basic information about the vulnerability, the affected product, and the nature of the exploitation. The 24-hour clock starts from awareness, not from confirmation — meaning that organizations cannot delay by conducting extended internal investigation before reporting.

The second stage requires a comprehensive vulnerability notification within 72 hours. This must include a detailed technical assessment of the vulnerability, information about the severity and potential impact, an assessment of whether the exploitation has affected EU users, and preliminary information about mitigation measures.

The third stage requires a final report no later than 14 days after a corrective measure or security update becomes available. This must provide a complete analysis of the vulnerability, the root cause, any observed exploitation patterns, the corrective measures taken, and an assessment of the residual risk.

For severe security incidents — distinct from individual vulnerabilities — a parallel notification regime applies with the same initial 24-hour and 72-hour windows, but the final report deadline extends to one month after the initial notification.

This reporting framework creates several practical challenges. Organizations must have internal processes capable of detecting active exploitation within hours — not days or weeks. They need communication channels with national CSIRTs and ENISA that can be activated rapidly. They must be able to produce technically detailed vulnerability assessments under time pressure. And the reporting obligation applies to all products with digital elements already on the EU market, regardless of when they were placed there.

Conformity Assessment and the Standards Race

The conformity assessment requirements establish the substantive cybersecurity standards that products must meet before they can carry the CE marking and be placed on the EU market. Full compliance is required by December 11, 2027.

At their core, the CRA’s essential requirements mandate that products be designed and developed with security as a default. This includes requirements for secure-by-default configuration, authenticated and authorized access controls, protection of data confidentiality and integrity, minimization of attack surface, and the ability to receive and install security updates.

For the default product category, manufacturers can self-assess compliance by applying harmonized standards — once those standards are published. On February 3, 2025, the European Commission formally requested the three European Standardisation Organisations (CEN, CENELEC, and ETSI) to develop 41 harmonized standards under the CRA: 15 horizontal standards aligned with essential cybersecurity requirements (deadline: August 30, 2026) and 26 vertical standards tailored to specific product categories (deadline: October 30, 2026). The first finalized harmonized standards are expected in Q3 2026, and after citation in the EU Official Journal, manufacturers can use them for conformity assessments to benefit from a presumption of conformity.

Without finalized harmonized standards, manufacturers face uncertainty about exactly how to demonstrate compliance, and the fallback to internal assessment increases both cost and risk.

For “important” and “critical” products, third-party assessment introduces an additional layer of complexity and cost. The availability of qualified notified bodies to conduct these assessments is a bottleneck that the Commission has acknowledged. The June 11, 2026 deadline — when member states must have designated notifying authorities and established procedures for assessing conformity assessment bodies — is the critical precondition for this entire framework to function. Organizations that delay engaging with notified bodies risk finding themselves unable to complete assessments before the December 2027 deadline.

The conformity assessment also requires manufacturers to maintain technical documentation, conduct cybersecurity risk assessments, and establish procedures for handling vulnerabilities throughout the product’s lifecycle — including providing security updates for the expected product lifetime or for a period of five years from placing the product on the market, whichever is shorter. Manufacturers must determine and disclose this “support period” to customers.

Intersection with NIS2 and the Broader Regulatory Landscape

The CRA does not operate in isolation. It is part of a broader EU cybersecurity regulatory architecture that includes the Network and Information Security Directive 2 (NIS2), the Digital Operational Resilience Act (DORA) for the financial sector, and various sectoral regulations for medical devices, automotive, and aviation.

The interaction between CRA and NIS2 is particularly significant. NIS2, which EU member states were required to transpose into national law by October 17, 2024, imposes cybersecurity obligations on “essential” and “important” entities — operators of critical infrastructure, digital service providers, and manufacturing companies above certain size thresholds. However, the transposition process faced significant delays: only four member states met the deadline, and the European Commission opened infringement procedures against 23 member states in November 2024. Organizations subject to both NIS2 and CRA face overlapping but not identical requirements for risk management, incident reporting, and supply chain security.

In January 2026, the European Commission presented a new EU cybersecurity package that includes targeted amendments to the NIS2 Directive alongside a proposed overhaul of the Cybersecurity Act (CSA2). The package aims to simplify compliance across overlapping cybersecurity frameworks, streamline reporting through a single entry point proposed in the Digital Omnibus initiative, and facilitate cross-border supervision with an enhanced coordinating role for ENISA. Under the proposed NIS2-CSA2 alignment, EU cybersecurity certifications could be used to demonstrate compliance with NIS2 risk-management obligations, eliminating duplicative security audits. Both proposals now move into trilogue negotiations with political agreement targeted for early 2027.

The global implications extend beyond the EU. The CRA’s product security requirements are likely to become de facto global standards, as manufacturers find it more efficient to build security into products once rather than maintaining separate EU-compliant and non-compliant product lines. This “Brussels effect” — where EU regulation shapes global market practices — has already been observed with GDPR and is expected to repeat with the CRA.

Compliance Challenges and Industry Response

The transition from CRA legislation to CRA compliance is proving more difficult than many organizations anticipated.

The SBOM Requirement

One of the most discussed requirements is the obligation for manufacturers to produce and maintain a Software Bill of Materials (SBOM) for their products. The SBOM must be in a commonly used, machine-readable format and must identify, at minimum, the top-level dependencies of the product, including version numbers and licensing information. While the CRA does not require manufacturers to make the SBOM publicly available, they must include it in the product’s technical documentation and provide it to market surveillance authorities upon request. For complex software products with hundreds or thousands of dependencies, the practical implementation requires tooling, processes, and expertise that many organizations do not yet have.

Open Source Complications

The CRA’s treatment of open-source software has been a point of contention since the regulation was first proposed. The final text exempts free and open-source software that is not placed on the market in the course of a commercial activity. However, the boundary between commercial and non-commercial activity is defined broadly: providing a software platform through which the manufacturer monetizes other services, charging for technical support, or using personal data for purposes beyond improving the software’s security, compatibility, or interoperability can all constitute commercial activity.

The regulation introduces a new legal category of “open-source software steward” — organizations that systematically provide support on a sustained basis for the development of specific free and open-source software intended for commercial activities and ensure the viability of those software products. Stewards face lighter obligations than commercial manufacturers — they are not subject to administrative fines and their obligations begin in December 2027 — but must still implement cybersecurity policies, cooperate with market surveillance authorities, and participate in vulnerability reporting.

A Linux Foundation research report found that many in the open-source community remain unaware of or uncertain about CRA requirements, raising concerns about preparedness across the broader software supply chain.

Supply Chain Accountability

The CRA’s supply chain provisions require manufacturers to exercise due diligence over third-party components, including open-source libraries. This creates a cascading accountability chain where a vulnerability in a deeply nested dependency can trigger compliance obligations for every product that incorporates it. Managing this accountability requires robust dependency tracking, vulnerability monitoring, and update propagation processes that span organizational boundaries.

Resource and Expertise Gaps

For small and medium-sized enterprises, the CRA’s requirements represent a significant compliance burden. The costs of conformity assessment, SBOM maintenance, vulnerability management, and incident reporting infrastructure may be prohibitive for smaller software companies and hardware manufacturers. The Commission has acknowledged this concern and included provisions for simplified procedures and support measures for SMEs, but the practical effectiveness of these measures remains to be seen.

Preparing for Compliance: A Practical Framework

Organizations that have not yet begun CRA compliance preparation are already behind schedule. A practical approach includes several priorities.

First, conduct a product inventory to identify all products with digital elements that are placed on the EU market, and classify each product by risk category (default, important Class I/II, or critical). Second, perform a gap analysis against the CRA’s essential requirements to identify areas where current product security practices fall short. Third, establish or enhance vulnerability management processes to meet the September 2026 reporting timelines — this means not just technical capability but organizational procedures, designated contacts, and communication templates compatible with ENISA’s Single Reporting Platform. Fourth, invest in SBOM tooling and processes for all relevant products, ensuring machine-readable formats and automated dependency tracking. Fifth, engage with notified bodies early if third-party conformity assessment is required — the December 2027 deadline for full compliance leaves less room than it appears.

The CRA represents the most significant product cybersecurity regulation in history, and its impact will extend far beyond the EU’s borders. Organizations that invest in compliance now will find themselves better positioned — not just for regulatory compliance, but for the market reality that product security is becoming a competitive differentiator and a customer expectation.

Sources & Further Reading

• Regulation (EU) 2024/2847 — Cyber Resilience Act Summary — European Commission
• CRA Reporting Obligations and Single Reporting Platform — ENISA
• EU Cyber Resilience Act: Key 2026 Milestones Toward CRA Compliance — Hogan Lovells
• CRA and Open Source: What Developers Need to Know — Linux Foundation
• European Commission Proposes NIS2 Simplification and Cybersecurity Act 2 — Global Policy Watch
• SBOM Requirements in the EU’s Cyber Resilience Act — FOSSA