# The CRA Single Reporting Platform: a complete guide to reporting > From 11 September 2026, actively exploited vulnerabilities and severe incidents are reported on a single ENISA platform. What the SRP is, who registers, what goes into each notification, who receives it and within how many hours. A guide from the official sources, with references to the CRA articles and to ENISA guidance. - URL: https://albertoscarpa.com/guide/en/single-reporting-platform-guide/ - Lingua / Language: English - Published: 2026-08-12 - Updated: 2026-08-12 - Tags: CRA --- From 11 September 2026 the nearest obligation under the Cyber Resilience Act kicks in. It is a reporting obligation, not a product requirement. Whoever discovers an actively exploited vulnerability or suffers a severe incident must notify it, and from that date they do so through a single channel run by ENISA, the Single Reporting Platform (SRP). This guide gathers what the official sources say about the platform: who notifies, with which account, what they write, within how much time. It is updated to the ENISA guidance of August 2026. *This guide reports the binding text of the CRA and the official guidance of ENISA and the Commission, with precise references. Operational readings and applied advice, such as how to choose the AR or how to decide whether a report becomes a notification, are in the linked blog articles at the end.* If the general picture of the CRA is not yet in focus, the starting point is [The CRA in one hour](/guide/en/cra-in-one-hour/); for how this deadline sits against the others, [The CRA deadlines](/guide/en/cra-deadlines/). ## What the SRP is, and why it exists The SRP is a single entry point for the notifications required by the CRA. The manufacturer notifies only once, and the platform routes it to the competent national CSIRT and to ENISA. A single submission reaches every recipient, with no need to notify multiple authorities separately. In practice, for anyone selling across several Member States, the logistics of reporting change: a single form that the platform routes to the competent national authorities. The manufacturer indicates where the product is available, the CSIRT that receives it first disseminates the notification to the other concerned CSIRTs and, where needed, to the market surveillance authorities. The legal basis is Article 16 of the CRA (Regulation EU 2024/2847): ENISA establishes the platform, runs its day-to-day operations and ensures its security. The architecture provides for national electronic notification end-points (the CSIRTs) and one at Union level (ENISA). ## When it goes live The platform is scheduled to be operational by 11 September 2026, the same date on which Article 14 of the CRA, the one that introduces the reporting obligations, starts to apply. A testing period is expected before launch. The platform's public URL has not yet been communicated: ENISA will publish it on its page before the platform goes live. Note: the date is not a product conformity deadline, it is the activation of a process. A company can have products still far from the essential requirements (which apply from 11 December 2027) and still be subject to the reporting obligation from September 2026, including for products already on the market. ## What must be reported, and what may be reported The CRA distinguishes two levels. Mandatory (Art. 14): the manufacturer notifies actively exploited vulnerabilities (vulnerabilities for which there is reliable evidence of exploitation by a malicious actor) and severe incidents that have an impact on the security of the product. The criteria for the severity of an incident are in Art. 14(5). Open-source software stewards are subject to the obligations to the extent that they are involved with products with digital elements (Art. 24(3)). Voluntary (Art. 15): anyone, not only the manufacturer, may notify on a voluntary basis vulnerabilities, cyber threats, incidents and near misses. The SRP will enable this function after 11 September 2026. The CSIRT may handle mandatory notifications as a priority over voluntary ones. The distinction matters because it defines what starts the clock. Only the active exploitation of a vulnerability, or a severe incident, triggers the obligation and its timelines. A known but unexploited vulnerability sits on the voluntary level. ## The deadlines: 24 hours, 72 hours, final report The timelines run from the moment the manufacturer becomes aware of the exploitation or the incident. Art. 14(2) (for vulnerabilities) and Art. 14(4) (for incidents) set three steps: - Early warning, within 24 hours. - Notification, within 72 hours, with general information and an initial assessment. - Final report: for vulnerabilities, within 14 days of a corrective measure being made available; for severe incidents, within 1 month of the notification. The early warning within 24 hours is a preliminary notification, carrying only the few fields that identify the case; the detailed information arrives in the two later steps. ## Who notifies: the representative and registration The platform is operated by the Assigned Representative (AR), the user who submits notifications on behalf of the manufacturer or the open-source steward. The ENISA guidance (pages published in July, updated on 3 August 2026, non-binding) describes two roles and two registration paths. The Primary AR registers by selecting the role and the coordinating CSIRT, authenticating through EU Login, accepting the agreement, confirming the pre-filled details and entering the manufacturer data. Once done, the account is active with the primary AR role. A backup AR (Secondary) registers via an email invitation sent by the primary; the invitation expires after 7 days. Note: validation of the AR by the coordinating CSIRT happens after registration, but it is not a prerequisite for notifying. It runs in parallel with the reporting and does not block submission. Precisely to avoid overloading the CSIRTs, ENISA advises registering and starting validation only when you actually need to notify, not in advance. The EU Login account can be created right away: https://ecas.ec.europa.eu/cas/login. It is the one step that does not depend on the platform launch. ## What goes into each notification The ENISA FAQ (question 16) publishes the form fields, split across the three deadlines. The fields come from the CRA (Art. 14) and, for some, from ENISA's logical reading. A summary of what is mandatory at each stage. Early warning (24 hours). Only the fields that identify the case: notification type (vulnerability or incident), product, manufacturer or open-source steward, title. For an incident, you must state right away whether unlawful or malicious acts are suspected (consistent with Art. 14(4)(a)). The Member States where the product is available are required if the information is already available. The rest is optional. Notification (72 hours). The technical substance comes in. For a vulnerability: nature of the vulnerability and of the exploit, corrective or mitigating measures taken and those users can take. For an incident: nature of the incident, date and time it was detected and when it occurred, initial assessment, measures taken and measures for users. In both cases the sensitivity of the information is to be indicated, where relevant. Final report. The full description. For a vulnerability: severity and impact, the date the corrective measure becomes available, details on the security update. For a severe incident: severity (against the Art. 14(5) criteria), impact, type of threat or root cause, mitigation measures applied and ongoing. Two practical details. Some fields are copied automatically from the previous stage and can be updated; others (reporting timestamps, submitter identity) are filled by the platform. No APIs are provided at this stage: filling in is manual, including for anyone handling high volumes of notifications. ## Who receives the notification, and how it travels On submission, the notification reaches simultaneously the CSIRT designated as coordinator of the Member State where the manufacturer has its main establishment, and ENISA (Art. 14(1) and (3); Art. 16). The CSIRT that receives it first disseminates it without delay to the other coordinating CSIRTs of the Member States where the manufacturer has indicated that the product is available, and, where necessary, to the market surveillance authorities. An exception concerns exceptional circumstances. The receiving CSIRT may delay or withhold dissemination to other Member States on justified cybersecurity grounds (Art. 16). The conditions are specified by Delegated Regulation (EU) 2026/881, adopted on 11 December 2025. In particularly exceptional circumstances, when in the 72-hour form the manufacturer marks one of the conditions in Art. 16(2)(a)-(c), ENISA receives only partial information until the receiving CSIRT discloses the full notification. ## Which CSIRT is yours The competent coordinating CSIRT is determined by the manufacturer's main establishment (or that of its authorised representative, if the manufacturer is not established in the EU). Art. 14(7) provides the criteria to identify it. For a manufacturer whose main establishment is in Italy, the reference is CSIRT Italia, at the National Cybersecurity Agency (ACN). ENISA will publish the list of CSIRTs designated as coordinators at a later stage. ## Further reading The operational choices on the SRP are covered in the blog, which builds on this guide: [The Assigned Representative on the SRP](/blog/en/choosing-the-assigned-representative/) and [From report to notification: when a report becomes an SRP notification](/blog/en/from-report-to-notification/). --- *References: Regulation (EU) 2024/2847 (CRA), Articles 14, 15, 16, 24 and relevant Annexes; Delegated Regulation (EU) 2026/881 (conditions for delaying the dissemination of notifications). Non-binding guidance: ENISA pages on the SRP and related FAQ (updated 3 August 2026), Commission guidance. Article numbers verified against the official text of the CRA.*