Since 11 September 2026, manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities and severe incidents under Article 14 of the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847). The duty applies more than a year before the rest of the Regulation and covers products already on the market. This guide sets out what to report, when, to whom and how, with the clarifications published by the European Commission and a readiness checklist. For the CRA as a whole, see our overview of the Cyber Resilience Act obligations for manufacturers.
In brief
- Article 14 applies from 11 September 2026; the rest of the CRA applies from 11 December 2027 (art. 71(2)).
- Two events trigger a mandatory report: an actively exploited vulnerability in your product, and a severe incident having an impact on the security of your product.
- Each report has three stages: an early warning within 24 hours, a notification within 72 hours and a final report, due 14 days after a fix is available for a vulnerability and one month after the 72-hour notification for an incident.
- One submission on ENISA's single reporting platform reaches the CSIRT designated as coordinator of your main establishment and ENISA at the same time. For a main establishment in Italy, that CSIRT is CSIRT Italia.
- The duty covers products placed on the market before 11 December 2027, including products whose support period has ended.
- Breaches of Article 14 can carry fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.
What must be reported: actively exploited vulnerabilities and severe incidents
Article 14 does not ask manufacturers to report every vulnerability. It names two events, both defined in the Regulation (art. 14(1) and (3)).
Actively exploited vulnerability
A vulnerability "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" (art. 3(42)). The test is evidence of malicious exploitation, not a severity score. The Commission gives two examples of what does not qualify: a zero-day reported through a bug bounty programme with no evidence of earlier malicious exploitation, and one found by a laboratory testing the product on the manufacturer's behalf (Commission FAQs on the CRA, section 5.2). Both can still be reported voluntarily under Article 15.
Severe incident having an impact on the security of the product
An incident is severe when (art. 14(5)):
- it negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or
- it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user of the product.
When the clock starts
Every deadline runs from the moment the manufacturer becomes aware. According to the Commission, that is when, after an initial assessment of a suspicious event, the manufacturer has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident has compromised the security of the product. The initial assessment has to be prompt (Commission guidance on the CRA, C(2026) 5252, section 9.1).
Timelines
| Stage | Actively exploited vulnerability (art. 14(2)) | Severe incident (art. 14(4)) |
|---|---|---|
| Early warning | Within 24 hours of becoming aware. Indicates, where applicable, the Member States where the product has been made available. | Within 24 hours of becoming aware. States at least whether the incident is suspected of being caused by unlawful or malicious acts, and the Member States where the product has been made available. |
| Notification | Within 72 hours of becoming aware: general information on the product, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken and those users can take, and how sensitive the information is. | Within 72 hours of becoming aware: the nature of the incident, an initial assessment, corrective or mitigating measures taken and those users can take, and how sensitive the information is. |
| Final report | No later than 14 days after a corrective or mitigating measure is available: description, severity and impact; the malicious actor, where available; details of the security update or other corrective measures. | Within one month after the 72-hour notification: detailed description, severity and impact; type of threat or root cause; mitigation measures applied and ongoing. |
Three details matter when you plan the process:
- The two final reports start from different moments: for a vulnerability, when a fix or mitigation becomes available; for an incident, when the 72-hour notification is submitted.
- The notification and the final report are due "unless the relevant information has already been provided" in an earlier stage.
- The CSIRT that first receives the notification may ask for an intermediate report on relevant status updates (art. 14(6)).
Where to report: the single reporting platform and the coordinating CSIRT
Notifications go through the single reporting platform that ENISA established and runs (art. 16). The manufacturer submits once, using the electronic notification end-point of the CSIRT designated as coordinator of the Member State where it has its main establishment, and the notification is simultaneously accessible to ENISA (art. 14(7)). That CSIRT then passes it on to the CSIRTs of the other Member States where the product is available; it can delay this only in exceptional circumstances and on justified cybersecurity grounds.
Which CSIRT
The main establishment is in the Member State where the decisions on the cybersecurity of the products are predominantly taken. If that cannot be determined, it is where the manufacturer has the establishment with the most employees in the EU. A manufacturer with no main establishment in the EU follows a fixed order: the Member State of the authorised representative, then of the importer, then of the distributor handling the most of its products, and finally the one where most of its users are located.
In Italy, D.Lgs. 138/2024 designates CSIRT Italia as coordinator under Article 12 of the NIS 2 Directive (D.Lgs. 138/2024, art. 16), and the CRA defines its coordinating CSIRT by reference to that same article (art. 3(51)). So for a manufacturer whose main establishment is in Italy, the recipient is CSIRT Italia, the body that also receives NIS 2 incident notifications. ENISA warns that a notification sent to the wrong CSIRT may be invalidated and have to be resubmitted (ENISA, SRP FAQ no. 18). The list of CSIRTs designated as coordinators is on ENISA's single reporting platform page.
The platform
ENISA launched the platform on 11 September 2026 in a first version, which it calls the "initial operating capability", and will extend its functions in the coming months (ENISA, 11 September 2026). The Commission describes it as operational as of 11 September 2026 (Commission, CRA reporting obligations).
- Notifications are submitted by the manufacturer's Assigned Representatives, each with a personal EU Login account with multi-factor authentication.
- The CSIRT validates the link between representative and manufacturer; notifications can be submitted while validation is pending.
- ENISA advises registering when a notification is needed: with an EU Login account already in place, registration takes a few minutes (SRP FAQ no. 9, updated 3 October 2026).
- As of 8 October 2026, the format of notifications is set by the platform and by ENISA's guides, glossary and user manual. The Regulation allows the Commission to specify it further by implementing acts (art. 14(10)).
CSIRTs designated as coordinators provide helpdesk support on Article 14, in particular to micro, small and medium enterprises (art. 17(6)), and ENISA runs a helpdesk for questions its guides do not answer.
Products already on the market, components and open source
- Products already on the market. Article 14 applies to every in-scope product placed on the market before 11 December 2027 (art. 69(3)). The Commission adds that reporting continues after the support period ends, while the vulnerability handling requirements of Annex I, Part II do not apply to those products (guidance, section 9.1).
- Exploitation known before 11 September 2026. There is no retroactive reporting of active exploitation the manufacturer already knew about before that date. A vulnerability known earlier, but found to be exploited only after 11 September 2026, must be reported (guidance, section 9.1).
- Third-party components. If an actively exploited vulnerability in your product comes from an integrated component, you report it; the component's manufacturer also reports it if the component was placed on the market. A component vulnerability that cannot be exploited, or has not been exploited, in your product is not a mandatory report for you: you still report it to whoever maintains the component (art. 13(6)) and may notify it voluntarily (FAQs, section 5.4).
- Open-source software stewards. Their reporting duties under Article 24(3) apply from 11 December 2027 (Commission, CRA reporting obligations). A manufacturer that integrates open-source components reports from 11 September 2026 like any other manufacturer.
Informing users
Once aware of an actively exploited vulnerability or a severe incident, the manufacturer informs the impacted users, and where appropriate all users. Where necessary, it also tells them the mitigation and corrective measures they can deploy, where appropriate in a structured, machine-readable format (art. 14(8)). If the manufacturer does not inform users in time, the CSIRTs that received the notification may do it themselves.
Informing users does not mean public disclosure. The Commission notes that, for products used in sensitive environments, the details can be limited to the customers concerned, and that broader disclosure may follow once the issue has been addressed (guidance, section 9.1).
Penalties
Non-compliance with Articles 13 and 14 and with the essential cybersecurity requirements of Annex I can carry administrative fines of up to EUR 15,000,000 or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher (art. 64(2)). This is the highest tier in the CRA, above the EUR 10 million or 2% tier that applies to other obligations. The amount takes into account the nature, gravity and duration of the infringement and the size of the operator, with particular regard to micro, small and medium enterprises, start-ups included.
The Regulation provides more favourable treatment for micro and small enterprises that miss only the 24-hour early warning; check its exact scope with the authority (art. 64(10)). Each Member State sets penalties within the Regulation's maxima (art. 64(1)); as of 8 October 2026 the Italian framework is being defined. Notifying does not, by itself, increase the liability of whoever notifies (art. 17(4)).
Readiness checklist
- Name who decides whether an event is an actively exploited vulnerability or a severe incident, and write the criteria of art. 3(42) and art. 14(5) into your triage procedure.
- Record for each case when the initial assessment ended and what it concluded: that moment starts the 24-hour clock.
- Determine your main establishment and its coordinating CSIRT; for a main establishment in Italy, CSIRT Italia.
- Create personal EU Login accounts with multi-factor authentication for at least two people who will act as Assigned Representatives, and read ENISA's user manual and glossary.
- Keep a list of the Member States where each product is made available: the early warning asks for it.
- Keep a component inventory, such as an SBOM, to tell quickly whether an exploited component vulnerability affects your product, and a channel to report it upstream.
- Prepare templates for the three stages and for the notice to users, with a field for the sensitivity of the information.
- Include products already on the market and products out of support in the scope of the procedure.
- Track the date each fix or mitigation becomes available: it starts the 14 days for the final report on a vulnerability.
- Test the procedure on a past case and time each stage. Our guide to the incident management and CSIRT notification plan shows how to structure the document under NIS 2.
If your company is also a NIS entity
CRA reports and NIS 2 notifications are separate obligations. A severe incident affecting your product may also have to be assessed as a significant incident under D.Lgs. 138/2024, with its own pre-notifica, notifica and relazione finale to CSIRT Italia (art. 25). The sequence is explained in our guide to NIS 2 Article 25 incident notification, and entities subject to Law 90/2024 also follow the ACN incident taxonomy.
In the Digital Omnibus (COM(2025) 837), the Commission has proposed a single entry point run by ENISA, possibly built on the CRA platform, under which a manufacturer's CRA report of a severe incident would also count as NIS 2 reporting where it contains the required information. As of 8 October 2026 it is a proposal, not adopted, and the CRA rules are unchanged. For the other EU proposals under discussion, see our analysis of the Cybersecurity Act revision.
If you are also subject to NIS 2, our NIS 2 incident notification service guides you through preparing the significant-incident communications within the NIS 2 deadlines: pre-notification, notification and final report.
