Kilde › Guides › CRA › “Actively exploited vulnerability” vs …

“Actively exploited vulnerability” vs “severe incident”: the two triggers, precisely

Current to 26 August 2026 · updates land in the changelog.

Everything in the CRA's reporting machine hangs off two defined triggers. Get the trigger analysis wrong and you either miss a mandatory 24-hour clock or file reports the law never asked for — both expensive in their own way.

Trigger one: actively exploited vulnerability

An actively exploited vulnerability is one where there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner (Article 3(42)). Three load-bearing elements: reliable evidence, actual exploitation, absence of permission.

The neighbouring defined term is the trap: an exploitable vulnerability (Article 3(41)) — one that can be exploited — does not trigger Article 14 reporting by itself. A pen-test finding or a scary CVSS score creates vulnerability-handling work under Annex I Part II, but the 24-hour reporting clock starts only when exploitation is actually happening.

Trigger two: severe incident impacting product security

Article 14(5) defines a severe incident having an impact on the security of the product as one that: (a) negatively affects — or is capable of negatively affecting — the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or (b) has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user.

Note the reach of “capable of”: both limbs cover credible near-misses, not only materialised harm. That makes the severity assessment a judgement call worth pre-structuring — a written triage worksheet beats an ad-hoc call at 2 a.m.

Why the track choice matters downstream

The two tracks share the 24-hour and 72-hour rhythm but diverge at the final report — 14 days after a corrective measure is available on the vulnerability track, one month after the 72-hour notification on the incident track — and their required content differs at every stage. Triage is therefore not paperwork: it decides your deadlines.

Quick answers

Does a merely exploitable vulnerability trigger CRA reporting?

No. The reporting trigger is an actively exploited vulnerability — reliable evidence that a malicious actor has exploited it without the system owner's permission (Art 3(42)). Exploitable-but-not-exploited findings feed the vulnerability-handling duties instead.

What makes an incident 'severe' under the CRA?

Under Art 14(5): it negatively affects or is capable of negatively affecting the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or it has led or is capable of leading to the introduction or execution of malicious code in the product or a user's systems.

General information only — not legal advice, and never a conformity assessment. Whether a specific product falls in a listed category is decided against the binding technical descriptions in Implementing Regulation (EU) 2025/2392, and reporting-platform mechanics are ENISA-published material marked subject to change. Sources are Regulation (EU) 2024/2847 (CELEX 32024R2847; Annex III/IV item texts read verbatim from EUR-Lex) and our audited kit research. © 2026 Kilde.

Built by Kilde's founder, a practising attorney admitted to a US state bar (not an EU or Hong Kong admission). About · Verification log · Refunds · Terms · Privacy · esau@trykilde.com