On 11 September 2026, the European Union’s Cyber Resilience Act (CRA) moved into an important operational phase.
The European Union’s cybersecurity requirements for products with digital elements have been accompanied by a dedicated mechanism for reporting certain serious cybersecurity events: the CRA Single Reporting Platform (SRP) operated by the European Union Agency for Cybersecurity (ENISA).
The concept is straightforward:
A manufacturer makes one notification through a European platform, rather than navigating separate reporting channels across multiple Member States.
But the significance of the platform goes well beyond creating another online reporting form.
The SRP establishes a common European mechanism through which information about actively exploited vulnerabilities and severe incidents affecting products with digital elements can be reported, coordinated and disseminated.
What is the CRA Single Reporting Platform?
The CRA Single Reporting Platform is ENISA’s online reporting mechanism for the mandatory cybersecurity notifications established under the Cyber Resilience Act.
It provides a centralised entry point for manufacturers subject to the CRA’s reporting requirements.
The reporting architecture connects several participants:
Manufacturer
↓
CRA Single Reporting Platform
↓
CSIRT designated as coordinator (CDaC)
↓
Relevant national CSIRTs and authorities
with ENISA receiving the notification through the platform.
The objective is to eliminate unnecessary duplication at the manufacturer’s end while enabling coordinated information sharing among the relevant European cybersecurity authorities.
A manufacturer whose product is available in several EU Member States therefore does not need to create an independent CRA notification for every country. The SRP provides the common reporting channel through which the information enters the European coordination process.
What must be reported?
The initial operational version of the platform focuses on two mandatory categories under the CRA.
1. Actively Exploited Vulnerabilities
An Actively Exploited Vulnerability (AEV) is a vulnerability for which there is reliable evidence that a malicious actor has exploited it without authorisation.
This distinction is critical.
The discovery of a vulnerability does not automatically mean that it is an AEV.
Similarly, the assignment or publication of a CVE identifier does not, by itself, trigger the AEV reporting requirement.
The determining factor is evidence of actual exploitation.
The distinction can therefore be represented as:
Vulnerability discovered
→ Does not automatically mean AEV
Evidence of exploitation emerges
→ AEV reporting obligation may apply
The CRA consequently separates ordinary vulnerability discovery from the more serious situation in which a vulnerability is being actively exploited.
2. Severe Incidents
The second mandatory reporting category covers severe incidents having an impact on the security of a product with digital elements.
The CRA’s concept of security encompasses properties such as:
- Confidentiality
- Integrity
- Authenticity
- Availability
The reporting obligation is therefore concerned with incidents that have a sufficiently serious impact on the security of the product within the scope of the CRA.
The SRP is consequently not intended to function as a general-purpose incident reporting mailbox.
It implements specific regulatory reporting obligations established by the CRA.
The reporting clock
One of the most important characteristics of the CRA reporting regime is that reporting occurs in stages.
The manufacturer does not necessarily have to possess the complete forensic picture before making the initial notification.
Instead, the process progressively builds the information available to the relevant authorities.
Within 24 hours — Early Warning
Once the manufacturer becomes aware of a reportable event, an Early Warning must be submitted without undue delay and, in any event, within 24 hours.
The purpose is to establish an early notification while the investigation may still be developing.
The first notification therefore does not represent the end of the investigation.
It initiates the reporting process.
Within 72 hours — Notification
A more detailed notification follows.
This must be submitted without undue delay and, in any event, within 72 hours of becoming aware.
The 72-hour notification provides additional information and an initial assessment of the event.
The platform links this notification to the preceding Early Warning, creating a continuous reporting record rather than two unrelated submissions.
The final report
The final reporting deadline depends on the type of event.
For an Actively Exploited Vulnerability
The final report is due within 14 days after a corrective or mitigating measure becomes available.
For a Severe Incident
The final report is due within one month of the 72-hour notification.
The resulting timelines are:
Actively Exploited Vulnerability
Awareness
→ Early Warning — 24 hours
→ 72-hour Notification
→ Corrective or mitigating measure becomes available
→ Final Report — within 14 days
Severe Incident
Awareness
→ Early Warning — 24 hours
→ 72-hour Notification
→ Final Report — within one month
This staged model recognises an important reality of cybersecurity investigations: information develops over time.
The initial notification starts the process; subsequent notifications progressively establish a more complete picture.
Who interacts with the platform?
The SRP incorporates several roles into the reporting process.
Manufacturer
The manufacturer is responsible for fulfilling the applicable CRA reporting obligation.
Where the same event affects a product distributed across several Member States, the reporting model is designed around one notification for the particular AEV or severe incident, rather than separate manufacturer submissions for every country.
Assigned Representative
The platform uses an Assigned Representative (AR) model for interaction with the system.
The Assigned Representative can perform activities including:
- Registering with the platform
- Establishing the manufacturer association
- Preparing notifications
- Submitting notifications
- Updating notifications
- Monitoring reporting activity
- Managing relevant alerts
The platform supports Primary and Secondary/Backup Assigned Representative roles.
Access requires an EU Login account with multi-factor authentication.
CSIRT designated as coordinator
The CSIRT designated as coordinator (CDaC) provides the national coordination point for the notification.
The manufacturer selects the appropriate coordinating CSIRT through the reporting process.
The CDaC can then coordinate the information and disseminate it to other relevant CSIRTs in Member States where the product is available.
ENISA
ENISA operates the Single Reporting Platform and receives the notifications within the European reporting framework.
This gives the EU-level cybersecurity agency visibility into reported events and enables coordination across the European cybersecurity ecosystem.
The platform therefore connects manufacturer-level reporting with European-level cybersecurity coordination.
Structured reporting rather than an open-ended narrative
The SRP is based on structured information.
ENISA has published a dedicated CRA SRP Glossary explaining the fields used by the platform, their meaning, expected formats and their applicability to different reporting stages.
Depending on the notification stage and type, information can include:
- Product details
- Vulnerability or incident information
- Timing
- Initial assessment
- Corrective or mitigating measures
- Additional information relevant to the event
This structured approach matters because the information submitted by a manufacturer may ultimately be consumed by multiple cybersecurity authorities.
The objective is therefore not simply to submit a written incident description.
It is to create consistent, structured regulatory information that can be processed and shared across jurisdictions.
Particularly Exceptional Circumstances
The CRA also recognises that vulnerability information can sometimes be dangerous to disseminate immediately.
For certain actively exploited vulnerabilities, the reporting framework provides for Particularly Exceptional Circumstances (PEC).
The mechanism addresses situations in which immediate dissemination of information could create additional security risks.
Where the applicable conditions are met, PEC can be indicated as part of the reporting process.
The coordinating CSIRT then assesses the circumstances and determines the appropriate handling and dissemination.
This introduces an important balance into the CRA framework:
Rapid information sharing
versus
Avoiding additional security harm caused by premature dissemination.
The regulation therefore recognises that disclosure is not always synonymous with security.
In some circumstances, when information is shared can be just as important as what information is shared.
The SRP is not a general vulnerability disclosure portal
A common misconception would be to treat the SRP as a European replacement for conventional vulnerability disclosure mechanisms.
It is not.
The initial operational platform is focused on the mandatory reporting requirements under the CRA.
In particular:
Actively Exploited Vulnerability → mandatory CRA reporting
Qualifying Severe Incident → mandatory CRA reporting
A vulnerability that has merely been discovered does not automatically become an SRP report simply because it is serious or has a CVE.
ENISA also plans further functionality for voluntary reporting under Article 15, covering areas such as vulnerabilities, cyber threats and security-impacting incidents.
That functionality is part of the platform’s future development rather than the initial mandatory reporting capability.
What about APIs and automation?
Modern product-security environments are increasingly automated.
Vulnerability management platforms, PSIRT systems, incident-management platforms and security databases can generate large amounts of structured information.
It would therefore be natural for manufacturers to expect direct system-to-system integration with the SRP.
However, the initial SRP release does not provide an API.
Organisations can automate their internal processes, but the actual submission to the SRP currently takes place through the platform interface.
ENISA has indicated that API functionality may be considered in a future phase.
This means the current model remains primarily human-mediated at the final submission boundary, even when the information used to prepare the notification may originate from automated internal systems.
What happens next?
The launch of the SRP is not the final stage of the CRA reporting ecosystem.
The platform is expected to evolve.
Two developments are particularly important.
Voluntary reporting
Future functionality is expected to support voluntary notifications under Article 15.
Open-source software stewards
The CRA also introduces specific obligations for open-source software stewards.
Their relevant reporting obligations apply from 11 December 2027, creating another phase in the expansion of the European reporting framework.
The SRP will therefore progressively move beyond its initial manufacturer-focused mandatory reporting capability.
From technical vulnerability to regulatory event
The most important conceptual change introduced by the CRA reporting mechanism is the connection between technical cybersecurity events and regulatory obligations.
A vulnerability can begin as a technical finding.
But when reliable evidence demonstrates active exploitation, it can become a reportable regulatory event.
Likewise, a serious security incident affecting a product with digital elements can move from being an isolated technical occurrence to becoming part of a coordinated European notification process.
The journey can be represented simply:
Security event
↓
Assessment
↓
CRA reporting criteria
↓
24-hour Early Warning
↓
72-hour Notification
↓
Coordinated handling
↓
Remediation / mitigation
↓
Final Report
This creates a formal bridge between product cybersecurity, vulnerability handling and European regulatory coordination.
Why the SRP matters
The real significance of the ENISA CRA Single Reporting Platform is not the web interface itself.
It is the infrastructure behind it.
For years, cybersecurity reporting has often operated through a fragmented landscape of vendors, national authorities, vulnerability databases, incident-response organisations and disclosure mechanisms.
The CRA introduces a European regulatory framework around cybersecurity for products with digital elements.
The SRP provides the reporting mechanism that makes part of that framework operational.
Its model is deliberately simple:
One manufacturer
→ One reporting channel
→ One coordinated notification
→ Relevant European cybersecurity authorities
The complexity is handled behind the reporting gateway rather than being placed entirely on the manufacturer.
The European cybersecurity reporting landscape is changing
The launch of the CRA Single Reporting Platform represents an important transition.
Cybersecurity vulnerabilities are no longer exclusively technical matters.
For products covered by the CRA, certain cybersecurity events now have a defined regulatory lifecycle.
The 24-hour Early Warning establishes the urgency.
The 72-hour Notification adds substance.
The Final Report closes the reporting cycle.
The CSIRT coordination mechanism connects national cybersecurity authorities.
And ENISA’s platform provides the common European reporting infrastructure.
The broader CRA cybersecurity requirements will follow their own implementation timetable, but the reporting mechanism is already operational.
That makes 11 September 2026 an important date in the evolution of European product cybersecurity.
The European Union has moved another step from establishing cybersecurity requirements on paper to creating the infrastructure through which those requirements are actually exercised.
And the message from the new reporting regime is clear:
When a qualifying cybersecurity event occurs, reporting is no longer a fragmented national exercise. Europe now has a single gateway for it.
Official resources
ENISA CRA Single Reporting Platform
ENISA — CRA Single Reporting Platform
ENISA — CRA SRP Frequently Asked Questions
