Active Exploitation and Incident Reporting - 24h, 72h, and 14-Day Obligations

Article 14 establishes a three-stage notification process triggered by active exploitation of a vulnerability or a severe security incident:

The first two deadlines are calculated from the moment the manufacturer becomes aware of the active exploitation or incident - not from when exploitation began. The final report runs on a different clock, and this is the detail most summaries get wrong. For an actively exploited vulnerability, Article 14(2)(c) gives you 14 days from the moment a corrective or mitigating measure is available, not from awareness. For a severe incident, Article 14(4)(c) gives you one month from the submission of the 72-hour incident notification. The full legal text is set out in Article 14 of Regulation (EU) 2024/2847 on EUR-Lex.

Every Article 14 deadline runs from the moment the manufacturer becomes aware, and the Regulation does not define that moment. Commission guidance C(2026) 5252 does. On detecting a suspicious event, or on a third party such as a researcher, customer, authority or media organisation bringing something to its attention, the manufacturer should assess it immediately. Awareness arises when, after that initial assessment, there is a reasonable degree of certainty that a vulnerability contained in the product is being actively exploited, or that a severe incident has occurred and has compromised the security of the product.

Receiving a report therefore does not by itself start the clock, and neither does an unexamined suspicion. A short triage window sits in front of the 24 hours. It is not open-ended, and the guidance stresses prompt action to carry out the initial assessment, particularly where the vulnerability may pose a significant risk.

The Commission deliberately aligned this reading with recital 31 of Implementing Regulation (EU) 2024/2690 under NIS2 and with Section II(A) of the EDPB guidelines on personal data breach notification under the GDPR, so that a manufacturer subject to several regimes can apply one awareness standard. The guidance is non-binding, and only the Court of Justice of the European Union can give an authoritative interpretation.

Two conditions trigger Article 14 notification:

1. Active exploitation - A vulnerability in your product is being actively exploited in the wild. This means there is evidence of real-world attacks using the vulnerability, not just proof-of-concept code.

1. Severe security incident - A security incident that has (or may have) a significant impact on the security of users of your product, or a significant impact on the internal operations of your organisation.

Not triggered by: Theoretical vulnerabilities, vulnerabilities with no known exploitation, low-severity bugs, or normal vulnerability reports received through your CVD programme that are not actively exploited.

Notifications must be submitted to the CSIRT designated as coordinator in the member state where you have your main establishment, and to ENISA. Each EU member state designates a coordinator CSIRT for this purpose.

ENISA is establishing a Single Reporting Platform for Article 14 notifications. Until this is operational, manufacturers should contact their national CSIRT directly.

• Germany: BSI (Federal Office for Information Security)
• France: ANSSI
• Netherlands: NCSC-NL
• Sweden: NCSC-SE
• Spain: INCIBE-CERT

CVD Portal can draft Article 14 notifications in the required format and alert you when deadlines are approaching.

The 24-hour early warning is not a full technical report - it is a rapid notification that exploitation is occurring. ENISA uses this signal to coordinate cross-border incident response before the full picture is known.

• Product name and affected version(s)
• Nature of the vulnerability or incident (brief description)
• Indication that active exploitation is occurring
• Geographic scope if known
• Initial mitigation actions taken (if any)

You do not need to have a root cause analysis or patch ready at this stage. Speed of notification is the priority.

Within 72 hours of becoming aware of active exploitation, you must submit a full vulnerability notification. This expands on the early warning with:

• CVSS 3.1 (or 4.0) score and vector string
• CVE identifier (or a request for one if not yet assigned)
• Affected products, versions, and configurations
• Description of the impact on confidentiality, integrity, and availability
• Known attack vectors and exploitation techniques
• Mitigations available (patches, workarounds, configuration changes)
• Supply chain impact assessment (are other products affected?)

72 hours is a very tight window for a complete analysis. This means your incident response process must be able to move very quickly when an active exploitation is confirmed.

The final report closes the case with ENISA and the coordinating CSIRT. Its deadline depends on which trigger you are reporting. For an actively exploited vulnerability, Article 14(2)(c) gives you 14 days from the moment a corrective or mitigating measure is available. For a severe incident, Article 14(4)(c) gives you one month from the submission of the 72-hour incident notification. It must include:

• Root cause analysis
• Complete remediation details (patch release, advisory publication)
• CSAF advisory (if applicable)
• Supply chain coordination actions taken
• Steps taken to prevent recurrence
• Lessons learned

If the case is still open when your clock runs out, submit what you have and explain what remains under investigation. Separately, under Article 14(6) the coordinating CSIRT that received your notification can request an intermediate report on status updates at any point between the stages.

Article 14 has significant supply chain implications. If a vulnerability affects components you source from third-party vendors, you are still responsible for the Article 14 notification for your product - but you must also:

1. Notify the component vendor if the vulnerability originates in their component
2. Coordinate with them on remediation timelines
3. Report the supply chain dimension in your Article 14 notifications

Conversely, if you are a component supplier and your component is found to be vulnerable, you must notify downstream manufacturers who integrate your component. This creates a notification cascade up and down the supply chain.

No to the first and yes to the second. Commission guidance C(2026) 5252 confirms that Article 14 applies from 11 September 2026 to all products with digital elements in scope, including products placed on the market before 11 December 2027, and that the reporting obligations continue after a product is no longer supported. Vulnerability handling under Annex I Part II behaves differently and stops with the support period.

There is no retroactive reporting. A manufacturer is not required to report active exploitation it had already become aware of before 11 September 2026. Where a vulnerability was known before that date but its active exploitation was not, either because none had occurred or because the manufacturer had not learned of it, and exploitation occurs or comes to light after that date, the vulnerability is reportable.

A vulnerability originating in an integrated third-party component is reportable only where it is actively exploited in your product. Where the vulnerable code is unreachable, or exploitation has not occurred in your product, no mandatory report arises. Voluntary notification under Article 15 remains available, the Annex I Part II handling requirements still apply, and Article 13(6) still requires the vulnerability to be reported upstream to whoever maintains the component.