Vulnerability Reporting

When reporting is required

The trigger is not the product category, the CVSS score, or the fact that a vulnerability exists. Article 14 asks whether the manufacturer has become aware of a reportable event in a product with digital elements.

Other vulnerabilities, cyber threats, near misses, and lower-impact incidents may still matter under vulnerability handling or voluntary reporting. They are not automatically mandatory Article 14 reports.

Actively exploited vulnerability

‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner;

Regulation (EU) 2024/2847, Article 3(42)

The definition has three parts. There must be a vulnerability, there must be reliable evidence of exploitation, and the exploitation must be malicious and unauthorised. A theoretical exploit path or a scanner result is not enough by itself.

A zero-day vulnerability can be reportable, but only if the manufacturer has reliable evidence that a malicious actor has exploited it. A good-faith bug-bounty report or laboratory finding with no evidence of previous malicious exploitation is outside the mandatory Article 14 trigger, though voluntary reporting may still be available.

Reliable awareness can come from several routes:

• a customer or partner reports compromise and provides evidence that the product vulnerability was exploited;
• a government body, security researcher, or threat-intelligence report identifies exploitation in the product;
• the manufacturer's own telemetry, monitoring, or investigation finds evidence of exploitation.

The vulnerability also has to be contained in the product with digital elements. If an integrated component has a vulnerability that cannot be exploited in the manufacturer's product, that fact does not become an actively exploited vulnerability in that product merely because the component is affected elsewhere.

Severe incident affecting product security

A severe incident is also product-centred. A general corporate IT incident is not enough by itself. The incident must have an impact on the security of the product with digital elements.

Article 14 treats an incident as severe when either:

• it negatively affects, or can negatively affect, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions;
• it has led, or can lead, to malicious code being introduced or executed in the product or in a user's network and information systems.

24 hours, 72 hours, and the final report

Article 14 uses staged reporting. The first report is an early warning and does not need to be a complete technical dossier. Later stages add the information available as the manufacturer investigates and mitigates the event.

1. Early warning: without undue delay and within 24 hours after the manufacturer becomes aware.
2. Main notification: without undue delay and within 72 hours after awareness, unless the relevant information was already provided.
3. Final report for an actively exploited vulnerability: no later than 14 days after a corrective or mitigating measure is available.
4. Final report for a severe incident: within one month after the 72-hour incident notification.

The deadlines run from awareness of the reportable event. The 24-hour and 72-hour stages are not waiting periods; the Regulation still says the notification must be made without undue delay.

Single Reporting Platform

For the purposes of the notifications referred to in Article 14(1) and (3) and Article 15(1) and (2) and in order to simplify the reporting obligations of manufacturers, a single reporting platform shall be established by ENISA. The day-to-day operations of that single reporting platform shall be managed and maintained by ENISA. The architecture of the single reporting platform shall allow Member States and ENISA to put in place their own electronic notification end-points.

Regulation (EU) 2024/2847, Article 16(1)

The Single Reporting Platform is the route for Article 14 notifications. The platform is scheduled to be operational by 11 September 2026, with testing before that date.

Reporting readiness

The trigger analysis and the reporting setup are different. This page explains when Article 14 is triggered. The separate readiness page explains the SRP route, coordinating CSIRT, Member State product map, and internal data that should be prepared before 11 September 2026.

Read Article 14 Reporting Readiness after the trigger rules are clear.

Boundary cases