Cyber Resilience Act Response Center Request a demoDemo

Guide Last updated 12 min read

Actively exploited vulnerability: what must be reported and what need not be

The reporting obligation under Article 14 does not apply to every vulnerability, only where there is reliable evidence of exploitation. This page explains the definition, separates it from CVE entries, scanner findings and researcher tests, and shows how to proceed when in doubt.

Under Article 3, point (42) of Regulation (EU) 2024/2847, an actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. Only vulnerabilities of this kind trigger the reporting obligation under Article 14(1). An entry in the CVE vulnerability database, a high CVSS score (the usual measure of how serious a flaw is), a scanner finding or an exploit demonstrated by a security researcher are not enough on their own. What matters is whether someone has actually used the flaw in your product against the will of the operator, and whether you know this with a reasonable degree of certainty.

Key points

  • Only a vulnerability contained in your product, for which there is reliable evidence of exploitation by a malicious actor, has to be reported (Article 3, point (42), Article 14(1)).
  • Not a trigger: publication of a CVE, a CVSS score, a proof of concept without real exploitation, findings from good-faith testing (recital 68).
  • Vulnerabilities in third-party components must be reported if they are contained in your product and exploited there. Otherwise: report upstream and, optionally, notify voluntarily under Article 15 (guidance, paragraph 218).
  • The CRA notification does not replace a notification under the GDPR, NIS2 or DORA (recital 72).
  • When in doubt, assess immediately and document the assessment. Reporting is the outcome of the assessment, not a substitute for it.

What does the definition in Article 3, point (42) say?

The Regulation distinguishes three levels. Under Article 3, point (40), a vulnerability is a weakness, susceptibility or flaw of a product that can be exploited by a cyber threat. Under point (41), an exploitable vulnerability is one that has the potential to be effectively used by an adversary under practical operational conditions. Only the third level triggers the reporting obligation:

'actively exploited vulnerability' means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner;

Article 3, point (42) CRA

Three elements must all be present:

  • Reliable evidence. A suspicion or a mere possibility is not enough. What counts as reliable in a given case (log data, traces on customer systems, a tip-off from the CSIRT) is not laid down in the Regulation; the Commission guidance stays abstract on this point.
  • A malicious actor. Someone has used the flaw with harmful intent. A tester or researcher who reproduces it as part of an assessment is not a malicious actor.
  • Without permission of the system owner. The exploitation took place against the will of whoever operates the system. A commissioned penetration test does not meet this criterion.

Article 14(1) adds a further limit: the obligation applies only to vulnerabilities contained in the product, and only once the manufacturer becomes aware of them. When the 24-hour deadline starts is explained in the guide When does the 24-hour deadline start? Awareness under Article 14 CRA.

What is not a trigger?

Most of the vulnerabilities a manufacturer deals with day to day do not have to be reported. Four cases come up particularly often:

  • A CVE entry on its own. CVE is the public catalogue of known vulnerabilities. A flaw being listed there says nothing about whether it is being exploited in your product. In a different context (paragraphs 230 to 235, on known exploitable vulnerabilities under Annex I, Part I, point (2)), the Commission guidance states that the mere fact that a vulnerability is reported or found does not, in itself, mean that it is exploitable in practice or applicable to the specific product.
  • A high CVSS score. CVSS rates how serious a vulnerability is in theory, not whether it is being exploited. A score of 9.8 without evidence of exploitation is not a trigger; a score of 5.0 with proven exploitation is.
  • A proof of concept without exploitation. A proof of concept shows that a flaw can in principle be used. If a researcher publishes one, there is still no exploitation by a malicious actor. From that point on, however, you should keep a close eye on telemetry, customer reports and support requests.
  • Findings from good-faith testing. Recital 68 expressly excludes vulnerabilities discovered with no malicious intent for the purposes of good-faith testing, investigation, correction or disclosure. A penetration test or a report received through your coordinated vulnerability disclosure process are cases of this kind.

What is enough, on the other hand, is exploitation at a single customer. The definition speaks of a system, not of many. As an example, recital 68 mentions a security breach affecting users that has resulted from a malicious actor making use of a flaw in the product, such as a weakness in its identification and authentication functions.

