ENISA Single Reporting Platform (SRP): CRA Onboarding Guide

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) routes every manufacturer's reportable vulnerabilities and severe incidents through one channel: the ENISA Single Reporting Platform, available at portal.cra-srp.enisa.europa.eu from 11 September 2026. This page covers what to prepare, how registration actually works, and how to wire an internal escalation that fits the 24-hour clock. For the reporting cadences themselves, see vulnerability reporting.

What the CRA says about the Single Reporting Platform

ENISA establishes and operates the Single Reporting Platform; Member States and ENISA may put their own electronic notification end-points in place under that architecture. Three operational facts follow:

• ENISA operates the Single Reporting Platform. Member States and ENISA can still put in place their own electronic notification end-points.
• One submission reaches both layers. The manufacturer submits through the coordinator-CSIRT endpoint, and the notification is simultaneously accessible to ENISA.
• Cross-border routing happens inside the platform. The receiving CSIRT disseminates the notification to other CSIRTs whose territory the manufacturer has flagged as affected.

The Single Reporting Platform is the channel for the 24-hour early warning, the 72-hour notification and the final report. Voluntary reporting is not available at launch. ENISA says that functionality arrives in a later phase, so on day one the platform accepts mandatory notifications only. Anyone planning to use the platform for voluntary vulnerability or near-miss reports has to wait.

Who must register

Manufacturers carry the mandatory Single Reporting Platform reporting duty. The obligation sits with manufacturers of products with digital elements, not the rest of the supply chain.

Open-source software stewards report too, but not until 11 December 2027. The CRA gives stewards a later start date than manufacturers, so a steward has fifteen months more to build the process. From that date a steward must report actively exploited vulnerabilities where it is involved in developing the affected product, and severe incidents affecting the systems it provides for that development. One caveat catches people: the later date attaches to the steward role, not to the organisation. If the same organisation also places a product on the market as a manufacturer, that product has been in scope since 11 September 2026.

Importers and distributors inform the manufacturer. They do not register on the Single Reporting Platform, file reports themselves, or inherit the 24-hour clock. Their duty is to inform the manufacturer without undue delay when they become aware of a vulnerability. See importer and distributor.

Non-EU manufacturers need routing clarity. A written authorised-representative mandate can cover mandatory reporting because the authorised-representative exclusions do not include reporting itself. Without a Union main establishment, routing follows the fallback chain: authorised representative, importer, distributor, then user concentration.

Pre-registration prerequisites

Seven inputs the organisation should have ready before registration. ENISA marks its guidance as subject to change, so treat the screens as documented rather than final, but missing any of these will slow a first submission.

Requirement	What you need
Legal entity in the Member State of main establishment	An unambiguous legal-entity record, so you can select the right coordinator CSIRT when you register. That is the State "where the decisions related to the cybersecurity of its products with digital elements are predominantly taken".
User single point of contact	A user-facing channel that "shall not limit such means to automated tools". Auto-reply-only mailboxes do not qualify. Published in the user information accompanying the product.
Authority-facing security contact	A contact for ENISA and the coordinator CSIRT, operationally distinct from the user-facing channel. Exact registration fields remain subject to ENISA's specifications.
EU Login accounts, personal, with MFA	Registration uses a personal EU Login account with multi-factor authentication enabled; create it in advance at ecas.ec.europa.eu. The SRP adds no separate company login, so every filer signs in as themselves. The coordinator CSIRT validates that the filer can act for the manufacturer after first access, in parallel with reporting, without blocking submission.
Coordinator CSIRT decision, written down	Choose your CSIRT designated as coordinator from ENISA's published list before the first event, and record why. ENISA states that a notification sent to the wrong coordinator may be invalidated and has to be resubmitted to the correct one.
Product portfolio inventory	A current list of products and the Member States where each has been made available. Without it, the early warning cannot indicate the affected territories correctly.
Documented internal escalation	A written procedure that gets the organisation from detection to SRP submission inside 24 hours, with out-of-hours coverage. "Without undue delay and in any event within 24 hours" leaves no room for ad hoc escalation.

Timeline: the cutover and the first reportable event

Official ENISA sources

ENISA states that its guidance reflects current best knowledge and may change. Check these sources before relying on a specific step.

