EU Cyber Resilience Act Countdown: 11 September 2026 Incident/Vulnerability Reporting Deadline Less Than 100 Days Away

I. Overview

The EU Cyber Resilience Act (CRA) is an EU product cybersecurity law for connected products (formally, “products with digital elements” under the CRA) commercialized in the EU; it entered into force on 10 December 2024, with direct application across the EU. Full application begins 11 December 2027, but one of its most operationally demanding provisions takes effect in just under 100 days, on 11 September 2026: the mandatory vulnerability and incident reporting under Article 14 CRA.

II. What Is the EU Cyber Resilience Act?

The CRA is the most comprehensive and far-reaching mandatory product cybersecurity framework globally and the first horizontal EU-wide law to impose binding cybersecurity requirements across virtually all categories of connected products placed on the EU market, and throughout a product’s lifecycle (from development all the way through to product decommissioning).

The EU’s decision to enact the CRA was driven by a recognition that the rapid proliferation of connected products — from consumer smart devices to critical industrial equipment — had created a vast and largely unregulated attack surface across the European single market. Prior to the CRA, there was no consistent, horizontal EU-wide framework governing the cybersecurity of products with digital elements; manufacturers faced a patchwork of voluntary standards and sector-specific rules, creating significant disparities in security levels and enabling a “race to the bottom” in which products were routinely placed on the market with known vulnerabilities, without security updates, and with little transparency for consumers or business users. The CRA is considered one of the EU’s most critical pieces of cybersecurity legislation.

The CRA is complemented by various EU implementing acts and guidance. On 3 March 2026, the European Commission published its first substantive CRA interpretative guidance. While not yet formally adopted, the draft provides the most authoritative current guidance on a range of key CRA questions.

III. Who Is in Scope of the EU CRA?

In addition to importers and distributors, the CRA applies to any “manufacturer” of connected products based inside or outside the EU who markets their products in the EU. Essentially, this means that the CRA applies to:

• Manufacturers, importers, and distributors of connected hardware who sell, make available, distribute, or import such hardware in the EU.
• Developers, importers, and distributors of connected software who sell, license, make available for download, import, or distribute connected software in the EU.
• Providers of remote data processing solutions (i.e., services that support these connected products such as cloud services).

In turn, non-EU manufacturers selling into the EU market from outside the EU are equally fully subject to the regulation, including Article 14 reporting.

For the CRA to apply, the hardware or software product must have the ability or intended purpose of directly or indirectly connecting to an (internal or external) network or another device.

Examples include:

• Consumer IoT devices (smart home products, wearables, connected appliances)
• Industrial software, control systems, and operational technology
• Network equipment and routers
• Operating systems and virtualisation software
• Standalone and embedded browsers
• Mobile applications
• Password managers, firewalls, and VPNs
• Remote access tools and identity management software
• Microprocessors and -controllers
• Certain smart home devices, e.g., smart door locks, baby monitoring systems, alarm systems, general-purpose virtual assistants
• Connected children’s toys
• Supply chain management and logistics platforms with connected components (e.g., tracking, warehouse management, fleet telematics)
• Smart meter gateways and smartcards
• Personal wearables that have a health monitoring purpose (e.g., smartwatches) or are intended to be used by children

Some products are explicitly scoped out of the CRA, including:

