Severe incident having an impact on security: when Art. 14 applies
Art. 14 has two triggers, not one. The first is the actively exploited vulnerability. The second is a severe incident having an impact on the security of the product — and it applies even when no vulnerability has been exploited.
1. What a severe incident is, under the Regulation
Not 'a serious problem'. It is a defined category: an incident that negatively affects the ability of the product with digital elements to protect the availability, authenticity, integrity or confidentiality of data or functions, or that has led to the execution of malicious code. Two alternative conditions: one is enough.
The practical difference from an exploited vulnerability is the starting point. There you start from a product flaw somebody used. Here you start from an event — unauthorised access to your update infrastructure, a compromised signing key, a malicious package that entered the distribution chain — that degraded the product's security properties. There may never have been a flaw at all.
2. Two chains, not one
Art. 14 keeps the two chains apart, and mixing them up means missing deadlines. The two things that trigger the duty are:
- an actively exploited vulnerability in the product, that is, with evidence that somebody used it without authorisation;
- a severe incident having an impact on the security of the product, even where no vulnerability was exploited.
The first two deadlines are identical — 24 hours and 72 hours — but the final one is not, and neither is the content of each filing. The distinction between a reported and an exploited vulnerability does not help you qualify an incident: they are two different axes.
3. When the clock starts
At the moment of awareness. Not when you open the case, not when the crisis team meets, not when you have grasped the scale. At the instant the manufacturer becomes aware of the incident: the report that landed on the public address, the monitoring alert somebody read, the customer's phone call.
It is the instant you will have to name to an authority, with evidence of when you fixed it. Fixing it late does not extend the deadlines: it only moves them on paper, and the paper is exactly what will be looked at.
If the moment of awareness falls on a Saturday evening, the 24 hours run from Saturday evening. The Regulation knows nothing of working days.
4. The three filings, and the deadline that changes
The chain is the Art. 14 one, with a difference on the final report:
- early warning within 24 hours of awareness: you declare that a severe incident exists, with what you know;
- update notification within 72 hours: initial assessment, severity, impact, and the corrective or mitigating measures taken;
- final report within one month of the update notification: description of the incident, severity and impact, root causes, measures applied.
This is where the two chains diverge. For an exploited vulnerability the final report is anchored to the date the corrective measure becomes available, plus fourteen days. For a severe incident it is anchored to the update notification, plus one month. Handling an incident on the vulnerability calendar misses the deadline by weeks.
5. Who receives the filing
The two recipients set out in the Regulation: the CSIRT designated by the Member State, and ENISA. Filing goes through the single reporting platform established by Art. 16, with EU Login credentials: administrative steps that are prepared beforehand, not inside the twenty-four hours.
The Regulation terms used on this page — severe incident, moment of awareness, corrective measure, single reporting platform — are in the glossary, each with its own article.
6. What to prepare in advance
A severe incident is qualified under pressure, and the qualification has to be documented while you make it, not reconstructed afterwards. Four things make the difference:
- a single channel where external reports arrive, with a timestamp on every entry;
- a written criterion to tell a malfunction from an incident with a security impact;
- the contact point to the designated CSIRT and the EU Login credentials, already validated;
- a record of decisions: a reasoned 'no, this is not a severe incident' counts as due diligence, while a silent 'no' counts for nothing.
None of these four is built on the day of the case.
This page describes the Regulation in general terms; it is not legal advice and not an assessment of your specific case. Qualifying an event, and the deadlines that follow, remain the manufacturer's responsibility.
Who receives your notification, country by country
Art. 14 sends the notification to two recipients: the CSIRT designated by your Member State, and ENISA. The CSIRT changes with the country. Pick yours and read who staffs it, how filing works and what to prepare in advance.
- ItalyCSIRT Italia
- GermanyCERT-Bund
- AustriaCERT.at
- FranceCERT-FR
- BelgiumCERT.be
- LuxembourgCIRCL
- SpainINCIBE-CERT
- NetherlandsNCSC-NL
- PolandCSIRT NASK
Nine countries. Designation for CRA purposes follows national implementation: check the one in force before you file.