Does This Trigger a CRA Report? How to Identify an Actively Exploited Vulnerability and a Severe Incident Under Article 14

The 11 September 2026 CRA reporting deadline is now fewer than 45 days away. On 27 July 2026, the European Commission published new practical guidance to help manufacturers meet their obligations - and among the things it clarifies is how to meet the reporting requirements. That makes now the right moment to answer the question that matters most operationally: does this event require me to file a report?

This post focuses on the trigger definitions - what an actively exploited vulnerability and a severe incident actually mean under Regulation (EU) 2024/2847, and how to run the "do I have to report this?" decision in practice. It does not re-explain the ENISA Single Reporting Platform mechanics (see our SRP guide) or how to write a CVD policy (see our CVD policy guide).

General guidance, not legal advice. This article explains the regulation as published. It is not a substitute for legal advice tailored to your organisation's specific circumstances.

---

Key points

• Article 14 of Regulation (EU) 2024/2847 requires manufacturers to report actively exploited vulnerabilities and severe incidents from 11 September 2026 - before the rest of the CRA applies in full on 11 December 2027.
• There are two distinct report types, each with its own definition and clock.
• The trigger is not a CVSS score, a CVE publication, or a researcher's proof-of-concept. It is evidence of actual malicious use.
• A vulnerability you discover and patch before anyone exploits it is not reportable under Article 14 - it is handled through your ordinary vulnerability process.
• The clock runs: early warning within 24 hours, full notification within 72 hours, final report within 14 days of a corrective measure being available (for actively exploited vulnerabilities) or within one month for severe incidents.
• Failing Article 14 sits in the top CRA fine tier: up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

---

What you must report - and what you don't

Article 14 creates two and only two reportable event types. Everything else - vulnerabilities you find in testing, CVEs in your dependency tree that are not being exploited, researcher disclosures with no evidence of malicious use - is handled through your vulnerability-handling process, not the Article 14 clock.

Event	Reportable under Article 14?	Clock
Actively exploited vulnerability in your product	✅ Yes	24h / 72h / 14 days
Severe incident having an impact on the security of the product	✅ Yes	24h / 72h / 1 month
Vulnerability discovered in testing, no exploitation evidence	❌ No	Vulnerability-handling process
CVE published for a component you ship, no exploitation evidence	❌ No	Vulnerability-handling process
Researcher reports a flaw, no evidence of malicious use	❌ No	Vulnerability-handling process
Proof-of-concept published, no confirmed exploitation	❌ No	Monitor; reassess if exploitation confirmed

---

What "actively exploited vulnerability" actually means

This is the definition that matters most, and it is precise.

The CRA defines an "actively exploited vulnerability" as 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(42), Regulation (EU) 2024/2847).

Three things follow from that definition.

1. The standard is reliable evidence, not certainty. You do not need a forensic report or a court-admissible chain of evidence. You need credible, reasonable grounds to believe exploitation has occurred. Unusual access patterns consistent with a known exploit technique, a SIEM alert showing your product was used as an entry point, or a customer report of a confirmed breach in which your product played a role - all of these can be sufficient.

2. The trigger is actual malicious use, not potential. A published CVE, a working proof-of-concept, or a researcher demonstrating exploitability does not start the clock on its own. Active exploitation means a malicious actor has used the flaw against a real target without the system owner's permission. Appearance on CISA's Known Exploited Vulnerabilities (KEV) catalogue is a strong signal, but the trigger is broader: a vulnerability being exploited against your customers that has not yet reached KEV can still require a report. The determination is factual, not list-based.

3. It does not matter whether the vulnerability is publicly known. A zero-day being silently exploited in the wild is just as reportable as a well-documented CVE that someone is now actively using. The distinction is exploitation, not disclosure status.

What "becoming aware" means - and why it matters

The 24-hour clock starts when you become aware of the actively exploited vulnerability. That is the moment your organisation has information indicating that exploitation has occurred - not when you have completed a full investigation.

Awareness can arrive through multiple channels:

• A security researcher reports active exploitation to your vulnerability disclosure inbox.
• Your monitoring matches a component in your SBOM against a feed showing confirmed exploitation in the wild.
• A customer's SOC team contacts you with evidence that your product was the attack vector.
• Your own telemetry surfaces anomalous behaviour consistent with a known exploit.

The clock does not wait for you to finish triage. It starts when credible information arrives.

---

What counts as a "severe incident"

The second reportable event type is an incident having an impact on the security of the product with digital elements.