• Products already regulated by sector-specific EU legislation that impose cybersecurity requirements — for instance, products licensed in the EU as a medical device or in-vitro diagnostic medical device, civil aviation equipment, motor vehicle, or marine equipment.
• Products developed exclusively for national security or defence purposes, or products designed specifically to process classified information. These products are subject to national (EU Member State) cybersecurity requirements (and the EU encourages the Member States to impose requirements at least as stringent as those under the CRA). Note that dual-use products, however, will be in scope of the CRA.
• Open-source software (OSS) that is not supplied in the course of a commercial activity. Note that as soon as the OSS is integrated into a product and that product is supplied commercially, the manufacturer of that product must carry out appropriate due diligence on the OSS. Contributing to OSS activities and then commercializing them through licenses or integrated components also likely brings those OSS in scope of the CRA.
• Software-as-a-Service (SaaS) and cloud-delivered products, as opposed to on-prem software, are not in scope of the CRA. There had been debate in industry as to whether SaaS software would fall in scope of the CRA, but the Commission’s March 2026 draft guidance now explicitly confirms (standalone) SaaS is out of scope. Cloud services and products would only be in scope where the cloud or SaaS component qualifies as a “remote data processing solution” (RDPS) within the meaning of the CRA, i.e.: (i) the RDPS processes data at a distance; (ii) the product is unable to fulfil a core function without such RDPS; and (iii) it was designed by or under responsibility of the same manufacturer that designed the product supported by the RDPS. Only components that satisfy all three legs fall within scope as an RDPS. Note, even where SaaS are not in scope of the CRA, the provision of SaaS in the EU can trigger application of the EU NIS2 Directive in relation to the organization.
• OEM products, meaning products developed for and on behalf of another organization, are only in scope of the CRA in relation to the manufacturer that commercializes the product in the EU under its own name or trademark —­ not in relation to the OEM developer of the product.

IV. What Is the Risk?

Noncompliance with the CRA carries significant and multi-dimensional risk for companies (inside and outside the EU, including the U.S.) operating in the EU market.

Regulatory enforcement (e.g., fines): The CRA establishes a tiered administrative fine structure enforced by national market surveillance authorities:

• Violations of the essential cybersecurity requirements (e.g., vulnerability handling, support period, mandatory patching) and of the incident/vulnerability reporting requirements: fines of up to €15 million or 2.5% of global annual worldwide turnover, whichever is higher.
• Violations of other CRA obligations (e.g., conformity assessment, technical documentation, authorized representative requirements): fines of up to €10 million or 2% of global annual worldwide turnover.
• Providing incorrect, incomplete, or misleading information to authorities: fines of up to €5 million or 1% of global annual worldwide turnover.

Product recalls and other market surveillance measures: Beyond fines, market surveillance authorities have the power to require corrective action, restrict or prohibit the sale of noncompliant products, and order product withdrawals or recalls from the EU market — a particularly disruptive outcome for companies with significant EU sales operations.

Product safety and security risk – civil liability risk: The CRA’s requirements are not merely procedural. Failure to build in security by design, patch known vulnerabilities, or maintain a minimum support period creates real-world exposure: products that are insecure or unsupported become vectors for cyberattacks, data breaches, and physical harm — particularly in the case of connected industrial, health care, or infrastructure devices. Regulators and courts are increasingly willing to attribute liability for harm caused by inadequately secured products, and the CRA creates a clear regulatory baseline against which such assessments will be made.

Reputational risk and customer trust: In a market where (enterprise) buyers, consumers, and public procurement bodies are increasingly cyber-aware, CRA noncompliance — or even a publicized enforcement action — can have lasting reputational consequences. Already, public and private buyers are increasingly expecting software and hardware providers in the EU to provide contractual assurances in relation to product CRA compliance. Once the 11 December 2027 deadline has passed and manufacturers are required to CE mark their CRA compliant products, the CE-marking under the CRA will function as a visible signal of security trustworthiness.

The reality is that in-scope companies that fail to comply with the CRA and are not able to provide the necessary assurances will no longer be able to offer their products on the EU market after 11 December 2027 — not only due to the regulatory risk of noncompliance, but because their customers will either (i) expect CRA compliant products, and/or (ii) be required to work with manufacturers who provide CRA compliant products (e.g., under the EU NIS2 Directive).

V. What Becomes Mandatory on 11 September 2026?

Article 14 of the CRA imposes a two-track mandatory reporting regime on manufacturers of products with digital elements:

Track 1: Actively Exploited Vulnerabilities

A manufacturer that becomes aware that any vulnerability contained in its product is being actively exploited must notify the EU Agency for Cybersecurity (ENISA) and the relevant EU Member State Computer Security Incident Response Team (CSIRT) within 24 hours of becoming aware. A follow-up report providing a more detailed assessment of the vulnerability must be submitted within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available.

Track 2: Severe Security Incidents

A manufacturer that becomes aware of a severe incident having an impact on the security of its product must similarly notify ENISA within 24 hours, followed by a detailed incident report within 72 hours and a final report within one month after the submission of the 72-hour incident notification report.