How do vulnerabilities in third-party components count?

Hardly any product consists solely of the manufacturer's own code. Libraries, operating systems, protocol stacks and open-source components are found in almost every device and every piece of software. The Commission guidance (C(2026) 5252, paragraph 218) draws a clear line here: an actively exploited vulnerability originating from a third-party component must be reported if the component is contained in your product. There are two cases in which it does not have to be reported:

  • The vulnerability cannot be exploited in your product, because the vulnerable code is not reachable there.
  • The vulnerability has not been exploited in your product, even if it has been exploited in another product using the same component.

In both cases, a voluntary notification under Article 15 remains possible. The other obligations remain as well: under Article 13(6), you report the vulnerability to the manufacturer of the component (upstream reporting) and handle it in your own product in line with Annex I, Part II. The component manufacturer's notification does not replace yours if the flaw is exploited in your product. More on this in the guide Open source and the CRA.

Decision tree: is there a trigger?

The following questions take you through the assessment in the order of the Regulation. Each answer determines the next step.

  1. Does the vulnerability affect a product that you make available in the EU as its manufacturer?No: no obligation under Article 14; importers, distributors and users have other obligations. Yes: go to question 2.
  2. Is the vulnerability contained in your product and reachable there?No: no obligation under Article 14; document the reasoning. Yes: go to question 3.
  3. Are there signs of exploitation by a malicious actor without the permission of the system owner?No, it is a CVE entry, a scanner finding, a proof of concept or a good-faith test: no obligation under Article 14; handle the vulnerability under Annex I, Part II and, for third-party components, report upstream. Yes or unclear: go to question 4.
  4. Are the signs reliable after an immediate initial assessment?If the assessment shows with a reasonable degree of certainty that exploitation is taking place in your product: you are aware, and the 24-hour deadline is running (paragraph 213). If it remains a suspicion: continue the assessment, record every step with a timestamp, consider a voluntary notification under Article 15.
  5. Did the exploitation only become known after 11 September 2026?No, you already knew about it before then: no retroactive notification (paragraph 217, ENISA FAQ 13). Yes: early warning within 24 hours, notification within 72 hours, final report no later than 14 days after a corrective or mitigating measure is available (Article 14(2)), and inform the impacted users under Article 14(8).

How does the CRA notification relate to the GDPR, NIS2 and DORA?

A notification under Article 14 does not replace any other reporting obligation. Recital 72 expressly names the General Data Protection Regulation (EU) 2016/679, the NIS2 Directive (EU) 2022/2555, the DORA Regulation (EU) 2022/2554 and the ePrivacy Directive 2002/58/EC as complementary reporting requirements. In practice, this means:

  • GDPR: If personal data are affected, the controller notifies the data protection supervisory authority within 72 hours under Article 33 GDPR and, where required, informs the data subjects under Article 34. The threshold is the risk to the rights and freedoms of natural persons.
  • NIS2: If the manufacturer is also an important or essential entity, it reports an incident in its own infrastructure under Article 23 NIS2, which in Germany means reporting to the BSI under section 32 of the BSI Act (BSIG). The threshold is a significant incident as defined in section 2, point 11 BSIG: serious operational disruption of the services or financial loss for the entity, or considerable material or non-material damage to other persons, whether it has occurred or is possible. More on this in the guide CRA and NIS2 compared.
  • DORA: Financial entities also report ICT-related incidents under the rules of that Regulation.

The thresholds differ, and so do the forms. One advantage remains: the Commission guidance has deliberately aligned the concept of becoming aware with NIS2 and with the guidelines on personal data breach notification under the GDPR (paragraph 212). The point from which the deadlines run can therefore be determined once and used for all regimes.

What does a voluntary notification under Article 15 achieve?

