Explanation
Two different duties
Manufacturers have two related but distinct sets of duties:
- Vulnerability handling (Annex I, Part II and Article 13(8)): finding, documenting and fixing vulnerabilities throughout the support period — lesson 3.
- Reporting (Article 14): notifying authorities of actively exploited vulnerabilities and severe incidents, and informing users.
Article 14 applies from 11 September 2026 (Article 71(2), second subparagraph), earlier than most of the regulation, and it also applies to in-scope products placed on the market before 11 December 2027 (Article 69(3)).
What triggers a notification
- A vulnerability is a weakness, susceptibility or flaw of a product that can be exploited by a cyber threat (Article 3, point (40)).
- An actively exploited vulnerability 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)
. - An incident having an impact on the security of the product negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions (Article 3, point (44)). It is severe where it affects or can affect the protection of sensitive or important data or functions, or has led or can lead to the introduction or execution of malicious code (Article 14(5)).
A vulnerability that is merely discovered — by testing or by a researcher — is handled under Annex I, Part II. It becomes subject to mandatory notification under Article 14(1) when there is reliable evidence of exploitation by a malicious actor.
To whom and how
What the text requires
The manufacturer must notify an actively exploited vulnerability, and a severe incident having an impact on the security of the product, simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform established under Article 16 (Article 14(1), Article 14(3)).
The single reporting platform is established and operated by ENISA (Article 16(1)). The notification goes through the electronic end-point of the CSIRT designated as coordinator of the Member State of the manufacturer's main establishment — where decisions related to the cybersecurity of its products are predominantly taken, or failing that, where it has the most employees in the EU. A manufacturer without a main establishment in the EU follows the order set out in Article 14(7), third subparagraph (authorised representative, then importer, then distributor, then users).
The deadlines
What the text requires
For an actively exploited vulnerability (Article 14(2)):
- an early warning without undue delay and in any event within 24 hours of becoming aware of it (Article 14(2), point (a));
- unless already provided, a vulnerability notification within 72 hours of becoming aware (Article 14(2), point (b));
- unless already provided, a final report no later than 14 days after a corrective or mitigating measure is available (Article 14(2), point (c)).
For a severe incident (Article 14(4)):
- an early warning within 24 hours, including whether the incident is suspected of being caused by unlawful or malicious acts (Article 14(4), point (a));
- unless already provided, an incident notification within 72 hours (Article 14(4), point (b));
- unless already provided, a final report within one month after the incident notification (Article 14(4), point (c)).
The CSIRT receiving the notification may also request an intermediate report on status updates (Article 14(6)).
Informing users
After becoming aware of an actively exploited vulnerability or a 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)).
Voluntary reporting and other actors
Manufacturers and others may also report vulnerabilities, cyber threats, incidents and near misses voluntarily (Article 15(1), Article 15(2)). Open-source software stewards are subject to parts of Article 14 to the extent set out in Article 24(3). Importers and distributors who become aware of a vulnerability must inform the manufacturer without undue delay (Article 19(5), second subparagraph, Article 20(4), second subparagraph).
Uncertain / awaiting guidance
The clocks run from the moment the manufacturer "becomes aware". The regulation does not define a precise trigger, and organisations need an internal rule for when evidence is considered reliable and who decides. Official guidance on the reporting obligations may clarify this; until then, document the criteria you apply.
Do not confuse these notifications with the notification of conformity assessment bodies in Chapter IV, which applies from 11 June 2026 and concerns Member States notifying bodies to the Commission — not manufacturers reporting vulnerabilities.
Practical case
Fictional example — Kestrel Robotics and an exploited flaw
Kestrel Robotics, a fictional manufacturer of warehouse robots with its main establishment in the Netherlands, receives a customer's forensic report on Monday at 09:00. It shows that an attacker exploited an authentication flaw in the robot controller to take control of a robot. Kestrel's security lead confirms the evidence is reliable the same day.
- Early warning (24 hours): submitted on Monday afternoon through the single reporting platform, using the end-point of the Dutch CSIRT designated as coordinator; ENISA has simultaneous access. It indicates the Member States where Kestrel knows the robots are made available.
- Vulnerability notification (72 hours): submitted on Wednesday with the general nature of the exploit, the affected models and the mitigating measure customers can apply (disable remote access).
- Patch: available on the following Friday.
- Final report: due no later than 14 days after the patch is available, with the description, severity and impact, information on the malicious actor where available and details of the update.
- Users: Kestrel informs impacted customers with a machine-readable advisory listing the affected firmware versions and the mitigation.
Exercise
EXERCISE — RUN THE CLOCK FOR A SEVERE INCIDENT
A fictional manufacturer becomes aware on 2 March at 14:00 that malicious code was introduced into its products through its update server. It submits the incident notification on 4 March at 10:00.
- Is this a severe incident having an impact on the security of the product? Why?
- By when must the early warning be submitted?
- By when must the incident notification be submitted, and was the deadline met?
- By when is the final report due?
Show a suggested answer
- Yes: it has led to the introduction of malicious code in the products — Article 14(5), point (b).
- Without undue delay and in any event by 3 March, 14:00 (24 hours) — Article 14(4), point (a).
- Within 72 hours, i.e. by 5 March, 14:00 — Article 14(4), point (b). Submitted on 4 March at 10:00: the deadline was met.
- Within one month after the submission of the incident notification, i.e. by 4 April — Article 14(4), point (c).
Key takeaways
KEY TAKEAWAYS
- Article 14 has applied since 11 September 2026, including for products placed on the market before 11 December 2027.
- Notify actively exploited vulnerabilities and severe incidents simultaneously to the CSIRT designated as coordinator and ENISA, via the single reporting platform.
- Vulnerabilities: 24 hours, 72 hours, final report 14 days after a fix or mitigation is available.
- Severe incidents: 24 hours, 72 hours, final report one month after the incident notification.
- Inform impacted users; and do not confuse Article 14 with the notification of conformity assessment bodies.