Guide Last updated 8 October 2026 14 min read

ENISA Single Reporting Platform: registration and notification step by step

Since 11 September 2026, ENISA and the national CSIRTs have accepted notifications under Article 14 only through a web form. This guide takes you through registration, cover arrangements and the three notification stages, and points out the quirks of the platform that cost time in an emergency.

The single reporting platform (SRP) is ENISA's web portal through which manufacturers notify actively exploited vulnerabilities and severe incidents. Article 14(1) and (3) of Regulation (EU) 2024/2847 require manufacturers to notify "simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA" via this platform. It has been running since 11 September 2026 at portal.cra-srp.enisa.europa.eu, as a web form in English, with no API. To submit a notification you need a personal EU Login account with multi-factor authentication, the role of Assigned Representative and the right choice of competent CSIRT; in Germany that is CERT-Bund, part of the BSI.

Key points

Only a natural person with a personal EU Login account and multi-factor authentication switched on can submit notifications: the Assigned Representative (AR). Accounts must not be shared.
Each manufacturer has one Primary AR and up to 20 Secondary ARs. Cover for holidays and sickness works only through Secondary ARs, whom the Primary AR invites once verified.
At registration, the AR chooses the coordinating CSIRT according to the Member State of the main establishment (Article 14(7)). Choosing the wrong one can invalidate the notification.
Verification by the CSIRT runs in parallel; up to 20 notifications can be submitted before it is complete. Waiting for it is no reason to miss a deadline.
The platform has no test environment and, in the current release, no field for the time of awareness, only for detection. The 72-hour counter in the portal currently calculates incorrectly. Manufacturers have to record the time of awareness themselves.

What the platform is and who has to use it

Article 16(1) requires ENISA to establish and operate the reporting platform. Every notification goes to ENISA and, at the same time, to the CSIRT designated as coordinator for the manufacturer. A CSIRT is a country's computer security incident response team; in Germany that is CERT-Bund at the BSI, in Austria CERT.at. Under Article 16(2), the CSIRT that receives the notification first passes it on without delay, via the platform, to the CSIRTs of the countries in which the product has been made available.

The platform is a web form, nothing more. The interface and the notifications are in English. The person who uses it is the Assigned Representative (AR), nominated by the manufacturer. The platform does not check any power of attorney; the CSIRT verifies the link to the manufacturer. The AR is not the authorised representative under Article 18, who legally represents a manufacturer without an establishment in the EU. More on this in the glossary under Assigned Representative.

Registration step by step

The BSI says registration can be done within a few minutes, and there is no obligation to register before the first notification. Even so, it belongs on a quiet day, not on the night a deadline is running. The steps follow ENISA's AR User Manual (version 1.1, September 2026) and the BSI's SRP page.

Create EU Login accounts for at least two peopleEU Login is the sign-in account of the EU institutions and can be set up in advance at ecas.ec.europa.eu. Multi-factor authentication must be switched on, for example via an app; the account itself shows which methods EU Login offers. Accounts are personal. Setting up two accounts from the start saves a hunt for cover later.
Determine the main establishment under Article 14(7)The competent CSIRT is that of the Member State of the main establishment. This is the Member State "where the decisions related to the cybersecurity of its products with digital elements are predominantly taken"; failing that, the Member State with the highest number of employees in the Union. Without an establishment in the EU, the location of the authorised representative, the importer, the distributor or the users counts, in that order. If you have several sites, record the decision in writing.
Open the platform and choose the roleOn portal.cra-srp.enisa.europa.eu, choose the role Assigned Representative. The first person to register for a manufacturer becomes the Primary AR.
Select the coordinating CSIRTChoose the "CSIRT Designated as Coordinator" from the drop-down list; for German manufacturers that is CERT-Bund. The manual places responsibility for this on the manufacturer. If the wrong CSIRT is chosen, the notification can be declared invalid and has to be resubmitted.
Sign in with EU Login and accept the terms of useThe platform redirects to EU Login and back; then accept the Terms and Conditions (version 1.0 of 10 September 2026).
Check your personal details, enter the manufacturerName and e-mail address are taken from EU Login and cannot be changed here. Enter the manufacturer's name exactly as it appears in the commercial register.
File the confirmation e-mail, wait for verificationAfter submission you receive a confirmation e-mail. The account shows as "Active", the role as "AR Primary User" and the link to the manufacturer as "Unverified"; it then goes to the CSIRT for review (status under Settings, Association Management). How long CERT-Bund takes has not been published; ENISA says it varies between CSIRTs. The only public experience so far, from Belgium, is three working days.
Invite Secondary ARs after verificationOnly a verified Primary AR can send invitations; the invitation goes out by e-mail and expires after seven days. Up to 20 Secondary ARs ("Backup ARs") can submit and update notifications but have no administrative rights. All ARs see all of the manufacturer's notifications. If the Primary AR leaves, a Secondary AR can take over the role via "Claim Primary AR Role", with the CSIRT's approval.
Prepare a notification template outside the platformProduct names, version designations, the Member States in which the products are in use, contact details and standard text in English. In an emergency you fill in the blanks instead of hunting for information.

