Actively Exploited Vulnerability Under the CRA: The ‘Reasonable Certainty’ Test That Starts the 24-Hour Clock, Applied to 9 Cases

Under the Cyber Resilience Act, the 24-hour clock for an actively exploited vulnerability starts when you, as the manufacturer, have a “reasonable degree of certainty” that a vulnerability in your own product is being exploited by a malicious actor. You reach that point through an initial assessment you are expected to start immediately. A published CVE does not start the clock, and neither does a proof-of-concept on GitHub or a researcher’s email. Evidence that someone has used the flaw against a real system does.

The obligation has applied since 11 September 2026. The “reasonable certainty” test comes from the European Commission’s guidance of 27 July 2026, and it is the same test Implementing Regulation 2024/2690 sets for the NIS2 entities it covers. Below you will find the three definitions that decide which clock runs, a seven-question reportability decision tree, and nine real-world situations sorted into three outcomes: actively exploited vulnerability, severe incident, or neither.

Who carries the Article 14 duty

In plain terms: only the manufacturer files. Everyone else in the chain either tells the manufacturer or answers to a different law.

Your role	Article 14 reporting duty?	Legal basis
Manufacturer, including a product sold under your own name or trademark	Yes, both tracks: exploited vulnerabilities and severe incidents	Art 14(1) and (3)
Manufacturer of a product placed on the market before 11 December 2027, or one whose support period has ended	Yes. The reporting duty outlives the support period, although the vulnerability-handling duties do not	Art 69(3); Commission guidance para 210
Open-source software steward	Yes for exploited vulnerabilities, to the extent it is involved in development. Administrative fines do not apply	Art 24(3); Art 64(10)(b)
Importer or distributor	No filing of its own. It must inform the manufacturer “without undue delay” when it learns of a vulnerability	Art 19(5); Art 20(4)
NIS2 entity that only uses the product	No CRA duty. A significant incident is reported under NIS2 Article 23 instead	Art 3(13) CRA; Art 23 NIS2
Manufacturer of a medical device, IVD or type-approved vehicle	No. These products sit outside the CRA	Art 2(2)

The row that catches manufacturers out is the second one. A controller you shipped in 2019 and stopped patching in 2023 is still reportable if it is exploited today. The Commission’s guidance says plainly that “the reporting obligations continue to apply after a product with digital elements is no longer supported”. What you no longer owe for that product is the Annex I Part II vulnerability-handling work.

Three definitions that decide which clock runs

In plain terms: a flaw becomes reportable only once someone hostile has used it, and an incident becomes reportable only once it threatens the product’s own security in a serious way.

The Cyber Resilience Act (Regulation (EU) 2024/2847) builds Article 14 on a short chain of definitions in Article 3. Read them in order and most borderline cases sort themselves out.

Term	What the CRA says	What it leaves out
Vulnerability, Art 3(40)	“a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat”	Nothing yet. This is the starting point, not a trigger
Exploitable vulnerability, Art 3(41)	One that “has the potential to be effectively used by an adversary under practical operational conditions”	Actual use. A working proof-of-concept makes a flaw exploitable, not exploited
Actively exploited vulnerability, Art 3(42)	“reliable evidence that a malicious actor has exploited it in a system without permission of the system owner”	Good-faith testing and research (Recital 68), and any test the system owner authorised (the “without permission” limb)
Incident affecting product security, Art 3(44)	An incident that “negatively affects or is capable of negatively affecting” the product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions	Incidents on corporate IT that have no path to the product
Severe incident, Art 14(5)	(a) it hits “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 the product or in users’ systems	Low-impact events that cannot reach sensitive functions or deliver code

Recital 68 draws the line between the two tracks better than any commentary does. An actively exploited vulnerability is a case where a manufacturer “establishes that a security breach affecting its users … has resulted from a malicious actor making use of a flaw” in its product. A severe incident is an attack on the manufacturer itself, one that “affects the development, production or maintenance processes” in a way that raises risk for users. The recital’s own example is an attacker who “has successfully introduced malicious code into the release channel” for security updates. Put simply, the first track is about a flaw in what you ship, and the second is about a compromise of how you build and ship it.

When you become “aware”: the reasonable-certainty test

In plain terms: the clock starts when your first assessment tells you, with reasonable certainty, that exploitation is real. A suspicion does not start it. A slow assessment does not delay it either.

