Get Ready: Reporting FAQs and Checklist as the EU’s Cyber Resilience Act Comes Into Force

Executive Summary

• What’s new: On 11 September 2026, the first part of the EU’s Cyber Resilience Act will come into force, imposing new vulnerability and incident reporting obligations on manufacturers of connected software and hardware products.
• Why it matters: To date, companies’ approaches to vulnerability disclosure have mainly been driven by voluntary intelligence-sharing efforts rather than by hard legal obligations. The Cyber Resilience Act’s reporting obligations introduce hard legal requirements to disclose vulnerabilities to EU regulators and may increase pressure on companies to fix those vulnerabilities and disclose them to other governments, customers and cybersecurity information-sharing networks.
• What to do next: Companies should consider identifying regulated products and updating vulnerability management and incident response plans, among other priorities outlined in this client alert.

__________

On 11 September 2026, the first part of the European Union’s Cyber Resilience Act (CRA) will come into force, imposing new vulnerability and incident reporting obligations on manufacturers of connected products. The remaining CRA obligations, including those relating to cybersecurity conformity assessments for new products, will apply starting December 11 2027.

Ahead of the reporting obligation deadline, we have set out below a brief overview of the obligations and a checklist of key items to focus on based on our experience advising on CRA preparedness programs.

Who Is Subject to the CRA’s Reporting Obligations?

The CRA’s reporting obligations apply to manufacturers of “products with digital elements” (PDEs), regardless of when those PDEs were first released.

PDEs include:

• Connected software and hardware (e.g., mobile apps and internet-of-things devices) made available in the EU, including for free.
• Back-end or cloud services that are necessary for those products to perform their functions.

The definition of a PDE is broad, and we have found that it is often a complex process to map CRA-regulated products, including drawing clear boundaries around which back-end systems “support” those products (though recent European Commission guidance helpfully narrows the scope of back-end systems to consider).

In complex supply chains, including intragroup supply chains and white-labelling arrangements, it is often challenging to identify which entity is the CRA-regulated “manufacturer” of a product, so it is important to undertake this analysis before a reportable incident occurs.

What Types of Vulnerabilities and Incidents Need to Be Disclosed?

The CRA requires manufacturers to notify:

1. Government authorities

The manufacturer must notify the relevant EU country’s¹ cybersecurity incident response team (CSIRT) and the EU Agency for Cybersecurity (ENISA) upon becoming aware of either:

• an actively exploited vulnerability contained in its PDEs, or
• a severe incident having an impact on its PDE’s security. An incident is “severe” if it negatively affects the PDE’s ability to protect important data or functions, or leads to the introduction or execution of malicious code.

The relevant EU country’s CSIRT will forward the notification to other EU countries’ CSIRTs and to those countries’ CRA regulators.

This mandatory vulnerability reporting obligation is a novel aspect of the CRA and may require companies to revisit their vulnerability handling processes — in particular, whether vulnerability notifications to EU regulators under the CRA should trigger:

• Notifications to other regulators in the EU (e.g., of the General Data Protection Regulation and the EU’s critical infrastructure cybersecurity law NIS2) and other jurisdictions in relation to the vulnerability.
• Notification to cybersecurity information-sharing bodies, such as sectoral information-sharing and analysis centers.
• Prioritization of efforts to remediate that vulnerability.

2. Customers

Where an actively exploited vulnerability or severe incident affects the PDE’s users, the manufacturer must notify those users and in particular must set out any steps those users can take to mitigate the risks they face (e.g., recommendations to update certain configurations or patch certain systems).

3. Suppliers/Vendors²

If a vulnerability is discovered in a PDE that relates to a third-party component (e.g., an open source software library) used by the PDE, the CRA requires the manufacturer to inform the person maintaining the component about that vulnerability and share any patch to address the vulnerability. 

What Do You Have to Report, and When?

Regulatory notifications take a phased approach, with:

• An initial notification required within 24 hours of becoming aware of the vulnerability or incident.
• A follow-up within 72 hours.
• A final report 14 days after a patch is available (for vulnerabilities) or one month after the incident has occurred (for severe incidents).

Regulatory notifications are filed through a form on ENISA’s newly created Single Reporting Platform, whose form requires information such as the product type, product category and an overview of the vulnerability or incident. A full list of reporting form fields is set out in Annex 1.

Unlike regulatory notifications, notifications to customers and suppliers do not have a strict deadline or require a specific format.

Will Notifications to Regulators Be Made Public?

Usually not. However, CSIRTs can notify affected users if a PDE manufacturer has not notified them about an exploited vulnerability “in a timely manner” or if “public awareness is necessary to prevent or mitigate a severe incident.”

