Cyber Resilience Act II: vulnerability handling and reporting since 11-09-2026

The legal framework

The Cyber Resilience Act is Regulation (EU) 2024/2847. Most of it applies from 11 December 2027, but the reporting duty in Article 14 has applied since 11 September 2026 (Article 71(2)). It covers every product with digital elements in scope, including products placed on the market long before 11 December 2027 (Article 69(3)). So the reporting clock already runs for your whole installed base.

Whether your product is caught at all is the subject of part I of this series. This part covers two things: what you report, and how you handle vulnerabilities over the product's life.

Two reporting tracks

Article 14 has two triggers. Each one is reported "simultaneously" to the CSIRT designated as coordinator and to ENISA, the EU cybersecurity agency.

Track 1: an actively exploited vulnerability (Article 14(1) and (2)). That is "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" (Article 3, point (42)). A flaw found in your own testing is not enough. You submit:

• an early warning without undue delay and in any event within 24 hours of becoming aware, naming where applicable the Member States where you know the product has been made available;
• a vulnerability notification within 72 hours, with general information on the product, the nature of the exploit and the vulnerability, the corrective or mitigating measures taken and those users can take, and how sensitive you consider the information;
• a final report no later than 14 days after a corrective or mitigating measure is available, with a description of the vulnerability, its severity and impact, information on the malicious actor where available, and details of the security update or other fix.

Track 2: a severe incident having an impact on the security of the product (Article 14(3) and (4)). An incident is severe when it affects or can affect the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or when it has led or can lead to malicious code in the product or in a user's network and information systems (Article 14(5)). Think of an attacker who compromises your update server. You submit:

• an early warning within 24 hours, stating at least whether the incident is suspected of being caused by unlawful or malicious acts;
• an incident notification within 72 hours, with an initial assessment and the measures taken and available to users;
• a final report within one month after the incident notification, with a detailed description, the type of threat or root cause and the mitigation measures applied and ongoing.

Under both tracks the CSIRT may ask for an intermediate report on status updates (Article 14(6)).

Where you report

All notifications go through the single reporting platform that ENISA establishes and manages (Article 16). You use the electronic end-point of the CSIRT designated as coordinator in the Member State of your main establishment in the Union, and ENISA has access at the same time (Article 14(7)). The main establishment is where the decisions on your products' cybersecurity are predominantly taken. If that cannot be determined, it is the EU establishment with the most employees.

A manufacturer with no EU establishment follows a fixed order: the Member State of the authorised representative acting for most of its products, then of the importer placing most of its products on the market, then of the distributor, then where most of its users are (Article 14(7), third subparagraph).

The receiving CSIRT passes the notification on to the CSIRTs of the Member States where the product is available. That dissemination can be delayed in exceptional circumstances, on justified cybersecurity grounds, for instance when you indicate that the information is sensitive or the vulnerability is in a coordinated disclosure procedure (Article 16(2) and (6)). The CSIRTs also pass on what market surveillance authorities need (Article 16(3)).

Informing users

After becoming aware of an actively exploited vulnerability or a severe incident, you must inform the impacted users, and where appropriate all users, of the problem and of the mitigation measures they can take, where appropriate in a structured, machine-readable format (Article 14(8)). If you do not do so in time, the CSIRTs may inform users themselves. The CSIRT may also inform the public, or require you to do so, after consulting you, where public awareness is necessary (Article 17(2)).

Protection for the reporter

Notifying does not by itself increase your liability (Article 17(4)). Voluntary reports of other vulnerabilities, cyber threats, incidents and near misses are possible for manufacturers and anyone else (Article 15). Once a fix is available, ENISA may add the vulnerability to the European vulnerability database, in agreement with the manufacturer (Article 17(5)). CSIRTs provide helpdesk support on the reporting duties, in particular to small and medium-sized manufacturers (Article 17(6)).

The CRA's administrative fines for missing the 24-hour early warning do not apply to manufacturers that are microenterprises or small enterprises (Article 64(10)). The duty itself still applies to them. For everyone else, a breach of Article 14 can lead to fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)).

Vulnerability handling from 11 December 2027

From 11 December 2027, products may only be made available if the manufacturer's processes meet Annex I, Part II (Article 6). The eight requirements are:

1. identify and document vulnerabilities and components, including a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies;
2. address and remediate vulnerabilities without delay, including through security updates, and where technically feasible ship security updates separately from functionality updates;
3. test and review the product's security effectively and regularly;
4. once an update is available, publicly disclose information about fixed vulnerabilities, with a description, the affected products, impact, severity and remediation help (a delay is possible in duly justified cases until users could patch);
5. put in place and enforce a coordinated vulnerability disclosure policy;
6. facilitate the sharing of information on vulnerabilities, including in third-party components, and provide a contact address for reports;
7. provide mechanisms to distribute updates securely, automatically where applicable for security updates;
8. disseminate security updates without delay and free of charge, with advisory messages, unless agreed otherwise with a business user for a tailor-made product.

