Your first CRA filing through the Single Reporting Platform: what to have ready

Written 5 September 2026, before the platform's scheduled launch on 11 September, and revised on 25 September 2026 so that it no longer speaks of that date as ahead. The platform details below come from ENISA's published SRP guidance as it stood when this was written and may have changed since, so check ENISA's current guidance before you rely on them. Practical guidance, not legal advice.

Since 11 September 2026 the Cyber Resilience Act's reporting obligations have applied: an actively exploited vulnerability in your product, or a severe incident affecting its security, puts you on a fixed clock that begins with a 24-hour early warning. The portal you file through, ENISA's Single Reporting Platform, was scheduled to become operational the same day.

That timing had a consequence that still holds: there was no practice window. Unless you have filed already, the first time you see the filing screen may be the day a real report is due. What you can do now is make sure everything on your side of the screen is ready.

What ENISA said about the platform before launch

• The platform was scheduled to be operational by 11 September 2026, with reports from that date onwards going through it to ENISA and the relevant national CSIRT.
• Access requires an EU Login account, the European Commission's standard sign-in, created at ecas.ec.europa.eu.
• CSIRT validation of your organisation happens after your first access to the platform, in parallel with reporting. Validation procedures vary by CSIRT, but ENISA stated they would not prevent you from submitting.
• User guidance for registration and submission, a helpdesk and training materials were promised around launch. Check what ENISA has published since.

Five things to have ready before your first filing

1. A named owner and a backup, each with a working EU Login account. Creating the account takes minutes and needs no approval from anyone, so it is the one step with no excuse to leave for the day a report is due.
2. The decision test, written down: the two triggers (an actively exploited vulnerability; a severe incident affecting the product's security) and who makes the report/no-report call when it is 2am on a Saturday. Our CRA reporting playbook walks through the thresholds in detail.
3. A pre-filled skeleton for the 24-hour early warning: product name and versions, manufacturer contact details, and a short description field. The early warning demands far less than teams assume: it is a flare, not an analysis. You do not need root cause, a fix, or a complete picture inside 24 hours.
4. The path onto the later steps: who owns the fuller 72-hour notification, and who owns the final report once a fix is available. Names and calendars, not roles on paper.
5. One dry run. Walk a mock actively exploited vulnerability end to end, on a timer, before the timer is real. Every team that does this finds at least one missing piece, and a rehearsal is the cheap place to find it.

If the platform fails when a report is due

The legal duty applies whatever the portal's state: the obligation is in the regulation, not in the software. If a real trigger hits and you cannot file through the platform, document the attempt with timestamps, keep the completed report ready, notify the relevant CSIRT through its published contact channels, and submit through the platform as soon as it accepts reports. What you must not do is treat a portal problem as a pause button.

One more thing non-EU teams keep missing: the duty sits on the manufacturer, and your EU importer or distributor cannot carry it for you. It covers products you already have on the EU market, not only the ones you ship from now on.

How exposed are you right now? The free 24-hour test on this site takes twelve questions and no signup, and tells you which of the capabilities the clock assumes you already have are actually in place.