Article 15 allows vulnerabilities and cyber threats (paragraph 1) as well as incidents and near misses (paragraph 2) to be notified voluntarily to the coordinating CSIRT or to ENISA. Under paragraph 5, a voluntary notification does not create any additional obligations; it does not trigger the deadlines in Article 14. Under paragraph 4, the CSIRT informs the manufacturer without undue delay if a third party notifies an actively exploited vulnerability in the manufacturer's product; the initial assessment begins from that notice. As of 3 October 2026, the single reporting platform had not yet implemented voluntary notifications (ENISA FAQ 27); ENISA does not say how they should be submitted in the meantime.

When in doubt, assess; do not report by reflex

This principle sounds like holding back. It means the opposite. The Regulation requires a notification when there is reliable evidence, and reliability comes from assessment, not from reflex. Anyone who sends an early warning for every scanner finding burdens the CSIRT with notifications that have no trigger, and gets their own organisation used to false alarms. Within 72 hours they then have to supply details of the nature of the exploitation that do not exist.

Conversely, the assessment must not become an excuse for delay. The initial assessment has to start immediately (paragraph 213), and awareness exists once there is a reasonable degree of certainty, not only after a complete root cause analysis. An assessment that is artificially drawn out does not credibly move the moment of awareness. So the assessment has to be taken on by someone who can be reached immediately, including at night and at weekends. That is the core of readiness: every report to your security address is looked at straight away, classified and recorded with a timestamp; where exploitation is suspected, the responsible person is woken up. CRA Response Center recognises important reports, notifies the people responsible and shows the deadlines from the moment awareness is confirmed; the decision on whether there is a trigger, and the submission, stay with the manufacturer.

Free templatesCRA Reporting KitThe assessment questions as a form for the initial assessment, with an awareness record, playbook and deadline calculator. Word, Excel and PDF.Request the kit

Common mistakes

  • Treating every CVE in the bill of materials as reportable. This floods the CSIRT and ties up your people with notifications that have no trigger.
  • Not treating customer reports of "strange logins" as a suspicious event. Signs like these are exactly how awareness typically begins.
  • Not recording the moment of awareness. The platform does not yet have a field for this in vulnerability notifications; the ENISA glossary (as of 1 October 2026) announces one for the next release. Without your own record, the 24-hour deadline can later be neither proven nor defended.
  • Misjudging third-party components. Either forgetting the upstream report under Article 13(6), or failing to make your own mandatory notification because the component manufacturer has already reported.

Frequently asked questions

Does the publication of a CVE trigger the reporting obligation?

No. A CVE entry shows that a vulnerability is known, not that it is being exploited. It only has to be reported once there is reliable evidence of exploitation by a malicious actor without the permission of the system owner (Article 3, point (42)).

Do I have to report an exploit that a researcher demonstrates to me?

No, as long as no exploitation by a malicious actor has been established. Recital 68 excludes good-faith testing and disclosure. The coordinated vulnerability disclosure process still goes ahead.

A customer reports an attack through our product. Is that enough?

It is a suspicious event that must be assessed immediately. You are aware once the initial assessment confirms exploitation in your product with a reasonable degree of certainty (guidance, paragraph 213). Both points in time belong in the record.

The vulnerability is in a component we bought in. Do I have to report?

Yes, if the component is contained in your product and the vulnerability is exploited there. No, if the vulnerable code is not reachable in your product or exploitation has only been shown in other companies' products (guidance, paragraph 218). Either way, you report the vulnerability to the component manufacturer (Article 13(6)).

Do I have to report cases from before 11 September 2026 retroactively?

No. Exploitation you already knew about before 11 September 2026 does not have to be reported retroactively (guidance, paragraph 217). If only the vulnerability was known and the exploitation becomes known after that date, it must be reported.

Does the CRA notification replace the GDPR or NIS2 notification?

No. Recital 72 names the GDPR, NIS2, DORA and the ePrivacy Directive as complementary reporting requirements. They all run in parallel, each with its own thresholds and forms.

Further reading

Sources

The reporting obligation already applies. Who answers at night at your company?

CRA Response Center monitors your security mailbox, recognises important reports using AI hosted in Germany (your e-mails never go to OpenAI, Anthropic or Google) and alerts your people by SMS and e-mail. EUR 190 per month including VAT. Try it free for 30 days.

Try it free for 30 days