Article 13 adds the frame around it:

• vulnerabilities must be handled effectively during the support period, which reflects the time the product is expected to be in use and is at least five years, unless the product is expected to be in use for less (Article 13(8));
• each security update must remain available for at least ten years after it is issued, or for the rest of the support period if longer (Article 13(9));
• a manufacturer that finds a vulnerability in an integrated component, open source included, must report it to whoever makes or maintains that component and remediate it, and share its fix where appropriate (Article 13(6));
• a single point of contact for users, also for reporting vulnerabilities, which may not be limited to automated tools (Article 13(17));
• the end date of the support period, at least month and year, must be clear at the time of purchase (Article 13(19)).

Next to NIS2 and the GDPR

The CRA borrows the 24-hour, 72-hour and one-month rhythm from NIS2. The two can apply to the same company: NIS2 to its own network and services, the CRA to the products it sells. If personal data are compromised, the GDPR adds a third notification to the data protection authority within 72 hours (see the 72-hour rule). Prepare all of them from one set of facts.

In practice

A Belgian maker of building-access controllers learns on a Friday evening from a customer that its readers are being opened with a crafted badge, and the logs confirm it. That is reliable evidence of exploitation. The early warning goes to the CSIRT designated as coordinator in Belgium, as the main establishment, through the single reporting platform by Saturday evening, listing the countries where the readers are sold. By Monday evening the vulnerability notification follows, with the temporary advice to switch to PIN plus badge. The firmware fix ships three weeks later. The final report is due 14 days after that. In the meantime the company informs its installers and customers with the mitigation steps.

A software company finds that its build server was breached and a signed update may have carried malicious code. This is a severe incident affecting product security under Article 14(5)(b). The 24-hour early warning states that a malicious act is suspected. If the company also falls under NIS2, it checks whether the same event is a significant incident for its own services.

A researcher reports a flaw in a smart camera that nobody has exploited. That is not a mandatory notification. The manufacturer handles it under its disclosure policy, fixes it and, from 11 December 2027, publishes an advisory once the update is out. It may report it voluntarily under Article 15.

Practical steps

1. Name an owner for CRA reporting and give that person authority to file at night and on weekends.
2. Determine your main establishment, and so your CSIRT, and learn how its end-point on the platform works.
3. Write a playbook with the two tracks, the deadlines and templates for each report.
4. Set up the single point of contact and publish a coordinated vulnerability disclosure policy now, even if Annex I applies only from 11 December 2027.
5. Generate a software bill of materials for every release.
6. Fix and publish your support periods.

Contracts

Suppliers, integrators and resellers often learn of a problem first. Put in your contracts a duty to inform you without delay of any exploitation or incident affecting your products, with the information you need for the 24-hour warning. Agree how security updates reach end users through distributors. In component purchase agreements, require the maker to tell you about vulnerabilities and fixes, and to support your own reporting.

Frequently asked questions

Does Article 14 apply to products we sold years ago?

Yes, if they are within the CRA's scope. Article 69(3) applies Article 14 to all products placed on the market before 11 December 2027.

When does the 24-hour period start?

When the manufacturer becomes aware of the actively exploited vulnerability or the severe incident (Article 14(2)(a) and (4)(a)). Make sure that knowledge reaches the right person quickly.

We are a small company. Do we have to report?

Yes. Microenterprises and small enterprises cannot be fined for missing the 24-hour early warning (Article 64(10)(a)), but the duty to report, including the 72-hour notification and the final report, still applies.

Does reporting to the CSIRT mean the vulnerability becomes public?

Not automatically. The CSIRT shares it with other CSIRTs and authorities, and dissemination can be delayed on justified grounds. ENISA adds it to the European vulnerability database only after a fix is available and in agreement with you.

How this connects

Our data breach response team runs the notifications under the CRA, NIS2 and the GDPR from one timeline, and the breach workflow keeps every deadline and report in one record. The reporting duties of your suppliers and distributors belong in your contracts; our commercial contracts team drafts them, and the rights and obligations register tracks support periods and notice duties after signature.

At a glance

Provisions cited: Regulation (EU) 2024/2847, Articles 3(42), 6, 13(6), (8), (9), (17) and (19), 14, 15, 16, 17, 64(2) and (10), 69(3) and 71; Annex I, Part II.

Key dates: reporting under Article 14 since 11 September 2026, for all products in scope; vulnerability handling requirements (Annex I, Part II) from 11 December 2027.

The series: part I, products and classes, part III, importers, distributors, open source and contracts and the 2026 cybersecurity package. Related: the NIS2 Directive and the 72-hour rule for personal data breaches.