Skip to content
Meet us at it-sa 2026
EN, Language: English

ENISA Single Reporting Platform: a preparation guide for CRA reporting

By Alex Varabyou ·

Contents

Legal statements were checked on 21 October 2026 against the Official Journal text of Regulation (EU) 2024/2847. Operational statements are taken from ENISA's public pages as read on that date (FAQ "Updated: 15 October 2026"); ENISA changes the platform and its guidance, so check them again before relying on them. This page is information, not legal advice. It does not determine whether an event is reportable.

The first two reporting deadlines start with awareness. Opening the portal does not start those clocks. That distinction belongs in the preparation work, before anyone needs to submit a notification.

What the Single Reporting Platform does

The Single Reporting Platform, or SRP, comes from Article 16 of the Cyber Resilience Act. ENISA establishes it and manages and maintains its day-to-day operations. Article 16(1) covers the mandatory notifications in Article 14(1) and (3) and the voluntary notifications in Article 15(1) and (2).

The stated purpose is "to simplify the reporting obligations of manufacturers" (Article 16(1)). Manufacturers notify the CSIRT designated as coordinator and ENISA simultaneously, via the platform (Article 14(1), (3)). The architecture allows Member States and ENISA to put in place their own electronic notification end-points, and the notification is submitted using the end-point of the competent CSIRT designated as coordinator (Article 16(1); Article 14(7)).

The CSIRT that first receives the notification disseminates it without delay via the platform to the CSIRTs designated as coordinators in the Member States where the manufacturer has indicated the product has been made available (Article 16(2)). In exceptional circumstances that dissemination may be delayed on justified cybersecurity-related grounds (Article 16(2); Commission Delegated Regulation (EU) 2026/881). In the particularly exceptional circumstances listed in the third subparagraph of Article 16(2), ENISA initially receives only limited information. Reporting to the designated recipients does not mean unrestricted sharing.

The public ENISA page explains the service. To submit, use the portal. According to ENISA, the platform has been operational since 11 September 2026 and is reached at portal.cra-srp.enisa.europa.eu (opens in a new tab) (ENISA SRP page; FAQ 4 and 28).

Who uses it, and for which events?

Article 14 places mandatory reporting duties on manufacturers. It covers an actively exploited vulnerability contained in a product with digital elements, and a severe incident having an impact on the security of such a product. These are distinct reporting grounds (Article 14(1), (3) and (5)). Article 14 applies from 11 September 2026 (Article 71(2)).

A vulnerability finding is a reason to assess the situation. It should not automatically become a decision to notify under Article 14. The manufacturer must assess the relevant legal trigger and record the evidence. An actively exploited vulnerability requires reliable evidence that a malicious actor has exploited it in a system without permission of the system owner (Article 3(42)).

Article 15 provides for voluntary notifications. Manufacturers and other natural or legal persons may notify a CSIRT designated as coordinator or ENISA of any vulnerability and of cyber threats that could affect the risk profile of a product (Article 15(1)). They may also notify any incident having an impact on the security of the product and near misses that could have resulted in such an incident (Article 15(2)). A voluntary notification and a decision that mandatory reporting applies need to remain separate.

According to ENISA, the platform does not yet support voluntary notifications under Article 15; only mandatory Article 14 notifications by manufacturers can currently be submitted. Persons who are not manufacturers are asked to contact the relevant national CSIRT directly (FAQ 4, 27 and 30). Open-source software stewards have reporting obligations under Article 24(3) from 11 December 2027 (Article 71(2)).

The glossary explanation of the single reporting platform and the Article 14 guide provide related terminology and timelines.

The clock starts before the form

The first two deadlines run from the manufacturer becoming aware. Opening an account or starting a draft does not start those clocks. Both stages require action without undue delay, within their stated outer limits (Article 14(2)(a)–(b) and (4)(a)–(b)).

scrolls sideways
StageActively exploited vulnerabilitySevere incident
Early warningWithout undue delay and in any event within 24 hours of becoming aware. Indicate, where applicable, the Member States where the product has been made available. Article 14(2)(a).Without undue delay and in any event within 24 hours of becoming aware. Include at least whether unlawful or malicious acts are suspected and, where applicable, the Member States where the product has been made available. Article 14(4)(a).
NotificationUnless the relevant information has already been provided: within 72 hours of becoming aware. General information, as available, about the product, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken and those users can take, and, where applicable, the sensitivity of the information. Article 14(2)(b).Unless the relevant information has already been provided: within 72 hours of becoming aware. General information, where available, about the nature of the incident, an initial assessment of the incident, corrective or mitigating measures taken and those users can take, and, where applicable, the sensitivity of the information. Article 14(4)(b).
Final reportUnless the relevant information has already been provided: no later than 14 days after a corrective or mitigating measure is available. Article 14(2)(c).Unless the relevant information has already been provided: within one month after the submission of the incident notification. Article 14(4)(c).

The vulnerability final report includes at least a description of the vulnerability, including its severity and impact; where available, information about any malicious actor that has exploited or is exploiting it; and details about the security update or other corrective measures made available (Article 14(2)(c)).

