Back to all articles
Reporting5 September 20265 min read

The Single Reporting Platform opens Friday: what to have ready before your first CRA filing

ENISA's SRP is scheduled to go live on 11 September 2026 - the same day the reporting duty starts. Five things to have in place before then, and what to do if the portal stumbles.

Written 5 September 2026. The platform details below come from ENISA's published SRP guidance and may change at launch; this article will be updated once the platform is live. Practical guidance, not legal advice.

This Friday, 11 September 2026, the Cyber Resilience Act's reporting obligations start: 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 will file through - ENISA's Single Reporting Platform - is scheduled to become operational the very same day.

That timing has a practical consequence: there is no practice window. The first time most manufacturers see the filing screen will be the day the duty is already live. What you can do is make sure everything on your side of the screen is ready before Friday.

What ENISA has actually said about the platform

  • The platform is scheduled to be operational by 11 September 2026, and reports from that date onwards go 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 states they will not prevent you from submitting.
  • User guidance for registration and submission, a helpdesk, and training materials have been promised around launch.

Five things to have ready before Friday

  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 - it is the one step with zero excuse to leave for launch day.
  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 - better on Tuesday than on the day.

If the platform stumbles on day one

The legal duty attaches on 11 September regardless of 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 - your EU importer or distributor cannot carry it for you - and it concerns products you already have on the EU market, not only the ones you ship after Friday.

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.