24-hour reporting deadline under the EU Cyber Resilience Act goes live

Scope: If you make connected PDEs, including hardware, software, or firmware product, that reaches the EU market, you may be a PDE manufacturer. An EU entity is not required.

Two triggers: Reportable events include an actively exploited vulnerability in your product or a severe incident affecting the product’s security. Both run from the moment you become aware .

Fast deadlines: Early warning in 24 hours . Fuller notification in 72 hours . Final report in 14 days after a fix is available (or one month after the 72-hour filing for severe incidents).

Parallel obligations: The Single Reporting Platform (SRP) of the European Union Agency for Cybersecurity (ENISA) delivers to your Computer Security Incident Response Team (CSIRT) designated as coordinator (CDaC) and ENISA at once. Separately, you must tell “impacted users” (and in certain circumstances, all users).

Additional, not substitutive: CRA reporting obligations apply in addition to, and do not replace, any reporting obligations that may arise under the GDPR, NIS2, DORA, or other applicable laws in relation to the same event.

Penalties: Failure to report, late reporting, or incomplete reporting can expose a business to penalties of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher.

As of 11 September 2026, manufacturers of connected products must meet new cybersecurity reporting deadlines under the EU Cyber Resilience Act (CRA).

Manufacturers of products with digital elements (PDEs) made available on the European Union market – including mobile apps, firmware or software embedded in hardware, components such as integrated circuits and sensors, consumer devices and industrial IoT products – must submit an early warning of actively exploited vulnerabilities and severe incidents within 24 hours of becoming aware of them, followed by a more detailed notification within 72 hours. The deadline for the final report differs depending on whether the notification concerns an actively exploited vulnerability or a severe incident.

The CRA can also apply to manufacturers that are not established in the EU where their products are made available on the EU market. Moreover, the same event may trigger reporting obligations under multiple regulatory regimes, including the General Data Protection Regulation (GDPR) and the NIS2 Directive.

The CRA reporting obligations in effect as of 11 September 2026 apply to manufacturers of PDEs made available on the EU market.

A manufacturer is a natural or legal person who develops or manufactures PDEs or has PDEs designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetization or free of charge. Importantly, an importer or distributor that places a PDE on the market under its own name or trademark, or carries out a substantial modification of a product already placed on the market, is considered a manufacturer and assumes, inter alia, the corresponding reporting obligations.

Broadly speaking, PDEs include hardware and software products, the intended purpose or reasonably foreseeable use of which involves a direct or indirect logical or physical data connection to a device or network. The concept also covers remote data processing solutions on which a PDE depends in order to perform one of its functions. By contrast, standalone cloud services that do not constitute such remote data processing solutions generally fall outside the CRA. Certain categories of products that are subject to sector-specific EU regulation are also excluded or subject to specific carve-outs, including certain medical devices and motor vehicles, while products developed or modified exclusively for national security or defence purposes are outside the CRA’s scope.

Under the CRA, two types of incidents trigger the new reporting obligations. A single event may comprise both triggers.

Actively exploited vulnerability: Reliable evidence that a malicious actor has exploited a flaw in a system without the owner’s permission. For example,

the manufacturer’s telemetry system or honeypot ( e.g., a security mechanism used to lure cybercriminals away from legitimate targets) indicates exploitation of a previously unknown vulnerability in the manufacturer’s product, or

a security team monitors dark web forums and finds evidence that hackers have successfully exploited a vulnerability in the manufacturer’s product.

Severe incident: An incident ( i.e. , an event that compromises the availability, authenticity, integrity, or confidentiality of stored, transmitted, or processed data, or of the services offered by, or accessible via, network and information systems) having an impact on the security of the PDE is considered severe when it:

Negatively affects, or is capable of negatively affecting, the PDE’s ability to protect availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or

Has led, or is capable of leading to, the introduction or execution of malicious code in the PDE or in the network and information systems of a user of the PDE.

According to Recital 68 of the CRA, such incidents include situations where a cybersecurity incident affects the manufacturer’s development, production, or maintenance processes in such a way that it could result in an increased cybersecurity risk for users or others (for example, an attacker introduces malicious code into the release channel used to distribute security updates).

The new reporting requirements are triggered as soon as a manufacturer becomes aware of an actively exploited vulnerability or a severe incident. A manufacturer is “aware” once an initial assessment gives it a reasonable degree of certainty that a vulnerability in its product is being exploited, or that a severe incident has compromised the product’s security, according to the Commission’s guidance on the application of the CRA .

This interpretation is consistent with the approach under Commission Implementing Regulation (EU) 2024/2690 for NIS2 ( Recital 31 ) and the European Data Protection Supervisor’s Guidelines 9/2022 on personal data breach notification ( Section II(A) 2 ).

A manufacturer may “become aware” through several channels, including the following:

A customer or partner reports unusual activity and provides reliable evidence of an actively exploited vulnerability in the product, or the manufacturer gathers reliable evidence confirming it.

Threat intelligence from security researchers or cybersecurity firms identifies a zero-day vulnerability in the manufacturer’s product being used in targeted attacks.

