The Cyber Resilience Act's reporting duty, Article 14 of Regulation (EU) 2024/2847, is usually explained by its clocks: 24 hours, 72 hours, and a final report. The clocks only start when one of two things happens, and both are defined in the Regulation more narrowly than most summaries suggest. Reporting everything is as much a failure as reporting nothing: it floods the CSIRT, it tells users nothing, and it trains the organisation to ignore its own procedure.

Here are the two triggers as the text defines them, and the line each one draws.

Trigger one: an actively exploited vulnerability

Article 14(1) requires the manufacturer to notify "any actively exploited vulnerability contained in the product with digital elements that they become aware of".

Article 3(42) defines the term: an actively exploited vulnerability is "a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner".

Three words carry the definition.

"Reliable evidence." Not a scanner's severity score, not a proof-of-concept on a security blog, not a CVE with an "exploited in the wild" rumour attached. Evidence that exploitation has happened, of a quality you would act on. The Commission's guidance of 27 July 2026 puts awareness at a reasonable degree of certainty: not the first rumour, not completed forensics.

"A malicious actor." Exploitation by your own penetration testers, by a researcher who reported it responsibly, or by a customer testing their own deployment is not exploitation by a malicious actor. The vulnerability may be serious; it is not, on that evidence alone, a trigger.

"In a system." Any system, not only your customer's. Reliable evidence that the vulnerability in your product has been exploited by an attacker anywhere is enough; you do not wait for one of your own users to be hit.

What is out: theoretical vulnerabilities, unexploited proofs of concept, vulnerabilities found by your own testing, and vulnerabilities in components that are known and being remediated but for which there is no evidence of exploitation. Those are Annex I, Part II work, handled and disclosed under the vulnerability-handling requirements, not Article 14 reports.

Trigger two: a severe incident having an impact on the product's security

Article 14(3) requires notification of "any severe incident having an impact on the security of the product with digital elements". Article 14(5) says when an incident is severe:

(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; or (b) 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.

Two things to notice.

"Is capable of." Both limbs cover incidents that could have the effect, not only ones that did. An incident that was contained before data was lost is still severe if it was capable of the loss.

It is about the product's security, not your company's. A breach of your corporate email is an incident, and under NIS2 it may be reportable, but it is an Article 14 trigger only if it has an impact on the security of the product you place on the market: your build pipeline, your update server, the signing key, the cloud back end a product depends on. The test is whether the product's ability to protect its users' data or functions is affected, or whether malicious code could reach the product or its users' systems through it.

The third duty that comes with both: tell your users

Article 14(8): after becoming aware of either trigger, the manufacturer "shall inform the impacted users of the product with digital elements, and where appropriate all users, of that vulnerability or incident and, where necessary, of any risk mitigation and corrective measures that the users can deploy to mitigate the impact", where appropriate in a structured, machine-readable format. If the manufacturer fails to inform users in a timely manner, the CSIRT may do it instead.

This is the duty most reporting procedures forget. The CSIRT and ENISA are one recipient. Users are the other, and the mechanism for reaching them, the wording, and the machine-readable format are things to decide before the day.

Not reportable is still recordable

A vulnerability or incident that does not meet either definition is not reported under Article 14, but the determination that it does not is a record worth keeping: what happened, why it was judged not to meet 3(42) or 14(5), who judged it and when. If the evidence changes, awareness in the Article 14 sense starts then, and the record shows the clock was watched. That is the difference between a company that decided not to report and one that did not notice.

What to do

Write the two definitions into the incident procedure verbatim, with the three questions for each: is there reliable evidence, of exploitation by a malicious actor, in any system; does the incident affect or threaten the product's protection of sensitive data or functions, or malicious code in the product or a user's systems. Name who makes the call, and record every call, including the "no". Then the clocks, to your CSIRT and ENISA, and the message to users.

Sources

  • Regulation (EU) 2024/2847, Article 3(42) (quoted), Article 14(1), (3), (5) (quoted) and (8) (quoted). Read from the Official Journal text on EUR-Lex on 11 September 2026.
  • European Commission guidance C(2026) 5252 of 27 July 2026, on the meaning of awareness.

This is not legal advice. The two definitions are two sentences of the Regulation; they belong in your procedure as written, not as remembered.