Article 14 runs the 24-hour and 72-hour deadlines from the moment the manufacturer becomes “aware”, but the regulation never defines awareness. The Commission’s guidance on applying the CRA (C(2026) 5252, July 2026) fills that gap. When a suspicious event surfaces, or a customer, authority, researcher or journalist reports one, the manufacturer “should assess the suspicious event immediately”. It “is therefore to be regarded as having become aware when, after such an initial assessment, it has a reasonable degree of certainty” that a vulnerability in its product is being actively exploited (para 213).

The guidance deliberately borrows this test from recital 31 of Implementing Regulation (EU) 2024/2690 and from the EDPB’s personal data breach guidelines, so that “becoming aware” means the same thing across regimes (para 212). If your NIS2 incident team already logs an “awareness” timestamp, the CRA team can use the same method.

Two limits stop the test from becoming a loophole:

• Speed of assessment. The guidance accepts that confirming exploitation can take time, but “the emphasis should be on prompt action to carry out the initial assessment” (para 214). An assessment parked until Monday is unlikely to persuade a market surveillance authority that awareness only began on Monday.
• No retroactive filings, but no amnesty. If you already knew about active exploitation before 11 September 2026, you do not have to report it now. If you knew about the flaw before that date but only learned of its exploitation afterwards, you do (para 217).

Record the awareness timestamp yourself, because the platform does not anchor its counters to it. ENISA’s Single Reporting Platform FAQ says the counters “do not replace the responsibility” of the manufacturer (FAQ 26). How each of the six deadlines is counted from that timestamp is covered in our guide to CRA reporting requirements.

A note on caution. The legal threshold is reasonable certainty, not suspicion. Many product security teams still adopt a house rule of “unclear means report”, because Article 17(4) provides that “the mere act of notification” does not “subject the notifying natural or legal person to increased liability”. That is a defensible policy choice, but it remains a choice and not a legal requirement.

The reportability decision tree

In plain terms: seven yes-or-no questions, asked in order, each ending in one of three outcomes. Log every outcome, including “no report”.

1. Is this a product we place on the EU market as manufacturer? This includes legacy and unsupported products. If not: Outcome C. An importer or distributor passes the information to the manufacturer.
2. Is it a vulnerability, an incident, or both? If both, run both branches. The tracks are independent.
3. Vulnerability branch: is the flaw in our product and exploitable there? A vulnerable library function our code never calls fails this test, which means Outcome C (Commission guidance para 218).
4. Is there reliable evidence that a malicious actor exploited it in a system without the owner’s permission? Testing, research and a public proof-of-concept do not count. No evidence means Outcome C, with monitoring.
5. Has our initial assessment reached a reasonable degree of certainty? If yes, that timestamp is T+0: Outcome A.
6. Incident branch: can the incident affect the product’s ability to protect the confidentiality, integrity, authenticity or availability of data or functions? Build pipelines, signing keys, update servers and product cloud back-ends usually pass this test. A breach of the HR file server usually does not. If it fails: Outcome C under the CRA.
7. Is it severe under Article 14(5)? That means sensitive or important data or functions are hit, or malicious code is introduced or could be. “Capable of” is enough. If yes: Outcome B.

Outcome	Early warning	Notification	Final report
A. Actively exploited vulnerability, Art 14(2)	24 h from awareness, naming the Member States where the product is available	72 h from awareness, including how sensitive you consider the information	No later than 14 days after a corrective or mitigating measure is available
B. Severe incident, Art 14(4)	24 h, stating whether unlawful or malicious acts are suspected	72 h, with an initial assessment	Within one month after the 72-hour notification
C. Neither	No Article 14 filing. Handle the flaw under Annex I Part II and coordinated disclosure, log the decision, and re-enter the tree if new evidence appears. Voluntary notification exists under Article 15, but the platform has not implemented it yet (ENISA FAQ 27)

Both reportable outcomes go once, through the single reporting platform, to the CSIRT designated as coordinator in your main establishment’s Member State. That is the state where cybersecurity decisions on your products are “predominantly taken”. Manufacturers without an EU establishment follow a fallback order set out in the same article. ENISA receives the report at the same time (Art 14(7)). On top of that, Article 14(8) requires you to inform impacted users, “and where appropriate all users”. For context on the wider rulebook, see our Cyber Resilience Act compliance guide for manufacturers.

Nine cases, sorted into three outcomes