Under Article 14(5) of the CRA, an incident is severe where it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity, or confidentiality of data or functions - or where it has led to, or is capable of leading to, the introduction or execution of malicious code in the product or in a user's network and information system.

A few practical examples of what this can cover:

• Supply-chain compromise: malicious code introduced into your build pipeline or update mechanism.
• Credential theft at scale: a breach of your authentication infrastructure that exposes user credentials across your product's user base.
• Integrity failure: an attacker modifying firmware or software in a way that affects the product's security functions, even if no data has yet been exfiltrated.

Note the phrase "capable of negatively affecting." The incident does not need to have caused confirmed harm. If the security impact is plausible given what you know, the threshold is met.

The severe-incident track and the actively-exploited-vulnerability track can overlap. A supply-chain attack that introduces a backdoor is both a severe incident and, once the backdoor is used, an actively exploited vulnerability. In practice, file under the track that fits best and note the overlap in your notification.

---

The 24 / 72 / 14 clock

Once a trigger event occurs, the reporting timeline is fixed. There is no discretion on the deadlines.

---

Where the report goes

Reports are filed through ENISA's Single Reporting Platform (SRP). You file once; the platform routes your submission to your relevant national CSIRT and to ENISA simultaneously.

The SRP is scheduled to be operational by 11 September 2026, with a testing period expected before that date. As of late July 2026, the platform's go-live readiness is still developing - monitor ENISA's SRP page for registration and dry-run materials. For the full mechanics of how the platform works and how reports flow, see our ENISA Single Reporting Platform guide.

---

Who gets relief

Not everyone faces the same enforcement exposure for a missed deadline.

Micro and small enterprises. Under Article 64(10) of the CRA, manufacturers that qualify as microenterprises or small enterprises cannot be fined for missing the 24-hour early-warning deadline. This is a narrow, specific relief: it covers only the fine for missing the 24-hour window. The obligation to report still applies in full. The 72-hour notification and the final report carry no equivalent relief. Non-financial enforcement actions - corrective orders, product withdrawals, public notices - remain available to market surveillance authorities regardless of company size.

Open-source software stewards. Article 64(10) explicitly exempts open-source software stewards from administrative fines for CRA infringements. Stewards operate under the lighter Article 24 regime rather than the full manufacturer obligations. They are not manufacturers and cannot be fined - but they do have their own reporting and cooperation duties.

Medium and large manufacturers. No relief. A missed 24-hour early warning is a Tier 1 infringement. See our penalties guide for the full fine structure.

---

How to get ready before 11 September 2026

The deadline is fewer than 45 days away. These are the steps that matter most right now.

1. Assign a named reporting owner - today. Someone in your organisation needs to be authorised to file an Article 14 report at any time, including weekends and public holidays. Define a backup. Write it down.

2. Define your "aware" trigger precisely. Agree internally on what constitutes awareness for your product and your monitoring setup. Which feeds do you watch? What alert level starts the clock? Document the decision. Ambiguity at 2am costs you hours you do not have.

3. Know what is in your products. You cannot report on a component you did not know you shipped. Maintain an accurate software bill of materials (SBOM) and match it against exploitation feeds continuously. A vulnerability being exploited against your customers that has not yet reached a public list can still trigger the duty.

4. Pre-draft your early-warning template. The 24-hour report does not need to be detailed - it needs to be filed. Draft a template now: product name, affected versions, nature of the event, current status. Fill in the blanks under pressure, not the structure.

5. Wire your detection to the clock. When a monitoring alert fires, the clock may already be running. Make sure your detection pipeline has a clear escalation path to the person who files SRP reports. A researcher report that confirms active exploitation in the wild starts the Article 14 clock - make sure your CVD intake has that escalation path too. See our CVD policy guide for how to structure it.

6. Register on the SRP as soon as it opens for testing. Do not wait until 11 September to log in for the first time. Watch ENISA's SRP page for the testing window and register early.

7. Check the Commission's new guidance. The 27 July 2026 guidance is non-binding but clarifies how the Commission expects the reporting obligations to work in practice, including for SMEs. Read the reporting section.

---

Where to go next on CRA Facts

• Deadlines at a glance: every confirmed CRA date is on the CRA deadlines page.
• SRP mechanics: how reports flow through the platform - ENISA Single Reporting Platform guide.
• CVD policy: structuring your coordinated vulnerability disclosure process - CVD policy guide.
• Penalties: the full fine tier structure and what authorities can do - CRA penalties guide.