CRA Article 14: actively exploited vulnerability vs severe incident

Recital 68’s dual path

Recital 68 explains why Article 14 names two categories. Actively exploited vulnerabilities concern instances where a manufacturer establishes that a security breach affecting its users or any other natural or legal persons has resulted from a malicious actor making use of a flaw in one of the products with digital elements made available on the market by the manufacturer. Examples include weaknesses in a product’s identification and authentication functions. Findings discovered with no malicious intent for good-faith testing, investigation, correction or disclosure should not be subject to mandatory notification.

Severe incidents having an impact on the security of the product, on the other hand, refer to situations where a cybersecurity incident affects the development, production or maintenance processes of the manufacturer in such a way that it could result in an increased cybersecurity risk for users or other persons. The Recital’s example: an attacker successfully introducing malicious code into the release channel via which the manufacturer releases security updates to users.

Operational shorthand used on the desk: product-flaw exploitation against systems → start with the AEV guide; build / sign / ship / maintain pipeline compromise → start with the severe-incident guide. Recital 68 is guidance for classification; the legal tests are Article 3(42) (AEV) and Article 14(5) (severe).

Legal tests — do not skip them

AEV (Article 3(42)): a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. No reliable malicious-exploitation evidence → not mandatory Article 14(1); see zero-days / FAQ 5.2 and Article 15 voluntary reporting.

Severe incident (Article 14(5)): either the incident negatively affects, or is capable of negatively affecting, the product’s ability to protect 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 in a user’s network and information systems. “Capable of” means actual user harm is not required — a compromised signing key can already be severe.

Same 24h / 72h shape — different finals

Both tracks run an early warning within 24 hours of becoming aware and a fuller notification within 72 hours (Article 14(2)(a)–(b) vs 14(4)(a)–(b)). See reporting deadlines and becoming aware. The trap is the close-out:

• AEV final (Article 14(2)(c)): no later than 14 days after a corrective or mitigating measure is available — separate from awareness. Details: corrective or mitigating measure.
• Severe final (Article 14(4)(c)): within one month after the 72-hour incident notification. Mitigation appears as content (“applied and ongoing mitigation measures”), not as the clock start. Details: final report.

ENISA’s Single Reporting Platform receives both tracks; it does not choose the track for you. If the CSIRT later asks for status under Article 14(6), that intermediate request does not rewrite either final — see the intermediate-report guide.

The trap: pick one wrong final

Three failure modes show up in triage. First: the team treats every product-security event as “the NIS2-style one-month final” and misses the AEV measure-available + 14-day limb. Second: the team treats a poisoned build or update channel as an AEV and waits for a “corrective measure” that never looks like a product CVE patch — while Article 14(4)(c) was already running from the 72-hour incident notification. Third: the team refuses to start either chain until counsel finishes a dual-label memo — meanwhile the shared 24-hour early warning is already live from awareness. Write the track choice, the awareness time, and (for AEV) the measure-available time into the evidence log, then run the clocks.

Questions people ask

Can one event be both an actively exploited vulnerability and a severe incident?

The same facts can look like both at first glance. Recital 68 draws two pictures: an AEV is a malicious actor using a flaw in a product you made available on the market to breach users or others; a severe incident is a cybersecurity incident that affects your development, production or maintenance processes so that cybersecurity risk for users could rise (example: malicious code in the security-update release channel). Article 14 treats them as separate notification duties under paragraphs 1–2 and 3–4. Record which track you chose and why — the final-report clock depends on it. If counsel says both limbs truly apply, run both calendars; do not invent a single blended final.

What does Recital 68 say about the two tracks?

Actively exploited vulnerabilities concern instances where a manufacturer establishes that a security breach affecting its users or any other natural or legal persons has resulted from a malicious actor making use of a flaw in one of the products with digital elements made available on the market by the manufacturer. Vulnerabilities discovered with no malicious intent for good-faith testing, investigation, correction or disclosure should not be subject to mandatory notification. Severe incidents having an impact on the security of the product, on the other hand, refer to situations where a cybersecurity incident affects the development, production or maintenance processes of the manufacturer in such a way that it could result in an increased cybersecurity risk for users or other persons — for example an attacker successfully introducing malicious code into the release channel used for security updates.

When is the final report due on each track?

Actively exploited vulnerability (Article 14(2)(c)): no later than 14 days after a corrective or mitigating measure is available — not from awareness. Severe incident (Article 14(4)(c)): within one month after the 72-hour incident notification under Article 14(4)(b). Both tracks still share a 24-hour early warning and a 72-hour notification from becoming aware. Mixing the finals — treating an AEV as “one month after 72h” or a severe incident as “measure available + 14 days” — invents a deadline the Regulation does not impose.

Do the early-warning and 72-hour contents differ?

Yes. Article 14(2)(a)–(b) (AEV) ask for product / Member State availability, then general information about the product, the nature of the exploit and of the vulnerability, and corrective or mitigating measures taken or available to users. Article 14(4)(a)–(b) (severe) ask whether the incident is suspected of being caused by unlawful or malicious acts, then general information about the nature of the incident, an initial assessment, and corrective or mitigating measures. The SRP fields look similar; the legal fields and the final clock do not. Use the case-type switch in the desk or calculator so drafts and countdown match the track.

Is a compromised update pipeline an AEV or a severe incident?

Recital 68’s severe-incident example is exactly that shape: an attacker successfully introducing malicious code into the release channel via which the manufacturer releases security updates to users. That points at Article 14(3)–(4) and Article 14(5)’s malicious-code limb, not at “a flaw in the product’s identification and authentication functions” as the Recital’s AEV illustration. If the same campaign later exploits a product flaw in user systems with reliable evidence under Article 3(42), that second fact pattern can open the AEV track — record both awareness moments separately.

When did these duties start to apply?

Article 14 has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)). The dual-path choice and the two final clocks are live now — they are not part of the December 2027 Annex I conformity package.