Creating a notification: early warning, 72-hour notification, final report

Article 14(2) (vulnerability) and Article 14(4) (incident) set three stages: an early warning notification within 24 hours, a notification within 72 hours, and a final report. The early warning and the notification are due within 24 and 72 hours "of the manufacturer becoming aware"; the final report is due no later than 14 days after a corrective or mitigating measure is available (vulnerability) or within one month after the incident notification (incident). In the platform, the stages are tabs of the same notification. The process according to ENISA's guidance (as of 12 September 2026):

Start a new notificationChoose "Submit new notification", then select the notification type (vulnerability or incident) and the manufacturer. The Early Warning tab opens.
Complete and submit the early warningMandatory fields are notification type, title, summary, manufacturer name, affected Member States, product name, product version and the time of detection. For an incident you must also state whether unlawful or malicious acts are suspected (Article 14(4)(a)). If a mandatory field is missing, the platform shows an error. "Save as draft" only saves. Only "Submit" counts as the notification.
File the confirmationAfter each submission, an e-mail and an alert go to the AR, the CSIRT and ENISA; the status changes to "EW Submitted". The e-mail belongs in your records, as it proves the time.
72-hour notification in the second tabThis requires the early warning to have been submitted. You add general information about the vulnerability or incident and the time it occurred; for incidents, the initial assessment; for vulnerabilities, optionally a request for delayed dissemination (Article 16(2)). The status then reads "72h Submitted".
Final report in the third tabFor vulnerabilities no later than 14 days after a corrective or mitigating measure is available; for incidents within one month of the 72-hour notification. Mandatory: measures taken, mitigating measures for users, severity and impact. Status: "FR Submitted". After that, the notification can no longer be edited.
Interim updates via "Update"Until the final report, every stage can be supplemented with the Update button; each update triggers notifications. The CSIRT sets the status to "Valid", "Invalid" or "Closed" and can request an intermediate report under Article 14(6).

What each of the three stages has to contain, and how vulnerabilities and incidents differ, is covered in the guide Early warning, notification, final report.

Which fields the platform requires

Based on ENISA's SRP Glossary (version 1.4 of 1 October 2026). "Mandatory" means the platform will not accept a submission without an entry. Anything already entered is carried over by the platform to the next stage.

Field	Early warning	72-hour notification	Final report
Notification type, title, summary	mandatory	carried over	carried over
Manufacturer name	mandatory	carried over	carried over
Affected Member States	mandatory	can be updated	can be updated
Product name, product version	mandatory	can be updated	can be updated
Date and time of detection	mandatory	carried over	carried over
Suspected unlawful or malicious acts (incident only)	mandatory	carried over	carried over
CVE ID, EUVD ID (vulnerability only)	optional	optional	optional
Product type, product class, product category, end-of-support indicator, component name	optional	optional	optional
General information about the vulnerability or incident	optional	mandatory	can be updated
Date and time of occurrence	optional	mandatory	carried over
Initial assessment (incident only)	optional	mandatory	can be updated
Attack vector	not applicable	optional	optional
Request for delayed dissemination, with justification (vulnerability only)	not applicable	optional	not applicable
Measures taken	optional	optional	mandatory
Mitigating measures for users	optional	optional	mandatory
Mitigation expected soon, immediate action for users, assessment of sensitivity (field 15 "Considered sensitivity of information": a short free-text justification of no more than 255 characters stating which information is sensitive and why)	optional	optional	optional
Date on which the mitigation became available, details of the security update (vulnerability only)	optional	optional	mandatory
Severity and impact, fully described	optional	optional	mandatory
Information on the malicious actor (vulnerability only)	optional	optional	where available
Threat type and root cause (incident only)	optional	optional	mandatory

One gap stands out: there is no field for the time at which the manufacturer became aware, which is when all the deadlines start. For vulnerabilities, the glossary announces such a field for the next release; for incidents, the glossary already labels the field "Date and time when you become aware of the incident", but in the current release it still reads "Date and time when the incident was detected". In its questions and answers updated on 3 October 2026, ENISA confirms that the time of awareness will only be used to calculate deadlines in a future release. Until then, manufacturers record the time themselves, with evidence; how to do this is explained in the guide When does the 24-hour deadline start? Awareness under Article 14 CRA.

Quirks worth knowing in advance

