Deadlines
When does a vulnerability have to be reported under Article 14?
Published . Reviewed against Regulation (EU) 2024/2847, OJ L, 20.11.2024, and Commission guidance C(2026) 5252.
Article 14 applies from 11 September 2026. A CVE identifier says that a vulnerability has been catalogued. Article 14 asks a narrower set of questions. This post walks through them in the order they arise, from the text of the Regulation, so that you can see which facts a clock depends on.
“This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026.”
Two tracks, two sets of clocks
Article 14 has a vulnerability track and an incident track. They use different tests and different deadlines, so the first question about any event is which of the two it is. The hour-by-hour post covers the deadlines themselves; this one covers what decides whether a deadline exists.
Vulnerability track: exploited, and in your product
The duty attaches to an “actively exploited vulnerability”, a term the Regulation defines. The definition asks for reliable evidence that a malicious actor has exploited the flaw.
“a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner”
Whether you hold that evidence is a question of fact about your own case. If the facts you have are a published CVE record, a severity score or a proof of concept and nothing more, the evidence the definition asks for is absent on those facts. If you do hold reliable evidence that a malicious actor has exploited the flaw, that element of the definition is present.
The second test is where the flaw sits. Article 14(1) speaks of a vulnerability “contained in the product with digital elements”.
“A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.”
Third-party components are the usual grey zone. The Commission's guidance, which is non-binding, says a vulnerability in a third-party component is reportable only where it is exploited in your own product. One that is unreachable or not exploited there is not reportable, though it still calls for vulnerability handling and for a report to the component's maintainer under Art. 13(6) (guidance paragraph 218). The guidance is not binding, and the definition itself speaks of exploitation “in a system”. Where a flaw in an integrated component is exploited in other systems and is not known to be exploited in your product, the two readings do not point the same way, and the check returns “Needs review”.
Where the definition is not met
A vulnerability that does not meet the definition is not thereby ignorable. Vulnerability handling is a separate requirement in Annex I.
“address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates”
One practical consequence is two records for two questions. The handling record shows that the flaw was addressed. The decision record shows which facts you had when you assessed Article 14.
Incident track: severe, and affecting the product
Incidents have their own severity test. The first limb covers an incident that negatively affects, or is capable of negatively affecting, the product's ability to protect sensitive or important data or functions. The second covers malicious code.
“an incident having an impact on the security of the product with digital elements shall be considered to be severe where: (a) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions”
“it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements”
Both limbs contain the words “or is capable of”. The wording therefore reaches beyond harm that has already happened.
When the clock starts
The 24-hour and 72-hour deadlines on both tracks run from the moment the manufacturer becomes aware. Commission guidance, non-binding, ties awareness to a point after an immediate initial assessment: the manufacturer becomes aware when it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited or that a severe incident has compromised the product's security (guidance paragraph 213). On the guidance’s reading the clock starts at that point. The guidance is not binding, so record both times: when the assessment started and when you reached certainty.
“an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it”
“a vulnerability notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability”
“a final report, no later than 14 days after a corrective or mitigating measure is available”
“an early warning notification of a severe incident having an impact on the security of the product with digital elements, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it”
“an incident notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the incident”
“a final report, within one month after the submission of the incident notification under point (b)”
Two facts that widen the duty
Article 14 does not stop at products placed on the market from a given date. It reaches products placed on the market before 11 December 2027. The non-binding guidance adds that exploitation the manufacturer already knew about before 11 September 2026 need not be reported, while a vulnerability known earlier whose active exploitation starts or becomes known after that date must be (guidance paragraph 217).
“By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.”
The second fact is that the duty runs to users as well as to the authorities. Article 14(8) requires the manufacturer to inform the impacted users.
“the manufacturer shall inform the impacted users of the product with digital elements, and where appropriate all users, of that vulnerability or incident”
Run the check on one event
The free Is this vulnerability or incident reportable? Article 14 check puts the questions above to a single event: vulnerability or incident, where the flaw sits, what you know about exploitation, and what the incident did. Its result reads either that your answers describe an actively exploited vulnerability (Article 14) or a severe incident (Article 14), or that they do not, or that on your answers the vulnerability is not contained in your product (Article 14(1)), or that the case needs review, with the reasons, the clocks that follow and the quoted sources. It runs in your browser and keeps nothing. Orientation, not legal advice. Cybiq never files or transmits anything on your behalf.
Orientation, not legal advice. Verify against the official text before relying on any item.