Manufacturers do not report every vulnerability or security event under Article 14. They report qualifying actively exploited vulnerabilities and severe product-security incidents through the Single Reporting Platform. The required information becomes more detailed across the 24-hour, 72-hour and final-report stages.
Article 14 Has Two Mandatory Reporting Triggers
Article 14 separates mandatory manufacturer reporting into two legal categories. Paragraph 1 covers an actively exploited vulnerability contained in a product with digital elements that the manufacturer becomes aware of. Paragraph 3 covers a severe incident having an impact on the security of a product with digital elements that the manufacturer becomes aware of. The distinction matters because the evidence used to establish the trigger and the information required in the final report are different. Internal product-security queues should therefore classify the event before the team begins preparing the regulatory notification. A single generic category called security issue is not precise enough for Article 14 operations.
- Trigger 1: an actively exploited vulnerability contained in the product.
- Trigger 2: a severe incident having an impact on product security.
- Both duties depend on manufacturer awareness.
- Both mandatory notification tracks use the Single Reporting Platform.
Not Every Vulnerability Is an Article 14 Mandatory Report
The CRA distinguishes a vulnerability from an actively exploited vulnerability. A vulnerability can exist without reliable evidence that a malicious actor has used it. The Regulation also separately defines an exploitable vulnerability as one that has the potential to be effectively used by an adversary under practical operational conditions. Even that does not automatically mean active exploitation has occurred. Article 14 mandatory vulnerability reporting requires the active-exploitation trigger. Manufacturers still need to assess and remediate non-reportable vulnerabilities through their vulnerability-handling processes, but remediation duties and Article 14 notification are separate questions. This distinction prevents the mandatory reporting mechanism from becoming a notification system for every weakness identified during normal security testing.
- A discovered weakness is not automatically an Article 14 report.
- Technical exploitability does not by itself establish active exploitation.
- The Article 14 reporting decision should be recorded separately from remediation priority.
- A non-reportable vulnerability can still require urgent corrective action.
The 24-Hour Early Warning Is the First Regulatory Stage
For an actively exploited vulnerability, Article 14 requires an early warning without undue delay and in any event within 24 hours after the manufacturer becomes aware of it. Where applicable, the early warning identifies the Member States in which the manufacturer is aware that the affected product has been made available. A severe incident follows the same 24-hour outer deadline, while the incident early warning also includes at least whether the incident is suspected of being caused by unlawful or malicious acts. The early-warning stage is designed for rapid regulatory awareness. Manufacturers should not wait for complete root-cause analysis, full attribution or a finished security update before beginning the reporting process.
- Submit without undue delay and no later than 24 hours after awareness.
- Identify relevant Member States where applicable.
- For severe incidents, state whether unlawful or malicious acts are suspected.
- Do not delay the early warning until the investigation is complete.
The 72-Hour Notification Adds the Initial Assessment
The second reporting stage is due without undue delay and in any event within 72 hours after awareness unless the relevant information has already been provided. For an actively exploited vulnerability, the notification provides general information, as available, about the affected product, the general nature of the exploit and vulnerability, corrective or mitigating measures already taken and measures users can take. Where applicable, the manufacturer also indicates how sensitive it considers the notified information. For a severe incident, the notification includes general information about the nature of the incident, an initial assessment, corrective or mitigating measures already taken and actions users can take. The 72-hour stage therefore converts the initial warning into a more useful operational assessment.
- Expand the product and event description.
- Provide the initial assessment available at that time.
- Describe corrective or mitigating actions already taken.
- Include actions users can take where relevant.
- Identify sensitive information where applicable.
Final Reports Differ for Vulnerabilities and Severe Incidents
The final-report stage is not identical for the two Article 14 trigger types. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. It includes at least a description of the vulnerability with its severity and impact, information about the malicious actor where available, and details of the security update or other corrective measures made available. For a severe incident, the final report is due within one month after submission of the 72-hour incident notification. It includes a detailed description of the incident, its severity and impact, the type of threat or likely root cause, and applied and ongoing mitigation measures.
- Vulnerability final report is linked to availability of corrective or mitigating measures.
- Severe-incident final report is linked to the 72-hour incident notification.
- Final reports should reflect the developed investigation and remediation record.
- Product and version information should remain traceable throughout reporting.
The CSIRT Can Request an Intermediate Report
Article 14 allows the CSIRT designated as coordinator that initially receives the notification to request an intermediate report where necessary. The intermediate report can provide relevant status updates about the actively exploited vulnerability or severe incident. Manufacturers should therefore keep the regulatory record current between the 72-hour stage and the final report rather than treating the SRP submission as a one-time form. Investigation findings, affected versions, mitigation status and corrective actions can change during this period. Assigning a named owner for regulatory follow-up helps prevent a CSIRT request from becoming separated from the technical team that holds the latest evidence.
- Keep investigation status current.
- Keep mitigation and corrective-action status current.
- Assign ownership for CSIRT follow-up requests.
- Preserve a timeline of material changes.
Article 14 Also Requires User Communication
Regulatory reporting is only one part of Article 14. After becoming aware of an actively exploited vulnerability or severe product-security incident, the manufacturer must inform impacted users and, where appropriate, all users about the vulnerability or incident. Where necessary, the manufacturer also communicates risk-mitigation and corrective measures that users can deploy. The user-facing duty should be built into the same escalation workflow so that the organisation does not complete regulator-facing submissions while overlooking users who need to take action. Product security, engineering, support, legal and communications teams should work from the same affected-product and mitigation information.
- Identify impacted users.
- Provide mitigation and corrective guidance where necessary.
- Coordinate security, support, engineering, legal and communications teams.
- Keep regulatory and user-facing information technically consistent.
Use a Reporting Matrix to Manage Article 14
A practical Article 14 reporting matrix should record the event type, affected product and versions, evidence, manufacturer awareness time, 24-hour deadline, 72-hour deadline, selected CSIRT, SRP representative, mitigation status, user-communication status and final-report deadline. The matrix should also record who made the reporting determination and why. This gives the organisation one operational record while incident responders continue the technical investigation in parallel. It also reduces the risk of confusing vulnerability deadlines with severe-incident deadlines. The purpose is not to replace the SRP or the incident record, but to make the regulatory timeline visible to everyone who has responsibility for completing it.
- Record the trigger category and awareness timestamp.
- Calculate every reporting deadline immediately.
- Assign the SRP representative and reporting decision owner.
- Track mitigation and user-communication status.
- Track the correct final-report deadline.
- Retain evidence supporting the reporting determination.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.