The CRA Reporting Clock: What to Report, and How to File It

The EU Cyber Resilience Act's reporting duty goes live 11 September 2026. Here is exactly what triggers a report, the 24-hour / 72-hour / final-report clock, and how to actually file through ENISA's Single Reporting Platform.

CRA & Compliance
Sep 9, 2026
Diagram showing what triggers a CRA report, an actively exploited vulnerability or a severe incident, and the 24-hour, 72-hour, and final-report timeline

From 11 September 2026, two days from today, the EU Cyber Resilience Act's reporting duty is live. The conformity-route question, self-assessment versus notified body, is a separate decision manufacturers make once. Reporting is different: it is a clock that starts the moment you become aware of one of two specific things, and it runs whether or not you were ready for it. This is what actually has to happen, and where.

What triggers the clock

Only two categories of event trigger a mandatory report. An actively exploited vulnerability (Article 3(42), Article 14(1)) requires credible evidence that a malicious actor is actually exploiting it, a published CVE or proof-of-concept with no observed exploitation does not count on its own. A severe incident (Article 3(44), Article 14(5)) requires the incident to actually affect the product's own confidentiality, integrity, or availability, or lead to malicious code execution, an external breach or ransomware event that never touches the product's own security is not automatically reportable. Routine bug fixes and vulnerabilities caught before exploitation stay inside normal vulnerability handling, no report needed.

The three-stage clock

Every report is one continuing record, built up in three stages, not three separate filings. All three deadlines count from the moment your organisation becomes aware, not from when the platform logs your submission.

Within 24 hours: early warning. The minimum viable notice, notification type, manufacturer name, the product affected, a title, and for incidents whether malicious intent is suspected.

Within 72 hours: notification. A fuller picture, the general nature of the vulnerability or incident, your initial assessment, any corrective measures already taken, and what users should do in the meantime.

Final report. For vulnerabilities, no later than 14 days after a corrective or mitigating measure becomes available. For severe incidents, within one month of the 72-hour notification. This stage carries the full description, severity, impact, and remediation detail.

Where you actually file it

Everything runs through ENISA's Single Reporting Platform (SRP), mandatory from 11 September 2026. A few practical points worth knowing before you need it under pressure:

You cannot file as a company directly, only a registered Assigned Representative can. One Primary Assigned Representative sets up the manufacturer's account with an EU Login (ecas.ec.europa.eu, MFA required) and selects the coordinating national CSIRT, additional Secondary Assigned Representatives can be added afterwards. That CSIRT then validates the manufacturer association, but this happens in parallel with reporting, validation does not have to finish before you can submit a real notification.

Once submitted, the record goes simultaneously to ENISA and to your coordinating CSIRT (determined by where your main EU establishment is, BSI in Germany's case), which is then responsible for passing it on to other affected member states' CSIRTs and market surveillance authorities. In practice this means one filing, not one per country, but it is your coordinating CSIRT doing the onward distribution, not an automatic broadcast.

There is no API at launch. Submission is a manual browser form on the SRP, which is worth budgeting real time for if an incident actually happens.

What this means for engineering teams this week

Get your Assigned Representative registered now, with a working EU Login and MFA set up, rather than during an actual incident when every hour already counts. Keep your own internal log of exactly when your team became aware of an issue, since that timestamp is the legal start of the clock, the platform's own counters are not the authority on it. And remember this applies to products already on the market today, there is no grandfathering on the reporting duty specifically, even for product lines that predate the CRA.

This is exactly the operational load Nord CS built Aitigrity to carry. Aitigrity connects continuous monitoring to the reporting workflow itself, so an actively exploited vulnerability or severe incident moves from detection to a drafted 24-hour notice without someone reconstructing the timeline from memory at 2am. Run your product through Nord CS's free CRA Scope and Classification Check to see where it lands, or contact Nord CS directly with questions about your specific product or reporting setup.

Sources:

European Commission, Cyber Resilience Act reporting obligations

cyberresilienceact.eu, CRA incident and vulnerability reporting (24h/72h/14-day)

ENISA, Single Reporting Platform

ENISA, Single Reporting Platform — Frequently Asked Questions

more

CRA & Compliance
Sep 8, 2026

The CRA's Conformity Routes, and Who Enforces Them

Ready to Secure Your Future? Contact Us Today

contact us

Bereit, Ihre Zukunft zu sichern? Kontaktieren Sie uns heute

KONTAKTIEREN SIE UNS