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 (SRP). The platform is not yet live; it goes operational on 11 September 2026, when reporting duties start to apply. ENISA states it will provide the access and registration instructions, plus training and dry-run support material, during June 2026, so the registration mechanics are still being published. This page covers what manufacturers should prepare now, the expected registration flow, and how to wire an internal escalation that fits the 24-hour clock. For cadences see vulnerability reporting.
Summary
- The Single Reporting Platform is the only reporting channel. Manufacturers notify ENISA and the coordinator CSIRT through the platform. National CSIRT email is not a substitute.
- Prepare before the first reportable event. The 24-hour clock does not pause for registration or routing problems. Keep legal-entity, product, contact and escalation data ready before the platform opens.
- Manufacturers are the obligated parties. Importers and distributors inform the manufacturer; they do not file reports themselves. An authorised-representative mandate can cover reporting for a non-EU manufacturer.
- Separate contact purposes. The user single point of contact is the user-facing channel. The platform authority contact should be managed separately so ENISA and the coordinator CSIRT can reach the reporting team.
- CSIRT routing follows the main establishment. Notifications go to the CSIRT designated as coordinator in the Member State of main establishment, with a fallback chain for non-EU manufacturers detailed in CSIRT routing below.
Onboarding is a readiness task, not an item to start after the first event hits the 24-hour clock.
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 also receives voluntary reports and is the channel for the 72-hour notification and the final report. ENISA says the voluntary-reporting functionality is enabled after 11 September 2026, so it follows the start of mandatory reporting rather than arriving earlier. Both reporting streams share the same platform architecture, even though ENISA still has to finalise the operational screens.
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.
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 AR 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
Six inputs the organisation should have ready before registration. The exact SRP screens are still specification-dependent, but missing these inputs will slow the first submission.
| Requirement | What you need |
|---|---|
| Legal entity in the Member State of main establishment | An unambiguous legal-entity record that lets the SRP assign the coordinator CSIRT (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. |
| Identity and authority evidence | Evidence that the filer can act for the manufacturer. Exact credential mechanics remain subject to ENISA's specifications and guidance. |
| 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: from today to first reportable event
ENISA is building the platform in cooperation with the CSIRTs network. The exact registration screens, credential mechanism, and electronic notification end-points remain subject to ENISA's specifications and the Commission's implementing acts. The framework below reflects the regulation's text and what is publicly known as of 2026-06-10; ENISA states the access and registration manual and instructions are promised during June 2026 but are not published yet, so verify against the official ENISA SRP page before treating any specific UI step as final. The 11 September 2026 cutover is fixed in the CRA timeline.
Expected registration flow
The exact SRP screens are still specification-dependent. ENISA has not yet published the live flow, so this section is a preparation checklist, not a final UI walkthrough.
Expect registration to cover four things:
- 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.
ENISA also says no Single Reporting Platform API will be provided at this stage. Plan initial reporting readiness around submission through the platform itself rather than API automation from your own tooling.
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. Without a Union main establishment, the fallback chain is AR's Member State, then importer, then distributor, then user concentration. After submission, cross-border dissemination to CSIRTs in other affected Member States happens inside the Single Reporting Platform. ENISA says it will provide the list of national CSIRTs designated as coordinators at a later stage, so confirm your coordinator assignment against ENISA's guidance once that list is published.
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; voluntary notifications; 72-hour and final reports |
| 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: every mandatory notification under Article 14. The platform handles cross-border routing to other affected Member State CSIRTs automatically. One submission reaches all relevant CSIRTs.
Common Pitfalls
- Registering only after the first reportable event. The 24-hour clock does not stop for onboarding. Register well before 11 September 2026.
- 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.
Frequently asked questions
Is the SRP live yet, and when does it go live?
Not yet. The Single Reporting Platform is not live for manufacturer reporting today; it goes live on 11 September 2026. ENISA is developing it with the CSIRTs network, and from that date manufacturers must be able to submit reportable actively exploited vulnerabilities and severe incidents through the platform. ENISA states it will provide the access and registration manual and instructions during June 2026; until they are published, the registration flow, credential mechanism and electronic notification end-points remain subject to ENISA's specifications and the Commission's implementing acts, so verify against ENISA's live guidance before relying on a specific UI step.
Do importers and distributors register on the SRP?
No. Importers and distributors do not take over the manufacturer's SRP reporting duty. Their CRA duty is to inform the manufacturer about a vulnerability without undue delay. SRP reporting remains the manufacturer's obligation.
Can a non-EU manufacturer register directly?
Possibly, but the fallback chain matters. A written AR mandate can cover mandatory reporting because the AR exclusions do not include reporting itself. For a manufacturer with no Union main establishment, routing then follows the available chain: authorised representative, importer, distributor, then user concentration.
How do I know whether to file an actively exploited vulnerability or a severe incident?
The two streams cover different situations. An actively exploited vulnerability is a flaw in your product that a malicious actor is using against your users. A severe incident is broader: any incident that can harm the product's ability to protect the availability, authenticity, integrity, or confidentiality of important data or functions, or that can lead to malicious code running in the product or in a user's systems. A compromise of your own build, release, or maintenance infrastructure that puts users at risk is one example, such as an attacker inserting malicious code into your update release channel.
A bug bounty submission or coordinated vulnerability disclosure report does not trigger either stream on its own. Mandatory notification applies once you have an actively exploited vulnerability or a qualifying severe incident.
The same attack can cross both boundaries at once. If an attacker exploits a flaw in your product and uses that access to compromise your build infrastructure, you file two separate reports, one for each stream, both with a 24-hour early warning from the same moment of awareness.
When exactly does the 24-hour clock start?
The moment anyone in your security team has credible information that a reportable event is happening. Not when management is briefed. Not when legal confirms it. Not when the root cause is established.
The 24-hour early warning only needs to include an indication of active exploitation and the Member States where your product is available. The detailed technical analysis goes in the 72-hour notification. The regulation designed it that way: you notify first, you investigate in parallel.
There is no assessment grace period. The clock runs from first credible awareness.
What if our SRP submission fails?
Use the Single Reporting Platform path first and preserve evidence of the failure. The Single Reporting Platform is the mandatory reporting channel, so fallback behaviour should follow ENISA or coordinator-CSIRT guidance once available. Tooling problems do not remove the 24-hour duty; keep a time-stamped record of the outage, attempted submission and any alternative contact used.
Is the user single point of contact the same as the SRP registration contact?
No. The user contact and Single Reporting Platform authority contact serve different audiences. The user-facing contact supports vulnerability reports from users and cannot be limited to automated tools. The Single Reporting Platform contact should route ENISA and coordinator-CSIRT messages to the reporting team, even if ENISA later specifies the exact registration fields.