The severe-incident final report includes at least a detailed description of the incident, including its severity and impact; the type of threat or root cause likely to have triggered it; and applied and ongoing mitigation measures (Article 14(4)(c)). Use the checklist for the event you are reporting. The vulnerability final-report checklist does not replace the severe-incident checklist.

Where necessary, the CSIRT that first received the notification may request an intermediate report on relevant status updates (Article 14(6)). According to ENISA, a notification can be updated through later stages by any assigned representative associated with the same manufacturer (FAQ 9). Keep the record open through those stages. Submitting the first form is only part of the work.

Which CSIRT receives the notification?

The recipient is the CSIRT designated as coordinator, a CSIRT designated under Article 12(1) of Directive (EU) 2022/2555 (Article 3(51)). A familiar response-team name, or proximity to the affected customer, is not enough to select the recipient. ENISA publishes a list of CSIRTs designated as coordinators. According to ENISA, if the wrong one is selected, the notification may be invalidated and must be resubmitted to the correct one (FAQ 18).

A manufacturer with a main establishment in the Union notifies the CSIRT designated as coordinator of that Member State. The main establishment is in the Member State where decisions related to the cybersecurity of its products are predominantly taken. If that cannot be determined, it is where the manufacturer has the establishment with the highest number of employees in the Union (Article 14(7)). The registered office alone does not settle the question.

A manufacturer with no main establishment in the Union applies the following order, based on the information available to it (Article 14(7)):

  1. the Member State where the authorised representative acting for the highest number of its products is established;
  2. the Member State where the importer placing the highest number of its products on the market is established;
  3. the Member State where the distributor making the highest number of its products available on the market is established;
  4. the Member State where the highest number of users of its products are located.

Where point 4 was used, the manufacturer may send later notifications to the same CSIRT it first reported to (Article 14(7)). Work through that order rather than choosing the most convenient recipient.

Prepare a short routing note before an event. It needs the legal manufacturer, the relevant establishment or fallback operator, and the facts supporting that choice. Record the provision used and have the responsible legal or security lead check it.

Who can submit, and who can see a draft?

These access details come from ENISA (FAQ 9, 15, 24 and 28, read 21 October 2026). They are a description of the published workflow, not a test of the platform.

  • Notifications are submitted by Assigned Representatives (ARs) of the manufacturer. Each AR needs a personal EU Login account with multi-factor authentication.
  • There is one Primary AR per manufacturer and up to 20 Secondary ARs, invited by the Primary AR. The CSIRT designated as coordinator validates the AR–manufacturer association. Notifications can be submitted while validation is pending, up to 20 per manufacturer.
  • Drafts are stored in the individual AR's account and are not visible to other ARs.
  • There is no API in the initial release; notifications are entered through the platform interface. The platform is available in English only.

On 20 October 2026 ENISA announced platform version 1.2.1 with a changed process for inviting Secondary ARs, and said its documentation was being updated. Check the date on the guidance you use, too.

What to prepare internally

Start with an event record. Discovery, awareness and submission need separate fields, with timestamps and the evidence behind them. Assign an owner and a backup, and keep the reporting decision and its reasoning beside the technical findings.

Gather the product identification and affected components, then the exploitation evidence and known impact. Separate confirmed facts from provisional findings and unknowns. Write down the immediate containment steps. Keep a separate list of corrective and mitigating measures, including when each became available.

That is preparation advice. For the actual platform fields, use ENISA's SRP Glossary: it sets out the fields for each notification type and stage, and which are required (FAQ 11 and 16). Check it before relying on a specific workflow.

Prepare the user communication process alongside the notification. Submission to the platform does not replace the manufacturer's duty to inform the impacted users and, where appropriate, all users of the vulnerability or incident and, where necessary, of the measures they can deploy (Article 14(8)).

Where to find current ENISA instructions

Start with ENISA's Single Reporting Platform page (opens in a new tab). It links the portal, the factsheet, the terms and conditions, the AR user manual, the guidance pages and the list of CSIRTs designated as coordinators.

Then consult ENISA's Single Reporting Platform FAQ (opens in a new tab) and the SRP Glossary (opens in a new tab).

If the platform is temporarily unavailable, ENISA says to wait and submit once it is available again; a manufacturer that considers immediate communication necessary may contact its CSIRT directly, but must still submit through the platform afterwards (FAQ 25).

Keep your own timeline. A displayed counter or a saved draft is not proof that a statutory deadline was met. According to ENISA, the current 72-hour counter shows a due time 48 hours after the early warning was submitted, not 72 hours after awareness, and there is no counter for the vulnerability final report (FAQ 26). The counters do not replace the legal deadlines.

Sources

For a separate timeline aid, use the crAcken reporting deadline calculator.

Information, not legal advice. These pages use Regulation (EU) 2024/2847 and link to its Official Journal text on EUR-Lex. They do not decide whether an event is reportable. These tools submit nothing to ENISA or a CSIRT.

All free resources