What does the CRA actually require you to report, and when?
The Cyber Resilience Act (Regulation (EU) 2024/2847) obliges manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents to their coordinating CSIRT and to ENISA. From 11 September 2026, three notifications are due: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days.
- ▸The reporting duties in Article 14 apply from 11 September 2026, roughly 15 months before the bulk of CRA obligations land on 11 December 2027.
- ▸You file through the ENISA single reporting platform (Article 16), which routes to the CSIRT designated as coordinator in the relevant Member State and to ENISA simultaneously.
- ▸Two triggers exist: an actively exploited vulnerability (reliable evidence an actor executed malicious code without permission) and a severe incident affecting the security of the product.
- ▸Voluntary notifications are allowed, and onward dissemination can be delayed on justified security grounds.
This piece complements our timeline overview in The Cyber Resilience Act Countdown: September 2026 Is the Real Deadline; here we focus on the pipeline that turns detection into a filed notification.
When does the reporting clock start under the CRA?
The 24-hour clock starts when the manufacturer becomes aware of an actively exploited vulnerability or a severe incident. Awareness is an organisational fact, not one engineer's hunch: it is the moment your triage has reliable evidence. Define that threshold in writing before 11 September 2026, or you will argue about it mid-incident.
- ▸Regulators read becoming aware as the point where you have reasonable grounds to believe a trigger is met, not the first ambiguous alert.
- ▸Build an explicit awareness decision into triage: who declares it, on what evidence, logged with a timestamp. That timestamp anchors all three deadlines.
- ▸Sources of awareness include your PSIRT intake, coordinated disclosure reports, telemetry from deployed products, exploitation intelligence (for example CISA's KEV catalog), and downstream reports from integrators.
- ▸Because the deadlines are wall-clock hours that include weekends, you need follow-the-sun on-call and a named deputy who can act without waiting for Monday.
How do you instrument detection so you know within 24 hours?
Instrument three layers: know what you ship (SBOM), watch for exploitation of what you ship (vulnerability and KEV/EPSS correlation), and give the outside world a fast channel to tell you (coordinated disclosure). The 24-hour deadline is only survivable when awareness is automated, not accidental.
- ▸Software Bill of Materials: generate a CycloneDX or SPDX SBOM per release so a new CVE maps to affected products in minutes, not days.
- ▸Continuous vulnerability correlation: feed CVE data, the CISA KEV catalog, and EPSS scores into a system that matches them against your SBOM inventory and flags actively exploited components.
- ▸Coordinated Vulnerability Disclosure: publish a security.txt and a CVD policy aligned with ISO/IEC 29147; many actively-exploited facts arrive from researchers, not your own telemetry.
- ▸Product telemetry: crash signatures, integrity violations, and anomalous authentication events from deployed devices are often your earliest exploitation signal.
For the upstream half of this problem, see The Software Supply Chain in 2026: SBOMs, Provenance, and the CRA Reckoning.
What goes in the 24-hour, 72-hour, and 14-day notifications?
The 24-hour early warning is deliberately thin: state that an actively exploited vulnerability or severe incident exists and, for incidents, whether malice is suspected. The 72-hour notification adds nature, initial assessment, and mitigations. The 14-day final report describes severity, impact, any known threat actor, and the fix shipped.
- ▸24 hours (early warning): minimal facts, the existence of the trigger, affected Member States where known, and for incidents whether unlawful or malicious acts are suspected.
- ▸72 hours (notification): general information about the product, the nature of the exploit or incident, an initial severity assessment, and corrective or mitigating measures taken or available to users. Flag how sensitive the information is.
- ▸14 days (vulnerability final report): a description with severity and impact, information on any malicious actor exploiting it, and the security update or corrective measure made available.
- ▸For severe incidents, the final report is due within one month of the 72-hour notification, covering root cause, severity, impact, and mitigations.
- ▸Use CVSS v4.0 for severity, and consider machine-readable advisories in CSAF 2.0 with VEX so users learn precisely what is and is not affected.
How do you build the PSIRT and decision path behind the pipeline?
A CRA pipeline is a PSIRT (Product Security Incident Response Team) with authority to declare awareness, draft notifications, and file under deadline. Align it to ISO/IEC 30111 for vulnerability handling. The scarce resource is not detection, it is a rehearsed decision path with named owners and legal sign-off pre-negotiated.
- ▸Define roles: incident commander, technical lead, a regulatory liaison who files to ENISA, legal and comms, and an executive approver with a standing mandate to authorise filings.
- ▸Pre-agree decision criteria: what counts as actively exploited, what counts as severe, and the fallback when evidence is ambiguous. Filing an early warning is low-cost; missing a deadline is not.
- ▸Write runbooks per trigger and rehearse them in tabletop exercises with the clock running.
- ▸Keep legal review pre-authorised; waiting for outside counsel burns the 24-hour window.
The mechanics overlap with security incident handling generally, covered in Incident Response Playbooks That Teams Actually Use, and with the parallel 24/72 cadence in NIS2 in 2026: Turning the Directive into an Engineering Backlog.
Which tools and artifacts make the pipeline auditable?
Auditors and CSIRTs want artifacts, not assurances. Keep an immutable case record per event, the SBOM for each affected release, the awareness timestamp, the three notifications with submission receipts, and the CSAF/VEX advisory. Version-control your policies so you can prove the process existed before the incident.
- ▸Case management: one ticket per event with an append-only timeline, evidence, and every notification version.
- ▸Artifacts to retain: SBOMs (CycloneDX/SPDX), CVSS v4.0 scoring, KEV/EPSS evidence of exploitation, ENISA platform submission receipts, and the published advisory (CSAF 2.0 / VEX).
- ▸Policy as versioned docs: your CVD policy, vulnerability handling (ISO/IEC 30111), and disclosure process (ISO/IEC 29147), each dated and change-controlled.
- ▸Metrics: time-to-awareness and time-to-file, tracked so you can prove and improve deadline performance under scrutiny.
What are the most common ways CRA reporting pipelines fail?
They fail on the human clock, not the technical one. The classic failures are an undefined awareness moment, no weekend on-call, legal review that outlasts the 24-hour window, an SBOM that cannot map a CVE to a product, and treating ENISA platform access as something to discover during a real incident.
- ▸No awareness definition: the deadline silently starts and you notice late.
- ▸SBOM gaps: you cannot answer quickly whether a vulnerable component ships in a specific product.
- ▸Single-region on-call: a Friday-night disclosure blows the Saturday deadline.
- ▸Legal bottleneck: sign-off was never pre-authorised.
- ▸Untested platform access: nobody has actually filed to the ENISA platform before the first real event.
How TuniCyberLabs helps
We build the whole path from detection to filing: SBOM generation in CI, CVE/KEV/EPSS correlation to your product inventory, a PSIRT runbook aligned to ISO/IEC 29147 and 30111, CSAF/VEX advisory tooling, and rehearsed 24/72/14 timelines your team can hit before 11 September 2026. Always confirm the current legal text and dates against the official EUR-Lex publication. Talk to our engineers about a CRA reporting readiness review.