Document	Link	ENISA status
SRP portal	portal.cra-srp.enisa.europa.eu	Available from 11 September 2026
CRA SRP - AR User Manual (55 pages)	AR User Manual (direct PDF)	Version 1.1, last updated 10 September 2026
CRA SRP guidance, Particular Exceptional Circumstances	PEC guidance	Updated September 2026
CRA Single Reporting Platform, Terms and Conditions	Terms and Conditions	Updated 10 September 2026
ENISA SRP page	Single Reporting Platform (SRP)	Programme page, factsheet, videos
SRP frequently asked questions	Frequently Asked Questions	Updated 10 September 2026
CRA SRP Glossary, field by field	CRA SRP Glossary	Version 1.3
List of CSIRTs Designated as Coordinators	Coordinator list	Updated 10 September 2026
CRA Single Reporting Platform Factsheet (PDF, English)	www.enisa.europa.eu/media/57221	English only, no version date on the file
CRA SRP - AR User registration	AR User registration	Updated 10 September 2026
CRA SRP - AR Notification submission and update	AR Notification submission and update	Updated 9 September 2026
CRA SRP - AR Interface functions	AR Interface functions	Updated 9 September 2026
CRA SRP Status	SRP status page	Live availability indicator. Reads both ways at the time of writing
Commission reporting page and FAQs on CRA implementation	CRA reporting	Section 5 covers reporting
Commission implementation guidance	Guidance, 27 July 2026	Section 9.1 covers reporting

The Glossary is the one to read before your first submission rather than during it. It covers 39 fields, 18 common ones plus 12 for an actively exploited vulnerability and 9 for a severe incident, and for each field it gives the meaning, how to complete it, an example, the expected format, and whether the field is required, optional, required if the information is available, or carried forward from the previous stage. It is English only, and it is now the single field reference: the FAQ points you here rather than listing the fields itself. Note what the 39 do not include. The platform fills in the reporting timestamps and the reporter for you, and the notification-stage selector is something you choose rather than a data field you prepare, so none of them appear in the Glossary and none of them need drafting in advance.

ENISA support address for the platform: cra-srp-helpdesk@enisa.europa.eu. Two further addresses cover the platform's own security, not your products: report a security incident involving the platform to cra-srp-security@enisa.europa.eu, and a vulnerability you find in the platform itself to responsible-disclosure@enisa.europa.eu, listed in ENISA's security.txt. Neither address is a route for CRA notifications about your own products.

The registration flow

ENISA updated its step-by-step registration guidance on 10 September 2026 and still marks it subject to change. For the click-by-click path, with screenshots of registration, the three submission stages and updating a notification, ENISA's AR User Manual is the fuller reference.

Assigned Representative is a platform role, not a legal one. ENISA calls the SRP user who files for a manufacturer or an open-source software steward an Assigned Representative, or AR. That is an SRP account role, separate from a CRA authorised representative appointed by written mandate. The guidance applies even when an EU-established manufacturer has appointed no authorised representative.

For a Primary AR, the flow is:

1. Open portal.cra-srp.enisa.europa.eu, select your AR role, and continue.
2. Select the CSIRT designated as coordinator from the drop-down. Identifying the right one is the manufacturer's responsibility.
3. Authenticate through EU Login.
4. Read and accept the legal agreement.
5. Confirm your pre-filled personal details, which come from EU Login and cannot be edited in the platform.
6. Enter the manufacturer name, plus optional additional information.

The platform then creates the manufacturer entity, your account becomes Active with the AR Primary User role, the association is submitted to your coordinator CSIRT for validation, and a confirmation email follows. With a working EU Login account this takes minutes.

A Secondary AR registers differently: they start from the emailed invitation, authenticate through EU Login, confirm their pre-filled personal details, then accept the manufacturer association.

One Primary AR per manufacturer, plus up to 20 Secondary ARs. In the platform these carry the role labels AR Primary User and AR Backup User.

• The Primary AR holds the administrative functions: managing the manufacturer entity, and inviting or removing Secondary ARs. ENISA gates that invite: it is available only to a Primary AR whose AR-manufacturer association the coordinator CSIRT has validated and marked Verified. Until then you cannot add your backup person. The association is validated per manufacturer, so an AR acting for several manufacturers is verified for each one separately.
• A Secondary AR joins from an emailed invitation and confirms pre-filled manufacturer details. If that registration is not completed within 7 days, the record moves to Invitation Expired and the invitation has to be sent again.
• A Secondary AR can later claim the Primary role.

Naming a Secondary is optional. Do it anyway, because EU Login accounts are personal, there is no shared company login to fall back on, and the 24-hour clock does not wait for whoever holds the only account.

Validation runs in parallel and does not block your notifications. The coordinator CSIRT validates the AR-manufacturer association after first access. Pending validation does not stop you submitting, but it does stop you inviting a Secondary AR. Procedures and processing times vary by CSIRT. ENISA asks manufacturers not to register pre-emptively and to start registration and validation when they actually need to submit, which keeps each CSIRT's validation queue manageable.

An unverified AR may submit up to 20 notifications for one manufacturer before validation becomes mandatory. ENISA's FAQ, its interface guide and the AR User Manual all give the same number. Treat the allowance as a safety valve against a slow validation queue rather than headroom you can plan against, and complete validation.