In plain terms: the same product can land in any of the three outcomes depending on one fact, which is whether there is evidence of hostile use or a compromise of the build and release chain.

#	Situation	Outcome	Deciding provision
1	A researcher reports a zero-day in your camera firmware through your bug bounty. No sign of use in the wild	C. Neither	Recital 68; Commission FAQ 5.2
2	Proof-of-concept code for your router’s CVE appears on GitHub. Your telemetry shows only scanning	C. Neither (monitor)	Art 3(41) vs 3(42)
3	A customer’s SOC sends logs showing an attacker used an authentication bypass in your VPN appliance to get in	A. Actively exploited vulnerability	Art 3(42); Art 14(1)
4	A library you ship appears in a known-exploited catalogue, but the vulnerable function is unreachable in your product	C for you. Report it upstream	Guidance para 218; Art 13(6)
5	Attackers breach your build server and ship a signed firmware update containing a backdoor	B. Severe incident	Art 14(5)(b); Recital 68
6	Your code-signing private key is stolen. No malicious update has shipped yet	B. Severe incident, on the “capable of leading to” wording	Art 14(5)(b)
7	Ransomware encrypts your HR file server. It has no link to build, signing, update or product cloud systems	C under the CRA. Check NIS2 and GDPR	Art 3(44)
8	A smart-meter model you stopped supporting in 2023 is being exploited in a botnet campaign	A. Actively exploited vulnerability	Art 69(3); guidance para 210
9	An injection flaw in your device-management cloud is used to push malicious configuration to customer fleets	A and B, so file on both tracks	Art 3(42) and Art 14(5)(b)

Three of these cases need a closer look.

Case 1 is spelled out in the Commission services’ CRA FAQ. A zero-day disclosed through a bug-bounty programme or found by a test laboratory “for which there is no evidence of previous malicious exploitation” is “not an actively exploited vulnerability subject to mandatory reporting” (FAQ 5.2). Your obligations here are coordinated disclosure and remediation. If you are setting that up, our guide on writing a vulnerability disclosure policy covers the intake side.

Case 6 is an interpretation, not settled law, and should be treated as one. A stolen signing key has not yet introduced malicious code anywhere. However, Article 14(5)(b) covers an incident that “is capable of leading to” that result, and a valid signing key in hostile hands is close to the textbook example. The guidance’s awareness wording for severe incidents (“has led to the security of its product … being compromised”, para 213) reads more narrowly than the statute. Where the two diverge, the binding text of Article 14(5) governs. Take legal advice if your facts are close to the line.

Case 9 shows why the tree runs both branches. The flaw in the cloud back-end is an exploited vulnerability in a product with digital elements, and pushing configuration to customer devices is the “introduction or execution of malicious code” in users’ systems. The two tracks then run on different final-report deadlines: 14 days after the fix for the vulnerability, and one month after the notification for the incident.

Known-exploited lists and third-party components

In plain terms: “exploited somewhere” is not the same as “exploited in your product”. A catalogue listing tells you to look. It does not, on its own, start your clock.

CISA’s Known Exploited Vulnerabilities (KEV) catalogue defines active exploitation almost word for word as the CRA does: “reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner”. Two differences matter, though. First, KEV deliberately counts attempted exploitation, including hits on honeypots. Second, it lists vulnerabilities at the component or CVE level, not by your product and version. KEV also excludes the same things the CRA excludes: scanning, security research and proof-of-concept code.

The Commission’s guidance settles the integrator question. If your product contains an actively exploited vulnerability from a third-party component, you must notify it. If the component flaw “cannot be exploited in its product” (for example, because the vulnerable code is not reachable) or “has not been exploited in its product”, it “is not subject to mandatory reporting for that manufacturer” (para 218). You still owe vulnerability handling under Annex I Part II and an upstream report to the component’s maintainer under Article 13(6). The component’s own manufacturer, if it placed that component on the market, also has to notify (FAQ 5.4).

The practical rule is this: a KEV entry, a CSIRT advisory or a vendor bulletin for a component you ship is a reason to start the initial assessment that day. Check reachability against your SBOM (our SBOM requirements guide covers the fields you need), then search your own telemetry and customer reports for exploitation of your product. The clock starts if that search reaches reasonable certainty.

The first 24 hours, by role

In plain terms: one person decides, one person files, and the board learns about it early. Penalties are high, but they apply only to late or missing filings.

