Your first notification on ENISA's Single Reporting Platform: a CRA walkthrough for SMEs

Since 11 September 2026, the notification obligation of Article 14 of Regulation (EU) 2024/2847, the Cyber Resilience Act, has applied, and on the same day ENISA opened the platform through which those notifications pass: the Single Reporting Platform, reachable at portal.cra-srp.enisa.europa.eu. The legal timetable, the content of the three deadlines and the scope of the events to notify are covered in our article CRA: the 24-hour and 72-hour notification. This guide picks up on more concrete ground: what real use of the platform looks like for an SME that has never filed a notification on it, and what to settle before the first incident rather than during it.

The scope of the CRA itself, the products covered and the full timetable are set out in our CRA guide for SMEs. What follows assumes an Article 14 event has occurred, that is, a vulnerability actively exploited in the product or a severe incident affecting its security.

Create the account before you need it

Access to the platform rests on an EU Login account with multi-factor authentication enabled. Accounts are personal: they are attached to a person, not to a shared mailbox. For a given manufacturer, ENISA provides for one primary account, which registers the manufacturer, and up to twenty secondary accounts invited by the primary one. That distinction has a practical consequence for an SME: the person holding the primary account should not be a single point of failure. Keeping at least one active secondary account avoids a notification being blocked because the only registered person is unavailable on the day of the incident.

Registration asks for information about the manufacturer and the choice of the competent CSIRT. There is no reason to do it under pressure: the account, the two-factor step and the link to the right CSIRT are set up outside a crisis and checked once with a control sign-in.

Pick the right CSIRT

The platform files a single notification that is passed to ENISA and to the CSIRT designated as coordinator. The right CSIRT is the one of the Member State where the manufacturer has its main establishment, meaning the place where cybersecurity decisions are mainly taken. For a company established in France, that role falls to CERT-FR, within the ANSSI.

Where the manufacturer has no main establishment in the Union, ENISA applies an order of attachment: the location of the authorised representative, then that of the importer, then that of the distributor, then the Member State with the highest concentration of users. An SME that sells outside its home country has an interest in settling this question at registration, not at the moment of filing, because it decides which authority will receive the report and then coordinate it with the CSIRTs of the other countries concerned.

What each stage asks for on the platform

Article 14 organises the notification in three steps, and the platform follows that structure. The early warning, due within 24 hours of becoming aware, calls for a reduced content: state whether exploitation is suspected or confirmed, and the Member States concerned where relevant. The 72-hour notification asks for the general information available and an initial assessment of the vulnerability or incident. The final report comes at the latest 14 days after a corrective measure is made available for an exploited vulnerability, and at the latest one month after the notification for a severe incident.

ENISA publishes a platform glossary that sets out, field by field, what is expected at each stage, with formats and examples. Reading it once, cold, is better than discovering it while filling in the 24-hour early warning. The exact content of the three deadlines, on the legal side, is detailed in our article on the 24-hour and 72-hour notification.

What becoming aware sets running

The 24-hour clock does not start from the incident itself, but from the moment the manufacturer becomes aware. Neither the regulation nor the Commission's page on the notification obligations gives a numeric definition of that moment, which leaves a margin of judgement better narrowed in advance than on the day.

In practice, the cautious reading ties becoming aware to reliable information. For a vulnerability, ENISA qualifies active exploitation by the existence of reliable evidence that a malicious actor has exploited it without permission in a system: it is that evidence, not the mere discovery of a flaw, that sets the deadline running. For an incident, becoming aware corresponds to the moment the manufacturer knows that a severe incident affecting the product's security has occurred, a severe incident being defined as an event that negatively affects, or is capable of negatively affecting, the product's ability to protect availability, authenticity, integrity or confidentiality. Two points are worth fixing in the internal process: the deadline runs continuously, weekends included, and a written criterion deciding from which signal the company considers it has become aware is better than an improvised call on the day.

What the platform does, and does not yet do

At its opening, the platform works only through its web interface: there is no API in this version, and notifications are entered by hand. A manufacturer can automate its internal preparation workflows, but the final filing goes through the browser. ENISA indicates that an application interface function could arrive in a later phase.

The platform is available in English at launch, with the supporting materials translated progressively, including a factsheet in French. The voluntary reports provided for by Article 15, covering vulnerabilities, threats or near misses, are announced for a later phase: at launch, the platform serves the mandatory Article 14 notifications. A mechanism is provided for exceptional circumstances under Article 16(2), where filing through the platform is not possible.

Tying the filing to the existing incident response

Filing on time does not depend on the platform but on the process that feeds it. In NIST CSF 2.0, qualifying and handling an incident fall under the RS.MA category (incident management), and mandatory reports to authorities and users under the RS.CO category (communication). The channels that feed detection, including coordinated vulnerability disclosure, and the interplay with the other regimes that can trigger on the same event, described in our article on notification under the GDPR, NIS2 and the CRA, are part of the same setup. The ENISA account, the choice of CSIRT and the notification templates are what Article 14 adds to an already structured incident response.

The Komplyo assessment measures the maturity of the RESPOND function, including the RS.MA and RS.CO categories, and the generated roadmap places the incident-management gaps by priority. The CRA scenario has its place in the risk register, with the regulatory obligation documented accordingly. The free diagnostic (23 questions, about 5 minutes) gives a first read of this function.