A government cybersecurity agency notifies the manufacturer after detecting exploitation through its monitoring systems.

An ethical hacker reports a vulnerability that is already being exploited in the wild, as contemplated by the Commission’s CRA FAQs .

While actively exploited vulnerabilities and severe incidents are subject to the same initial notification deadlines, the deadlines for their final reports differ. For an actively exploited vulnerability, the final report is due within 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month of the 72-hour notification.

A single submission through the SRP reaches a manufacturer’s CDaC and ENISA. What to expect:

Platform access. The SRP is available at . Select “Assigned Representative” (AR) and sign in with an EU Login account.

EU Login. Filers register as ARs using their individual EU Login accounts. There is no company login. An EU Login account can be created in advance at the following link: .

Representatives. A manufacturer can have one primary AR and up to 20 secondary ARs.The primary AR is the main administrative representative for the manufacturer in the SRP and has additional administrative permissions, including managing the manufacturer association and inviting or removing secondary ARs. Secondary ARs have restricted permissions, but can submit and update notifications for the manufacturer.

Registration. Do not preregister with the SRP. ENISA asks manufacturers to register only when they need to file, but you can set up EU Login in advance.

Platform outages: If the SRP is unavailable, ENISA directs users to file once service resumes. Manufacturers can their CSIRT directly if the matter cannot wait, but the notification must still be submitted through the SRP afterward. Keep a record of failed filing attempts.

Language. Submit in English. The platform and ENISA materials are currently available only in English, with other language versions under review for a later phase.

Manufacturers are responsible for identifying the correct CDaC and selecting it in the SRP. Choosing the wrong CDaC may invalidate the notification and require resubmission. Manufacturers should identify and document the correct CDaC before an incident occurs.

After receiving a notification, the CDaC initially receiving a notification disseminates the notification via the SRP to other CSIRTs on the territory of which the manufacturer has indicated that the PDE has been made available. The CDaC also decides, where necessary, on any delays in dissemination and on public disclosure.

In general, manufacturers should report to the CDaC in the EU Member State of their main establishment. Under the CRA, the main establishment is the place where decisions related to the cybersecurity of a manufacturer’s PDEs are predominantly taken. If this cannot be determined, the main establishment shall be considered to be in the Member State where the manufacturer has the highest number of employees in the EU.

Where the manufacturer has no main establishment in the EU , it shall submit the notifications using the electronic notification end-point of the CDaC in the Member States determined pursuant to the following order, based on the information available:

the Member State in which the authorised representative acting on behalf of the manufacturer for the highest number of PDEs of that manufacturer is established;

the Member State in which the importer placing on the market the highest number of PDEs of the manufacturer is established;

the Member State in which the distributor making available on the market the highest number of PDEs of that manufacturer is established;

the Member State in which the highest number of users of PDEs of that manufacturer are located.

Article 14(8) CRA requires the manufacturer to inform impacted users (and in certain circumstances, all users) the vulnerability or incident and the steps they can take. The Commission’s guidance on the application of the CRA confirms that this obligation is risk-based and proportionate.

A single event may trigger several reporting regimes, each with its own scope and analysis. The CRA focuses on the manufacturer and its product. NIS2 focuses on an in-scope entity and its services (for more information, see M c Dermott Will & Schulte’s NIS2 Monitoring Tracker ). GDPR focuses on personal data.

Because the awareness standard is shared, a single record of what the manufacturer knew, and when, can support the separate GDPR, NIS2, and CRA analyses.

The analyses outcomes may differ, however. An event affecting internal IT systems with no product nexus is not a CRA event. An exploited vulnerability in a shipped product may require a CRA filing without qualifying as a significant incident for the manufacturer’s services. And neither the NIS2 nor the CRA analysis determines whether personal data is affected and the GDPR implicated.

As a result, manufacturers should not assume that an existing breach-response or NIS2 playbook covers the CRA. The CRA analysis should be a separate decision point, with a clear owner within the organization.

Failure to report, late reporting, or incomplete reporting falls within the CRA’s highest penalty tier: up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2) CRA).

Member States set and impose the actual fines. These amounts are ceilings, and Article 64(5) requires authorities to consider factors such as the infringement’s gravity and duration and the size of the business.

Complete product and component mapping, including legacy products on the market.

Identify and document your CDaC.

Integrate CRA reporting into your incident response plan. Define who determines when awareness has been reached, the evidence required, and how the decision will be documented.

Identify legal, security, communications, and product owners, and build a 24/7 escalation matrix.

Align CRA templates with NIS2 and GDPR reporting where practical so teams can work from a shared fact base.

Review past incidents and vulnerabilities to assess whether they qualify as actively exploited vulnerabilities or severe incidents.

Train incident response, customer support, and product security teams on the CRA criteria and awareness threshold.

Draft 24-hour, 72-hour, and final-report templates for actively exploited vulnerabilities and severe incidents, including the key information fields.

Draft a user notification template in plain language and, where appropriate, in a structured, machine-readable format.

Dr. Natallia Karniyevich