ENISA's Single Reporting Platform: what to know before your first report

01Short answer

• Notifications are submitted with personal EU Login accounts. Multi-factor authentication is mandatory and there are no company accounts.
• ENISA asks manufacturers to register and start validation only when a notification is needed. Notifications can be submitted while validation is pending.
• Choosing the coordinating CSIRT is the manufacturer's responsibility. A wrong choice can invalidate the notification.
• The platform is in English only and its first release has no API; notifications are entered in the web interface.
• The platform's counters are for information. There is no counter for the final report on an actively exploited vulnerability; the manufacturer tracks that deadline itself.
• A manufacturer cannot withdraw a submitted notification; only the coordinating CSIRT can close it.

02What the platform does

The SRP is the reporting platform ENISA set up and runs under Article 16(1) of the CRA. It went live on 11 September 2026, the day the Article 14 obligations started to apply. Manufacturers report actively exploited vulnerabilities and severe incidents having an impact on the security of their products here once, instead of notifying national authorities one by one.

A submitted notification reaches the coordinating CSIRT and ENISA at the same time. The coordinating CSIRT passes it on to the CSIRTs of the other Member States where the product is available and informs market surveillance authorities where needed (Article 14(1), Article 16). For scope, deadlines and report contents, see the Article 14 guide.

One notification per vulnerability or incident is enough. If the manufacturer has several branches or subsidiaries in the EU, or its parent company is outside the EU, it is up to the manufacturer to agree internally who submits (ENISA FAQ 8).

If the platform is temporarily unavailable, the manufacturer waits until it is back. If immediate contact is needed in the meantime, the coordinating CSIRT can be contacted directly, but the notification must still be submitted through the SRP once it is available again (ENISA FAQ 25).

The platform currently accepts mandatory notifications only. Voluntary reporting under Article 15 will be added in a later phase. The reporting obligations of open-source software stewards apply from 11 December 2027 (ENISA FAQ 4 and 27).

03Accounts and representatives

People who submit on behalf of a manufacturer are called Assigned Representatives (ARs) in the platform. Each AR signs in with their own EU Login account. EU Login accounts are personal and multi-factor authentication (MFA) is mandatory. The SRP uses no separate company authentication, so a shared company account is not possible (ENISA FAQ 9).

A manufacturer can have one Primary AR and up to 20 Secondary ARs. The Primary AR registers, selects the coordinating CSIRT, enters the manufacturer's details and invites Secondary ARs. Before sending invitations, the Primary AR's own manufacturer association must show as "Verified". A Secondary AR can claim the Primary role, subject to the CSIRT's approval.

All ARs associated with the manufacturer can see and update submitted notifications, whoever submitted them, so another AR can complete the 72-hour notification or the final report. Drafts are the exception: they stay in the account of the AR who created them and other ARs cannot see them.

The coordinating CSIRT validates the association between AR and manufacturer; the procedure and processing time vary by CSIRT. Validation does not block reporting: an AR whose association is not yet verified can submit up to 20 notifications for that manufacturer before verification becomes mandatory.

To limit the CSIRTs' validation workload, ENISA asks manufacturers to register on the SRP and start validation only when they need to submit a notification. An EU Login account can be created in advance, and with one in place SRP registration takes a few minutes. So it is enough to name the people who will submit and set up their EU Login accounts and MFA now.

04Choosing the right CSIRT

The manufacturer decides which coordinating CSIRT receives the notification and selects it when submitting. If the wrong CSIRT is selected, the notification may be invalidated and must be resubmitted to the correct one (ENISA FAQ 18). Because the legal deadlines run from the moment of becoming aware, settle this before your first notification.

As a rule, it is the Member State of the manufacturer's main establishment in the EU: the place where decisions on the cybersecurity of its products are predominantly taken. If that cannot be determined, it is the Member State of the EU establishment with the most employees (Article 14(7)).

Manufacturers without a main establishment in the EU go through this order:

1. The Member State where the authorised representative acts on the manufacturer's behalf for the most products.
2. Otherwise, the Member State where the importer places the most of the manufacturer's products on the market.
3. Otherwise, the Member State where the distributor makes the most of the manufacturer's products available.
4. If none of these applies, the Member State with the most users of the manufacturer's products.

The form shows the coordinating CSIRT's Member State automatically; you add the other Member States where the product is available. ENISA publishes the list of coordinating CSIRTs with their contact details. For a manufacturer exporting from outside the EU, this order means documenting in advance which Member State follows from its authorised representative, importer and distributor relationships. Other points for non-EU manufacturers are in the CRA readiness guide.

05Counters and legal deadlines