English only. Both the interface and the free-text fields. Product descriptions and standard text translated in advance save an hour in the middle of the night.
No API. Your own ticketing systems can prepare the notification, but a person has to submit it in a browser.
No test environment. Neither the FAQ nor the manual mentions a practice environment. The form can only be worked through as a draft. Test notifications to the live platform or to CERT-Bund are off limits.
Drafts are private. They are visible only to the person who created them and do not count as a notification. A draft in the account of someone who is away helps nobody on a Saturday.
The 72-hour counter currently calculates incorrectly. According to ENISA's FAQ of 3 October 2026, the portal shows the 72-hour notification as due 48 hours after the early warning was submitted. The legal deadline, however, runs from awareness, not from the early warning. Your own time of awareness is what counts; ENISA intends to change the logic in a later release.
Reminders are no substitute. The platform sends reminder and overdue e-mails; ENISA stresses that the counters do not replace the manufacturer's own responsibility.
Helpdesk. Questions about using the platform go to cra-srp-helpdesk@enisa.europa.eu, security problems with the platform to cra-srp-security@enisa.europa.eu. ENISA provides a tutorial video on its SRP page.
Fallback if the platform is down. If the platform cannot be reached, the BSI accepts notification by e-mail to CERT-Bund by way of exception. Record the outage with a screenshot and submit the notification on the platform as soon as it is running again. How CERT-Bund handles such e-mails is not documented.

Cover during holidays, and the question of a service provider

The 24-hour deadline does not take holidays. Accounts are personal and multi-factor authentication is tied to one person's device; an account cannot be handed on. Cover works only through Secondary ARs: at least two people, ideally three, each with their own EU Login, invited by the Primary AR and signed in once so that the invitation does not expire. Who can be reached when belongs in the manufacturer's call chain, not in the platform.

Can an external service provider act as AR? The platform allows one person to be linked to several manufacturers (manual, section 4.3) and does not check any power of attorney; the CSIRT confirms each link. Neither ENISA nor the BSI says whether a service provider may take on the role; the BSI expects a person who can assess the product portfolio technically or who works closely with the specialist teams. Legally, the reporting obligation stays with the manufacturer; Article 14 is addressed to the manufacturer. What a service provider can take on is the preparation: receiving reports, assessing them, alerting the call chain, keeping track of the deadlines and having the draft ready in English. CRA Response Center is built for exactly this and never submits anything to ENISA itself; submission remains with the manufacturer's Assigned Representative. More in the guide Outsourcing the CRA reporting obligation.

Free templatesCRA Reporting KitNotification templates with all mandatory fields and the most important optional fields of the platform, standard text in English and a list for Primary and Secondary Assigned Representatives.Request the kit

Common mistakes

Wrong CSIRT chosen. The notification is invalid and has to be resubmitted, while the deadline keeps running.
Only one person with an account. Holidays, sickness or a resignation block the submission.
Draft instead of submission. Not a notification, and invisible to everyone else.
24 and 72 hours counted one after the other. Both run in parallel from awareness; the portal counter currently suggests the opposite.
Notification not in English, manufacturer name different from the commercial register, product version ambiguous. Each of these leads to follow-up questions.
Waiting for verification. Unnecessary: 20 notifications are possible before it is complete.
Final report submitted too early. After that, nothing can be changed.

Frequently asked questions

Do I have to register in advance?

No. The BSI says that registration and notification can be done within a few minutes in an emergency. Registering in advance does save time, though, lets verification happen without pressure and is a precondition for inviting Secondary ARs.

Who can be an Assigned Representative?

Any natural person with EU Login and multi-factor authentication whom the manufacturer nominates. The platform does not check any power of attorney; the CSIRT verifies the link to the manufacturer.

Does verification have to be complete before I can submit a notification?

No. According to ENISA, verification does not prevent submission; up to 20 notifications are possible beforehand. Only inviting Secondary ARs requires it.

Is there an API?

No. ENISA has said one may follow in a later phase, but has given no date. Voluntary notifications under Article 15 are not yet available either.

What happens if the platform goes down?

In that case the BSI accepts notification by e-mail to CERT-Bund by way of exception. Document the outage and submit the notification on the platform as soon as it can be reached again.

Is there a practice environment?

No, none is documented. Forms can only be worked through as drafts. Practise with tabletop exercises, never with real notifications.

Sources

Regulation (EU) 2024/2847, Articles 14, 16 and 71, Official Journal of the EU, 20 November 2024.
CRA Single Reporting Platform: Frequently Asked Questions, ENISA, as of 3 October 2026.
CRA SRP: AR User Manual, Version 1.1, ENISA, September 2026.
CRA SRP Glossary, Version 1.4, ENISA, 1 October 2026.
Guidance: AR Notification Submission and Update, ENISA, as of 12 September 2026.
List of CSIRTs Designated as Coordinators, ENISA, as of 10 September 2026.
Single Reporting Platform (CRA) (in German), BSI, accessed on 8 October 2026.
Aikido Security: first account using the ENISA SRP, cyberresilienceact.eu, 28 September 2026.
Commission CRA application guidance published, cyberresilienceact.eu, 27 July 2026.