Our reading of ENISA's advice: split it in two. Create the personal EU Login accounts and enrol MFA now, because that part involves a device, a phone and somebody's calendar. Leave the SRP registration itself for the day you need it, exactly as ENISA asks.

Have these ready before you start:

• Legal entity: who the manufacturer is and where its main establishment sits.
• Authority contact: the Single Reporting Platform contact for ENISA and coordinator-CSIRT messages, separate from the user-facing channel.
• Product coverage: the product portfolio and Member States where affected products are made available.
• Coordinator routing: the CSIRT assignment under the main-establishment and fallback rules.

After registration, the same end-point handles later submissions: the 24-hour early warning, the 72-hour notification, CSIRT-requested intermediate reports, and the final report.

There is no Single Reporting Platform API at the initial release. ENISA says organisations may automate their internal reporting workflows and integrate CRA reporting into their own systems, and that API functionality may be considered in a future phase, but the submission itself happens in the interface. The practical split: automate the preparation, not the filing. Pull the product name and version, the affected Member States, and the CVE or EUVD identifier out of your own systems into a ready-to-paste draft, and let a named person paste it in.

The platform's counters are not your deadline

The platform shows counters for the 72-hour notification and the final report and sends reminder emails against them. ENISA is explicit that they exist for visibility and do not replace the reporting obligations. Three details matter in this release.

• The 72-hour counter runs from your early-warning submission, not from awareness. It shows a due date 48 hours after the 24-hour early warning was submitted. File the early warning late in the 24-hour window and the platform can flag the notification as overdue while you are still inside the legal window. ENISA says a future release will calculate it from the awareness date instead.
• There is no counter for the final report on an actively exploited vulnerability. ENISA's reason is that the deadline depends on the date and time a corrective or mitigating measure becomes available, which is not a date the platform can count down to. For severe incidents the counter shows one month after the 72-hour notification.
• The awareness field for an exploited vulnerability is not settled yet. The SRP Glossary marks "Date and time when you become aware of the Actively Exploited Vulnerability" as required at the 24-hour early warning and, in the same row, notes that the field arrives in the next release of the platform. So it is required on paper and may not be on screen. Keep your own awareness timestamp and be ready to supply it either way. For incidents there is a related field, but in this release the Glossary says it is named "Date and time when the incident was detected (UTC time)", which is not the same thing as awareness.

So keep the awareness timestamp in your own system, and start your own clock there. The platform's counter is a reminder. The deadline is the law.

What each Single Reporting Platform submission must contain

Article 14 defines three notification stages per reportable event. The content requirements differ between the actively exploited vulnerability stream and the severe incident stream.

Actively exploited vulnerability:

Stage	Deadline	Minimum content required
Early warning	24h from awareness	Indication that a vulnerability is actively exploited; Member States where the product is made available, where known
Vulnerability notification	72h from awareness	General information about the product; general nature of the exploit and the vulnerability; corrective or mitigating measures taken; measures users can take; sensitivity indication
Final report	14 days after a corrective or mitigating measure is available	Vulnerability description including severity and impact; information about any malicious actors exploiting it, where available; security update or corrective measure details

Severe incident:

Stage	Deadline	Minimum content required
Early warning	24h from awareness	Whether the incident is suspected of being caused by unlawful or malicious acts; Member States where the product is made available, where known
Incident notification	72h from awareness	Nature of the incident; initial assessment; corrective or mitigating measures taken; measures users can take; sensitivity indication
Final report	1 month after the 72h incident notification	Detailed description of the incident including severity and impact; type of threat or root cause likely to have triggered it; applied and ongoing mitigation measures

The CSIRT designated as coordinator may also request an intermediate report between the 72h notification and the final report. Neither stream requires CVE IDs or CVSS scores at the early warning stage. The 24-hour obligation is to notify, not to have completed the analysis. Full technical detail goes in the notification and final report stages.

Internal escalation: hitting the 24h clock

The 24-hour clock starts at awareness, not at confirmation. The hard part is getting from "we just learned" to "we just submitted" inside 24 hours, including out-of-hours. A triage process that "usually takes 48 hours" is structurally non-compliant. Detection, triage, parallel legal review, and submission all need to fit inside the same calendar day, including weekends and out-of-hours.

Step	Inside 24h?	Notes
Detection	Yes	Internal engineering, customer reports, monitoring, threat intel, CVD intake. Triage paths for "actively exploited" and "severe incident" must be distinct.
Triage	Yes	Use severity scoring signals (CVSS / EPSS / KEV) as inputs. Exploitation evidence is the trigger; severity alone is not.
Legal review	In parallel	A serial wait for legal sign-off loses the 24 hours. The manufacturer can flag sensitivity, and the platform can withhold dissemination on cybersecurity grounds.
Single Reporting Platform early warning	Yes	Vulnerability stream or severe-incident stream.
72h notification	After 24h	Within 72 hours of awareness.
Final report	14 days (vuln) / 1 month (incident)	Vulnerabilities: 14 days from corrective measure available. Severe incidents: one month from the 72-hour notification.