The SRP uses counters to send reminder emails and to flag that a report may be overdue. According to ENISA, they only provide visibility; the manufacturer remains responsible for reporting without undue delay after becoming aware and within the deadlines of Article 14 (ENISA FAQ 26).

The 72-hour counter runs from the submission of the early warning, not from the moment of becoming aware. If the early warning went in within 24 hours, the counter never shows a time later than the legal limit; for an early warning sent sooner, it shows an earlier one. That is why a notification can sometimes appear "overdue" before 72 hours have passed. ENISA says a later release will calculate it from the awareness date and time entered in the form.

The final report is where attention is needed. For actively exploited vulnerabilities the deadline depends on when a corrective measure becomes available, so the platform has no counter and sends no reminder. Put the 14-day deadline in your own calendar on the day the update is released. For severe incidents the deadline is one month after the 72-hour notification.

The awareness date and time is entered in UTC and is mandatory in the early warning. If the exact time is unknown, enter the best supported estimate and say in the description that it is an estimate (SRP Glossary v1.6). Keeping internal records in UTC as well makes later comparisons easier.

06What the form asks for

ENISA's SRP Glossary explains the form field by field: what each field means, how to complete it, the expected format and at which stage it is required. If the person submitting and the team preparing the content are not the same, it works as a shared reference. The main required fields:

• Early warning (24 hours): notification type (actively exploited vulnerability or severe incident), title (up to 255 characters), summary (up to 4,000 characters), Member States where the product is available, product name, affected versions and the date and time of becoming aware. For severe incidents, whether unlawful or malicious acts are suspected is also required.
• 72-hour notification: for a vulnerability, general information on the exploit and the vulnerability; for an incident, its nature and an initial assessment. In a vulnerability notification, if one of the conditions in Article 16(2) is met, you can ask for dissemination to other Member States to be delayed (particularly exceptional circumstances, PEC).
• Final report: corrective or mitigating measures taken and those users can take. For a vulnerability, also a description of severity and impact, the date the corrective measure became available, details of the update and, where available, the malicious actor; for an incident, severity and impact and the type of threat or root cause.

Fields such as the CVE and EUVD ID, the product's CRA class, component name and whether the support period has ended are optional. ENISA expects them to be completed whenever the information is available and relevant (ENISA FAQ 16).

07After you submit

A manufacturer cannot withdraw a submitted notification. Only the coordinating CSIRT can close it. To ask for a notification sent by mistake to be closed, contact the CSIRT or add the request in the notification's additional note field (ENISA FAQ 34). ENISA therefore asks users to read the user manual carefully before reporting.

Once a notified vulnerability is publicly known, ENISA may contact the manufacturer to check whether and when it can be added to the European Vulnerability Database (EUVD). ENISA is a CVE Numbering Authority and can also help assign a CVE ID (ENISA FAQ 35, Article 17(5)).

08Exploitation before 11 September 2026

The obligation arises when the manufacturer becomes aware. A manufacturer that was already aware of an active exploitation before 11 September 2026 does not have to report it retrospectively. If it becomes aware after that date, the obligation applies, even if the vulnerability existed or was known before (ENISA FAQ 13, Commission FAQ 5.3).

The obligation covers all products in the scope of the CRA, including those placed on the market before 11 December 2027 (Article 69(3)). If a vulnerability in an integrated component is actively exploited in your product, you report it as the product's manufacturer; if the component was placed on the market on its own, its manufacturer reports it too. If the vulnerability cannot be exploited in your product, no mandatory notification is needed (Commission FAQ 5.4).

09Checklist

1. Name the Primary and Secondary ARs who will submit, and plan for weekends and holidays.
2. Set up their personal EU Login accounts and MFA now. Register on the SRP when a notification is needed.
3. Determine your coordinating CSIRT under Article 14(7), write down why, and note its contact details from ENISA's list.
4. Keep product names, affected version ranges and the Member States where each product is available at hand; they are required in the early warning.
5. Write down who decides the moment of becoming aware and how it is recorded; keep the time in UTC.
6. Prepare the content in English and keep the draft where the whole team can reach it; SRP drafts are visible only in the account of the AR who created them.
7. For vulnerabilities, put the 14-day final report deadline in your own calendar on the day the update is released; the platform keeps no counter for it.
8. Before submitting, check the coordinating CSIRT and the notification type; a submitted notification cannot be withdrawn.

To calculate the deadlines for your own dates, use the calculator in the Article 14 guide; for the overall obligations, see the CRA guide.

The TegmenSoft platform prepares Article 14 drafts in the field order of the SRP form; the manufacturer submits the notification.

10Frequently asked questions