IN SHORT
The Cyber Resilience Act (CRA) imposes two related sets of duties on manufacturers. First, vulnerability handling: throughout the support period, manufacturers must identify, fix and disclose vulnerabilities following the eight requirements of Annex I, Part II. Second, reporting: from 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents having an impact on the security of their products to the CSIRT designated as coordinator and to ENISA, through a single reporting platform, on a 24-hour / 72-hour / final-report schedule (Article 14). The reporting obligation also covers products already on the market before 11 December 2027 (Article 69(3)).
Two different things: handling and reporting
Vulnerability handling is a continuous process that the manufacturer runs for every product it places on the market. Vulnerability reporting under Article 14 is a narrower, event-driven duty: it is triggered only by an actively exploited vulnerability or a severe incident affecting the security of the product.
Do not confuse either of them with the notification of conformity assessment bodies in Chapter IV of the Regulation, which concerns how bodies are notified to carry out third-party assessments and applies from 11 June 2026 (Article 71(2), second subparagraph). That is a different subject entirely.
Vulnerability handling: the eight requirements of Annex I, Part II
What the text requires
Manufacturers must ensure, when placing a product on the market and for the support period, that its vulnerabilities, including those of its components, are handled effectively and in accordance with Part II of Annex I (Article 13(8), first subparagraph). Annex I, Part II requires them to:
- identify and document vulnerabilities and components, including by drawing up a software bill of materials (Annex I, Part II, point 1);
- address and remediate vulnerabilities without delay, including by providing security updates — where technically feasible, separately from functionality updates (Annex I, Part II, point 2);
- apply effective and regular tests and reviews of the security of the product (Annex I, Part II, point 3);
- once a security update is available, share and publicly disclose information about fixed vulnerabilities, with a possible delay in duly justified cases (Annex I, Part II, point 4);
- put in place and enforce a policy on coordinated vulnerability disclosure (Annex I, Part II, point 5);
- facilitate the sharing of information about potential vulnerabilities, including by providing a contact address for reporting them (Annex I, Part II, point 6);
- provide mechanisms to securely distribute updates, where applicable for security updates in an automatic manner (Annex I, Part II, point 7);
- disseminate available security updates without delay and, unless otherwise agreed with a business user for a tailor-made product, free of charge, with advisory messages (Annex I, Part II, point 8).
Article 13 adds several obligations that shape how this process works in practice:
- Components. Manufacturers must exercise due diligence when integrating third-party components (Article 13(5)). When they identify a vulnerability in an integrated component, including an open-source one, they must report it to the person or entity manufacturing or maintaining the component and remediate it (Article 13(6)).
- Support period. The support period reflects how long the product is expected to be in use; it is at least five years unless the product is expected to be in use for less than five years, in which case it corresponds to the expected use time (Article 13(8), third subparagraph). The criteria used to determine it are listed in Article 13(8), second subparagraph.
- Availability of updates. Each security update made available during the support period must remain available for at least ten years after it is issued, or for the remainder of the support period if longer (Article 13(9)).
- Single point of contact. Manufacturers must designate a single point of contact so that users can communicate with them, including to report vulnerabilities (Article 13(17)).
- Policies. Manufacturers must have appropriate policies and procedures, including coordinated vulnerability disclosure policies, to process and remediate vulnerabilities reported from internal or external sources (Article 13(8), sixth subparagraph).
Reporting under Article 14
What triggers a notification
The CRA defines an actively exploited vulnerability as 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 vulnerability that has merely been discovered, or that is theoretically exploitable, does not by itself trigger the Article 14 notification — it remains subject to the handling requirements above.
A severe incident is an incident having an impact on the security of the product that either affects (or is capable of affecting) the product's ability to protect the 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 product or in a user's network and information systems (Article 14(5)).
The notification schedule
What the text requires
For an actively exploited vulnerability (Article 14(2)), the manufacturer submits:
| Step | Deadline in the text | Content (summary) |
|---|---|---|
| Early warning | without undue delay and in any event within 24 hours of becoming aware of it | where applicable, the Member States where the product has been made available |
| Vulnerability notification | without undue delay and in any event within 72 hours of becoming aware of it | general information about the product, the exploit and the vulnerability, corrective or mitigating measures, sensitivity of the information |
| Final report | no later than 14 days after a corrective or mitigating measure is available | description, severity and impact; where available, the malicious actor; details of the security update or corrective measures |
For a severe incident (Article 14(4)), the manufacturer submits:
| Step | Deadline in the text | Content (summary) |
|---|---|---|
| Early warning | without undue delay and in any event within 24 hours of becoming aware of it | at least whether the incident is suspected of being caused by unlawful or malicious acts; where applicable, the Member States concerned |
| Incident notification | without undue delay and in any event within 72 hours of becoming aware of it | nature of the incident, initial assessment, corrective or mitigating measures, sensitivity of the information |
| Final report | within one month after the submission of the incident notification | detailed description, severity and impact; likely threat type or root cause; applied and ongoing mitigation measures |
Steps (b) and (c) are required unless the relevant information has already been provided. The CSIRT may also request an intermediate report on status updates (Article 14(6)).
Note the difference between the two final reports: for vulnerabilities the clock starts when a corrective or mitigating measure is available (no later than 14 days after a corrective or mitigating measure is available Article 14(2), point (c)
), whereas for incidents it runs from the incident notification (within one month after the submission of the incident notification under point (b) Article 14(4), point (c)
).
Where and how to notify
Notifications go simultaneously to the CSIRT designated as coordinator and to ENISA (Article 14(1), Article 14(3)), via the single reporting platform established and managed by ENISA (Article 16(1)). The manufacturer uses the electronic notification end-point of the CSIRT of the Member State where it has its main establishment — where decisions related to the cybersecurity of its products are predominantly taken (Article 14(7), second subparagraph). For manufacturers without a main establishment in the Union, the text sets an order of precedence based on the authorised representative, importer, distributor, and finally the location of users (Article 14(7), third subparagraph).
The receiving CSIRT disseminates the notification to the CSIRTs of the Member States where the product has been made available; in exceptional circumstances, dissemination may be delayed on justified cybersecurity-related grounds (Article 16(2)).
Informing users
After becoming aware of an actively exploited vulnerability or severe incident, the manufacturer must inform the impacted users — and where appropriate all users — and, where necessary, explain the mitigation and corrective measures they can deploy, where appropriate in a structured, machine-readable format (Article 14(8)). If the manufacturer fails to do so in a timely manner, the CSIRTs may inform users themselves.
Voluntary reporting
Manufacturers and any other natural or legal person may also report, on a voluntary basis, any vulnerability, cyber threat, incident or near miss to a CSIRT designated as coordinator or to ENISA (Article 15(1), Article 15(2)). Voluntary reporting does not create additional obligations for the notifier (Article 15(5)).
When does this apply?
What the text requires
Article 14 applies from 11 September 2026, earlier than the general date of application of 11 December 2027 (Article 71(2), second subparagraph). By derogation from the general transitional rule, Article 14 also applies to all in-scope products placed on the market before 11 December 2027 (Article 69(3)). The vulnerability handling requirements of Annex I, Part II apply as part of the general application of the Regulation.
Nuances and limits
Our interpretation
"Becoming aware" is the starting point of the 24-hour and 72-hour clocks, but the Regulation does not define it in detail. In our reading, a manufacturer should document when and how it obtained reliable evidence of exploitation, because that moment determines whether deadlines were met. Official guidance or the delegated and implementing acts mentioned in Article 14(9) and Article 14(10) may refine the procedures.
Uncertain / awaiting guidance
The Commission may specify the format and procedures of notifications by implementing acts (Article 14(10)). Until such acts and the platform specifications (Article 16(5)) are available and checked, practical details such as notification forms should be confirmed against ENISA and national CSIRT publications.
The administrative fines for Article 14 infringements do not apply to manufacturers that qualify as microenterprises or small enterprises as regards a failure to meet the 24-hour early warning deadline (Article 64(10), point (a)). The other reporting obligations remain.
Open-source software stewards are subject to Article 14(1) to the extent that they are involved in the development of the products, and to Article 14(3) and (8) in the circumstances described in Article 24(3).
Fictional example — Acme Sensors
Acme Sensors, a fictional manufacturer of connected air-quality sensors sold in several Member States, learns on a Monday morning from a security researcher, with logs attached, that attackers have used a flaw in its firmware update service to take control of customer devices. Acme treats this as reliable evidence of active exploitation. Its team submits an early warning through the single reporting platform to the CSIRT of the Member State where its product security decisions are taken, listing the Member States where the sensor is sold. Within 72 hours it submits the vulnerability notification with the measures users can take. It informs affected customers with a security advisory. Once the patched firmware is released, it prepares the final report and files it within 14 days.
Good practice (recommendation, not a legal requirement)
Prepare before September 2026: name an owner for Article 14 decisions, write down the criteria you will use to decide that evidence of exploitation is "reliable", keep a dated log of each decision, prepare notification templates matching the content listed in Article 14(2) and (4), and rehearse the process with a tabletop exercise. These steps are good practice, not requirements of the text.
What to do next
Map your current vulnerability handling process against the eight points of Annex I, Part II, then check that your organisation can produce a 24-hour early warning. The reporting obligation already applies to products on the market today.