Role	What they own in the first 24 hours
CISO / PSIRT lead	Run the decision tree, record the awareness timestamp and the evidence behind it, and identify the affected versions and the Member States where they are sold. Draft an early warning that stays minimal: the 24-hour stage only requires the Member State indication for exploited vulnerabilities. The fields for all six forms are mapped in our CRA vulnerability reporting template guide
Compliance / legal	Confirm the main-establishment CSIRT, check whether the same event is a significant incident under NIS2 Article 23 or a GDPR breach, and flag information that is sensitive for dissemination (Art 16(2)). Agree how users will be informed. The Commission says this is “risk-based and proportionate” and need not be public (guidance para 220)
Board / C-suite	Know the exposure. Breaching Article 14 can draw fines of up to €15,000,000 or 2.5% of worldwide annual turnover, whichever is higher (Art 64(2)). Approve the pre-delegated filing authority before it is needed
SME owner	Micro and small manufacturers are exempt from administrative fines for missing the 24-hour early warning only (Art 64(10)(a); Recital 120). The 72-hour notification and the final report remain enforceable, so the exemption is no reason to skip the procedure

Two operational traps are worth knowing in advance. If the platform is down, ENISA says to wait and submit once it is back. You may contact your CSIRT directly where immediate communication is necessary, but the platform submission is still required afterwards (FAQ 25). Log the outage with timestamps. And if you are both a manufacturer and an NIS2 entity, one compromise can trigger two filings with different final-report deadlines. Our article on zero-day exploits and the NIS2 24-hour clock covers that dual-filing case side by side.

Frequently asked questions

Does a published CVE start the CRA 24-hour clock?

No. Publication shows that a vulnerability exists. Article 3(42) requires reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. The clock starts when your initial assessment reaches a reasonable degree of certainty that this has happened to your product.

Do we have to report a zero-day found by our own bug-bounty programme?

Not under Article 14, provided there is no evidence of earlier malicious exploitation. The Commission services’ FAQ uses exactly this example. Handle it through coordinated disclosure and remediation. If exploitation evidence turns up later, awareness, and with it the 24-hour clock, starts then.

What if exploitation was only seen outside the EU?

The Article 3(42) definition contains no territorial limit. It refers to exploitation “in a system”. Where your product is on the EU market and the flaw is being exploited, the safer reading is that Article 14 applies, and the early warning names the Member States where the product has been made available.

Does the 24-hour deadline pause at weekends?

Article 14 sets the deadline “in any event within 24 hours” and provides no exception for weekends or public holidays. Plan an on-call filer with a working platform account, including deputies.

When does the 14-day final report clock start if we publish a workaround first?

Article 14(2)(c) runs the 14 days from when “a corrective or mitigating measure is available”. On that wording, a published mitigation can start the clock before the full patch ships. Log the release date of each measure.

Key takeaways

• The trigger is evidence of hostile use of a flaw in your product, assessed promptly to a reasonable degree of certainty. Publication, a proof-of-concept or a researcher report alone does not start the clock.
• A compromise of your build, signing or update chain belongs on the severe-incident track, and “capable of” is enough.
• A catalogue listing for a component starts your assessment, not your clock, unless the flaw is reachable and exploited in your product.
• Reporting covers legacy and unsupported products, and your own awareness timestamp, not the portal’s counter, is your legal deadline.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 2, 3, 13, 14, 15, 16, 17, 19, 20, 24, 64, 69 and 71, Recitals 68 and 120. Official Journal of the European Union (linked above).
• European Commission, Annex to C(2026) 5252 final, Commission guidance on the application of Regulation (EU) 2024/2847, 27 July 2026, section 9.1, paras 209–221 (linked above). Publication notice: Commission publishes new guidance to support timely Cyber Resilience Act implementation.
• European Commission services, FAQs on the Cyber Resilience Act, version 1.4, 4 September 2026, section 5 (linked above).
• ENISA, CRA Single Reporting Platform: Frequently Asked Questions, FAQ 25, 26 and 27 (linked above), and ENISA, Single Reporting Platform (SRP), including the version 1.1 upgrade of 12 October 2026.
• CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities (KEV catalogue criteria), cisa.gov/known-exploited-vulnerabilities.
• Commission Implementing Regulation (EU) 2024/2690, Recital 31 (linked above).
• Directive (EU) 2022/2555 (NIS2), Articles 6(6) and 23 (linked above).