CSIRT routing

CSIRT routing follows the manufacturer's Union main establishment, meaning the Member State where cybersecurity decisions for the product are predominantly taken. If that cannot be determined, use the Member State where your EU establishment with the highest number of employees sits. Without a Union main establishment the fallback chain runs in order: the Member State where your authorised representative acts for the highest number of products, then the importer placing the highest number on the market, then the distributor making the highest number available, then the Member State with the highest number of users.

ENISA's list of CSIRTs designated as coordinators is dated 10 September 2026 and carries a contact page for each Member State. Confirm your coordinator against that list and write down the reason for the choice, because ENISA now states that a notification submitted to the wrong coordinator may be invalidated and has to be resubmitted to the correct one. The deadline runs from awareness rather than from a fresh start, so the hours lost to a resubmission come out of your own budget. After submission, cross-border dissemination to the CSIRTs of other affected Member States happens inside the platform.

One notification per event, even with EU subsidiaries

ENISA settled a question that comes up in every group structure: only one notification is required for a given actively exploited vulnerability or severe incident, even where the manufacturer has several branches or subsidiaries in the EU, or a parent company outside it. Coordinating across that structure is the manufacturer's own job.

Read the boundary carefully, because it is narrower than people hope. This is one manufacturer with branches and subsidiaries, not a licence for two legally separate manufacturers in the same group to share a single filing. Where two entities each place their own products on the market, each carries its own duty.

The two failure modes are worth writing into the procedure. Two subsidiaries file the same event and the coordinator CSIRT receives duplicates that look like two manufacturers. Or each entity assumes the other filed, and nothing arrives inside 24 hours. Name the filing entity and the filing person before the event, not during it.

Single Reporting Platform versus national CSIRT contact

Emailing a national CSIRT directly does not satisfy the CRA reporting obligation, even where the manufacturer has a prior working relationship with that CSIRT.

Channel	Mandatory for CRA reports?	What it covers
Single Reporting Platform	Yes	Actively exploited vulnerability reports; severe incident reports; the 72-hour notification and the final report
National CSIRT direct contact	No	Coordinated vulnerability disclosure coordination; sector threat intelligence sharing; informal incident response collaboration

Manufacturers that have an existing relationship with a national CSIRT can keep it for CVD coordination and sector intelligence exchange. What must move to the Single Reporting Platform is every mandatory notification. The platform handles cross-border routing to the other affected Member State CSIRTs, so one submission reaches all of them.

If you are not a manufacturer, the platform is not your channel. This release accepts only mandatory Article 14 notifications from manufacturers. A security researcher, a user, an importer or a distributor who wants to report a vulnerability goes to the relevant national CSIRT directly. ENISA says a submission from anyone else may be marked invalid in the platform.

If the platform is down. ENISA's answer is to wait and submit once it is available again. If you judge that immediate communication cannot wait, you may contact your coordinator CSIRT directly in the meantime, but the notification still has to go through the platform afterwards. Direct contact is an addition, never a replacement, and it is not a deadline extension. Keep a timestamped record of the outage, of what you attempted, and of any direct contact you made.

Common Pitfalls

• Enrolling EU Login and MFA during the incident. ENISA asks you not to register on the platform pre-emptively, and that is reasonable. It does not mean leaving identity until the event. Create the personal accounts, enrol MFA and test the sign-in now, so that same-day registration really is a few minutes.
• Letting the platform tell you the deadline. In this release the 72-hour counter runs from your early-warning submission plus 48 hours, and the awareness field for an exploited vulnerability may not be on screen yet even though the Glossary marks it required. Keep your own clock.
• Two subsidiaries filing, or neither. One notification per event for one manufacturer, and somebody has to own it. Name the filing entity and the filing person in the procedure.
• One person holding the only account. Appoint a Primary AR and at least one Secondary AR, and complete the invitation inside 7 days before it expires.
• Guessing the coordinator CSIRT during an incident. The list is published. A wrong coordinator can invalidate the notification and cost you hours you do not have.
• A generic security@ with auto-reply. Conflicts with the user-facing channel requirement and is unfit for the Single Reporting Platform authority channel.
• No or stale products mapped to the registration. The early warning must indicate the Member States where the product has been made available; without a current inventory, the early warning is incomplete.
• No internal SLA for the 24-hour clock. Detection-to-submission needs an explicit time budget.
• Filing via national CSIRT email. The Single Reporting Platform is the named channel; email to a national CSIRT is not equivalent.
• Treating the AR as a forwarding address. A non-EU manufacturer's AR mandate must explicitly cover reporting, and the AR must be ready to support Single Reporting Platform filing.