Do I Need to Fix the Vulnerabilities I Report?

The CRA’s incident reporting obligation doesn’t strictly require that any reported vulnerabilities be fixed. However, the fact that an actively exploited vulnerability has been notified to European regulators and, potentially, customers, will increase the pressure manufacturers feel to address those vulnerabilities.

The additional CRA obligations that come into force in December 2027 will include vulnerability handling obligations that require security risks to be addressed through security updates during their support period.

What Should I Be Doing Now?

With the September deadline approaching, companies should consider the readiness steps outlined above and, in particular, may want to:

• Identify and inventory your PDEs. Determine the CRA-regulated manufacturer for each PDE and the EU member state in which that entity has its “main establishment” for CRA reporting purposes.
• Establish your reporting team and escalation process. Identify the individuals responsible for assessing and submitting CRA reports, designate appropriate backups to ensure coverage, and establish clear internal escalation and decision-making responsibilities.
• Prepare for the reporting mechanics. Register the necessary EU account(s) for CRA reporting and be prepared to complete any additional registration required to access and use the Single Reporting Platform once available.
• Update relevant policies and procedures. Review vulnerability management, vulnerability disclosure and incident response policies and procedures in order to both incorporate the CRA reporting requirements and enable potentially reportable matters to be identified, escalated and assessed within the applicable reporting timelines, including the initial 24-hour reporting window.
• Test your readiness. Conduct tabletop exercises to stress-test your ability to identify potentially reportable events, gather the necessary information, reach the appropriate decision-makers and submit required reports within the CRA’s compressed timelines.

Annex 1: CRA Notification Form Fields

Field	First Notification (24 hours)	Second Notification (72 hours)	Final Notification (14 days for incidents or one month for vulnerabilities)
Exploited Vulnerability Reports and Severe Incident Reports
Notification type (vulnerability/incident)	Yes	Yes	Yes
Notification type (24h/72h/final)	Yes	Yes	Yes
Date/time of notification	Yes (automatic)	Yes (automatic)	Yes (automatic)
Reporter	Yes (automatic)	Yes (automatic)	Yes (automatic)
Name of manufacturer	Yes	Yes	Yes
Product	Yes	Yes	Yes
Product type (default/important/critical)	Optional	Optional	Optional
Product category	Optional	Optional	Optional
EU countries where product is available	Yes (if known)	Yes (if known)	Yes (if known)
Title	Optional	Optional	Optional
Exploited Vulnerability Reports Only
CVE ID	Optional	Optional	Optional
EUVD ID	Optional	Optional	Optional
General information, in particular: General nature of the vulnerability General nature of the exploit	Optional	Yes	Yes
Corrective or mitigating measures taken	Optional	Yes	Yes
Corrective or mitigating measures that users can take	Optional	Yes	Yes
Considered sensitivity of information	Optional	Yes (if known)	Yes (if known)
Date when corrective or mitigating measure was made available	Optional	Optional	Yes
Full description of the vulnerability, including: Its severity Its impact	Optional	Optional	Yes
Malicious actor that has exploited/is exploiting the vulnerability	Optional	Optional	Yes (if known)
Details about the security update/corrective measures available	Optional	Optional	Yes (if known)
Serious Incident Reports Only
Incident is suspected by unlawful or malicious acts	Yes	Yes	Yes
General information about the nature of the incident	Optional	Yes	Yes
Date and time when the incident was detected	Optional	Yes	Yes
Date and time when the incident occurred	Optional	Yes	Yes
Initial assessment of the incident	Optional	Yes	Yes
Corrective or mitigating measures taken	Optional	Yes	Yes
Corrective or mitigating measures that users can take	Optional	Yes	Yes
Considered sensitivity of information	Optional	Yes (if known)	Yes (if known)
Detailed description of incident, including: Assessment of severe incident reporting triggers Impact of the incident	Optional	Optional	Yes
Type of threat or root cause that is likely to have triggered the incident	Optional	Optional	Yes
Applied and ongoing mitigation measures	Optional	Optional	Yes

 _______________

1 The relevant EU country is usually the country in which the PDE manufacturer’s “main establishment” is located — i.e., the EU country where the PDE manufacturer makes most of its cybersecurity decisions or has the most employees.

2 This obligation, unlike the other obligations described in this checklist, comes into force in December 2027.

This memorandum is provided by Skadden, Arps, Slate, Meagher & Flom LLP and its affiliates for educational and informational purposes only and is not intended and should not be construed as legal advice. This memorandum is considered advertising under applicable state laws.