For both Tracks 1 and 2, manufacturers must file notifications through the ENISA Single Reporting Platform (SRP) – which is a centralised system enabling simultaneous notification to ENISA and the relevant national CSIRT. The platform is scheduled to be operational by 11 September 2026, with a testing period before that date. As of early June 2026, ENISA has stated it will provide registration instructions, training materials, and dry-run support during June 2026, but the SRP has not yet been formally set up. Companies should actively monitor the ENISA SRP page and the Commission’s CRA reporting page for updates.

Track 3: User Notifications

Manufacturers must also notify affected users — and where appropriate all users — of the vulnerability or incident and any corrective measures they can take, without undue delay. If they fail to do so, the CSIRT can step in and notify users directly, something manufacturers should be aware of.

Track 4: Component (Upstream) Notifications

When a manufacturer discovers a vulnerability in a third-party component integrated into its product, it must notify the component’s manufacturer or maintainer — i.e., this is an upstream notification obligation.

The practical implications are significant. Many manufacturers rely on numerous third-party libraries, firmware modules, and software dependencies. Without systematic processes for tracking components, clear and systematic Software Bills of Materials (SBOM) identifying vulnerabilities, and routing notifications, upstream notifications become challenging.

Track 5: Customer Notifications

The CRA itself does not require manufacturers to notify corporate (B2B) customers (unless that customer also acts as the product’s user within the meaning of the CRA) when a vulnerability or incident arises. However, manufacturers are advised to review customer agreements as customers increasingly impose vulnerability and incident reporting through contract.

VI. Key Practical and Operational Considerations Related to Vulnerability and Incident Reporting

The Meaning of “"Awareness"” and Awareness Defences

A critical operational question is when the 24-hour clock starts. The Commission’s March 2026 draft guidance confirms that a manufacturer is deemed to be “aware” when it has a reasonable degree of certainty that (i) a vulnerability in its product is being actively exploited; or (ii) a severe incident has occurred that led to the security of its product being compromised. Although this depends on the circumstances of each case, often such reasonable degree of certainty can only be reached after an initial assessment (meaning manufacturers can hold off notifying until such initial assessment is complete). However, an ongoing investigation with the aim of achieving full forensic confirmation or certainty that a vulnerability is being actively exploited is in principle no defence for missing the deadline.

To ensure timely detection of vulnerabilities and incidents, manufacturers should do a critical review of their security scanning tools and procedures to ensure they capture, at least, (i) a regular review of public vulnerability databases (including the European Vulnerability Database), (ii) the implementation of a fully functioning Coordinated Vulnerability Disclosure (CVD) policy and procedure (to allow external parties, such as researchers, to notify  the manufacturer of vulnerabilities); (iii) up-to-date SBOMs that map components and dependencies and (iv) state-of-the-art continuous, or at least regular, vulnerability scanning of the manufacturer’s products (through automated scanning tools, where possible). 

Our team helps manufacturers design the monitoring, escalation, and decision-making workflows needed to meet reporting windows across the CRA, GDPR, NIS2, and other applicable cyber laws.

a. Know Who and What You Are Reporting Into

All Article 14 notifications flow through the ENISA Single Reporting Platform, a centralised online platform that routes to both ENISA and the relevant national CSIRT coordinator simultaneously. Manufacturers select the coordinating CSIRT at the point of filing; that CSIRT then disseminates the notification to other Member States where the product is available. There is no API at this stage. Submissions are manual through the SRP, an online platform. This means qualified personnel must be ready to log in and populate forms on short notice. For manufacturers with large product portfolios or high vulnerability volumes, this could become a serious operational constraint or bottleneck. Organisations should build this reality into their incident response plans and on-call structures.

Further, organizations should be mindful of the information they have to provide when reporting, and which may, directly or indirectly, reveal confidential business information or details the manufacturer is not ready to share, such as product architecture and design details, affected components and dependencies, the scope of impact on users and deployed products, and any corrective or mitigating measures still under development.

We assist clients in designing reporting workflows and governance structures that work under these constraints.

