From 11 September 2026, Article 14 of the EU Cyber Resilience Act applies. If an actively exploited vulnerability turns up in a product you have placed on the EU market, you have 24 hours. Not 24 hours to fix it — 24 hours to tell a regulator it exists.
Those notifications go to one place: ENISA's Single Reporting Platform (SRP), which became operational on the same day. We put together a 37-second walkthrough of it. Watch it, then read on — three things catch manufacturers out, and none of them is obvious from the portal itself.
1. ENISA does not want you to pre-register
The instinct is to create the account now, as a readiness milestone. ENISA asks you not to. To keep the validation queue at the national CSIRTs clear for real events, manufacturers “are advised to register and initiate the validation process only when they need to submit a notification.” Provided the person filing already has an EU Login account, registration on the platform takes a few minutes.
So the readiness work is not the account. It is everything the account depends on, which is the list at the end of this post.
2. Registering is not complying
The mirror-image mistake: assuming that an account, once validated by your CSIRT, is what discharges the duty. It is not. ENISA's registration guidance states that validation of an Assigned Representative happens after registration and “is not a prerequisite for submitting a notification.” The FAQ adds that verification “does not prevent an AR from submitting notifications while validation is pending” — up to twenty of them before verification becomes mandatory.
The obligation is the filing, on the clock, when a reportable event happens. An account on the platform proves nothing on its own.
3. The coordinator is the part you cannot fix under pressure
Your notification routes to the CSIRT designated as coordinator (CDaC) for the Member State of your main establishment — under the CRA, “the place where decisions related to the cybersecurity of your products with digital elements are predominantly taken.” If that cannot be determined, it is the Member State where your largest EU establishment by headcount sits; if you have no EU establishment at all, a further ordering applies based on your authorised representative.
ENISA is direct about the cost of choosing wrong: “If the wrong CDaC is selected, the notification may be invalidated and will need to be resubmitted to the correct CDaC.” For a multinational with engineering in one country, a holding company in another and product decisions taken in a third, that is a question to answer in writing now, not at 2am with the 24-hour clock running.
The clocks, and what the platform shows you
Two event types are reportable: an actively exploited vulnerability in your product, and a severe incident having an impact on the security of the product. Each starts a sequence of deadlines from the moment you become aware:
- 24 hours — early warning.
- 72 hours — notification, with general information and an initial assessment.
- 14 days after a corrective or mitigating measure becomes available — final report, for an actively exploited vulnerability.
- 1 month after the 72-hour notification — final report, for a severe incident.
The notification reaches your CSIRT coordinator and ENISA together. The platform then tracks each filing through six dashboard queues: All, Needs Submission, Corrective Measures Required, Closed (Previously Valid), Closed (Previously Invalid), and Draft. “Needs Submission” is where your open obligations sit. The platform also runs counters for the 72-hour notification and the final report, with reminder emails and overdue alerts — but ENISA is clear that they “do not replace the responsibility” to report within the Article 14 timelines, and in the current release the 72-hour counter is measured from the early warning rather than from when you became aware. Keep your own clock.
What is worth doing before anything happens
None of this requires an account on the platform. All of it takes longer than 24 hours to sort out once the clock is running.
- EU Login accounts with multi-factor authentication for the people who would file. Accounts are personal, never shared — enable MFA before you need it, not during an incident.
- A written decision on your main establishment. Which Member State, and why. Circulate it beyond the compliance team.
- Named Assigned Representatives. One Primary, who registers the manufacturer and holds the administrative rights, and up to twenty Secondary, who join from an emailed invitation that expires after seven days. Handover is built in: a Secondary can later claim the Primary role, subject to approval by your CSIRT.
If Article 14 has arrived before your vulnerability-handling process, we help manufacturers build the triage rule, the named decision-maker and the rehearsed submission path that the duty assumes you already have. If you would rather work through the CRA with tooling than with a consultant, the CRA Workbench is the same team in a different shape.
Sources
- ENISA, Single Reporting Platform — frequently asked questions: enisa.europa.eu/…/frequently-asked-questions
- ENISA, Single Reporting Platform topic page: enisa.europa.eu/…/single-reporting-platform-srp
- ENISA, CRA SRP guidance — Assigned Representative user registration: enisa.europa.eu/…/cra-srp-guidance-ar-user-registration
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13, 14 and 16; application dates at Article 71(2).
Quoted phrases are ENISA's own wording, verified against the pages above on 12 September 2026. This post is not legal advice; verify against the Official Journal text.