HECAVEX Labs / CRA reporting triageOfficial regulation ↗
Lab 03 · regulatory triage

CRA reporting starts with facts, not a timer.

A private, browser-only checklist for preparing an Article 14 discussion. It helps separate an actively exploited vulnerability from a severe product-security incident and surfaces the corresponding reporting sequence.

Not legal advice. This tool does not determine scope, severity, liability or whether a report is legally required. It stores and sends nothing. Consult Regulation (EU) 2024/2847, current ENISA guidance, the relevant CSIRT and qualified counsel.
Triage questions

What is known right now?

1. Is the organisation acting as a manufacturer of the product with digital elements—or an open-source software steward where the CRA duty applies?
2. Is the affected product within CRA territorial and product scope?
3. Is there reliable evidence that a malicious actor exploited the vulnerability?
4. Did an incident negatively affect the product’s ability to protect availability, authenticity, integrity or confidentiality, and could its impact meet Article 14(5)?
If the duty applies

Two reporting tracks

Actively exploited vulnerability

Early warning without undue delay and within 24 hours of awareness. Vulnerability notification within 72 hours. Unless already supplied, final report no later than 14 days after a corrective or mitigating measure is made available.

Severe incident

Early warning without undue delay and within 24 hours of awareness. Incident notification within 72 hours. Unless already supplied, final report within one month after the incident notification.

Reporting route

Article 16 establishes ENISA’s Single Reporting Platform. ENISA says mandatory CRA reporting begins on 11 September 2026. Always use the current official guidance.

Primary sources

Read before relying

  1. Regulation (EU) 2024/2847, especially Articles 14–17 ↗
  2. ENISA Single Reporting Platform guidance ↗
  3. HECAVEX analysis of Article 14 reporting ↗