b. Confidentiality of Reports: What Happens After You File

Filing a report does not make a vulnerability public. Reports are handled within a trusted network of cybersecurity authorities — public disclosure is ordinarily withheld until a patch is available. Delaying vulnerability information dissemination is an important consideration from a security perspective because sharing such information before a patch or remediation is available opens the door for malicious actors to exploit an unpatched vulnerability. If vulnerability details reach threat actors before a patch has been developed and deployed, the disclosure itself can expand the attack surface.

c. Do I Need to Report Vulnerabilities and Incidents in Legacy Products?

Yes, as long as they are still on the EU market on or after 11 September 2026 and they are still under active mandatory support (per the CRA support period standards). A product that is still in use by (certain) customers but already decommissioned by the manufacturer and no longer under active support is not subject to mandatory reporting.

VII. What You Can Do to Prepare 

1. Conduct a Product Inventory and Scoping Assessment

Map all products your organisation commercializes, imports, or distributes in the EU that could qualify as connected products within the meaning of the CRA. Assess (i) which products connect to networks or other devices, (ii) which products are subject to a potential exemption (e.g. SaaS, medical device), and (iii) what the organisation’s position under the CRA is (e.g., manufacturer, OEM developer, distributor, importer).

CRA requirements vary depending on the position of the economic actor. Further, the CRA imposes obligations in line with a risk-based approach; therefore, it is key to assess cyber risk related to each product in these assessments. Similar to the GDPR, due documentation and legal assessment is key in light of compliance and in case a position is ever challenged.

2. Build or Update Your Vulnerability and Incident Detection and Monitoring Capabilities

The 24-hour reporting clock starts the moment you “become aware” of an actively exploited vulnerability or severe incident with impact on your product’s security. This means you need continuous (or at least regular) monitoring of your products after they have been made available on the EU market (and prior, to ensure products are not sold with known exploitable vulnerabilities), threat intelligence feeds, vulnerability databases, functioning CVD programs, and internal escalation processes that are equipped to meet the strict 24-hour notification window.

With the reporting requirement deadline being less than 100 days away, it is time to act now.

3. Review Contractual Arrangements Across the Supply Chain

The CRA’s obligations fall on the manufacturer, but manufacturers are frequently dependent on component suppliers and software vendors for vulnerability intelligence. Review existing supply chain contracts to ensure upstream vendors are contractually required to notify you of known vulnerabilities and actively exploited weaknesses in components incorporated into your products. Without such clauses, you may not receive the information you need to comply with Article 14 in time.

4. Update Your Incident Response Plan

Your existing incident response plan was almost certainly not drafted with Article 14 of the CRA in mind. Review and update it to integrate the CRA reporting workflows and timelines, ideally alongside parallel obligations under the EU NIS2, GDPR, or sector-specific reporting regimes, as well as ex-EU cyber laws your organisation may be subject to, such as in the U.S. and UK.

5. Train Your Security and Legal Teams

The CRA’s technical reporting triggers and legal compliance obligations require coordination between cybersecurity, infosec, product, legal, and communications teams. Ensure all relevant personnel understand the reporting thresholds and who has authority to make the notification decision. All personnel should also have a basic understanding of the cybersecurity obligations that fall on the organisation.

VIII. How We Can Help

Crowell & Moring’s team consists of cybersecurity, data, product safety, and contract lawyers and leverages that cross-disciplinary bench to advise both hardware manufacturers and software developers on CRA compliance across sectors including consumer products, industrial technology, semiconductors, health care technology, and financial services infrastructure.

We assist clients with CRA compliance throughout a product’s lifecycle, including:

• Scoping and product classification assessments.
• CRA readiness statements (both customer- and regulator-facing).
• Preparing and updating incident response and vulnerability management plans (under the CRA and other applicable legal cyber frameworks).
• Incident and vulnerability response (including global and cross-border).
• Regulatory engagement.
• Customer and vendor contract reviews and negotiation.
• Multi-jurisdictional coordination and alignment of incident reporting strategy with overlapping or conflicting requirements e.g. under EU NIS2, GDPR, and sector-specific regimes.
• Litigation and dispute resolution.