The Single Reporting Platform (SRP) provided for in the Cyber Resilience Act (CRA) shall become a technical tool to use for the reporting of actively exploited vulnerabilities and incidents impacting products with digital elements operating in the EU Digital Single Market.
The SRP will be used by CSIRTs and manufacturers for mandatory reporting and could be used by any natural/legal persons for voluntary reporting.
The CRA mandates manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents having an impact on the security of the product as of 11 September 2026 onwards using the Single Reporting Platform. Throughout 2025 and 2026, ENISA is undertaking a number of necessary steps to support the successful implementation of the platform.
The CRA brings transparency to the vulnerability disclosure processes and strengthens how EU CSIRTs can mitigate risks stemming from vulnerabilities.
Further information: Regulation - 2024/2847 - EN - EUR-Lex
Frequently Asked Questions
This is a collection of frequently asked questions on Cyber Resilience Act Single Reporting Platform (CRA SRP). Document is intended for publication on ENISA website and to be updated during implementation of CRA SRP
Please see also information about CRA reporting https://digital-strategy.ec.europa.eu/en/policies/cra-reporting in particular FAQ file there https://ec.europa.eu/newsroom/dae/redirection/document/122331
- 1. What is the Cyber Resilience Act’s Single Reporting Platform (CRA SRP)?
-
CRA SRP will be a centralized electronic system designed to simplify the reporting obligations for manufacturers and open-source software stewards under the Cyber Resilience Act. It will serve as a "single entry point", allowing for manufacturers to report actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements only once, rather than having to notify multiple national authorities individually.
Manufacturers will submit notifications electronically through the platform, which will allow them select CSIRT designated as coordinator (based on the location of the manufacturer's main establishment - see CRA Article 14(7) on determining relevant CSIRT for reporting) and ENISA simultaneously. The CSIRT will then disseminate the information without delay to other relevant CSIRTs in Member States where the product is available, and to market surveillance authorities as needed. The platform will incorporate security measures to protect confidentiality.
- 2. What is the legal basis for CRA SRP?
-
The legal basis for the operation of the SRP is the Cyber Resilience Act (CRA), which states in Article 16(1): For the purposes of the notifications referred to in Article 14(1) and (3) and Article 15(1) and (2) and in order to simplify the reporting obligations of manufacturers, a single reporting platform shall be established by ENISA. The day-to-day operations of that single reporting platform shall be managed and maintained by ENISA. The architecture of the single reporting platform shall allow Member States and ENISA to put in place their own electronic notification end-points.
Articles 14-17 of the CRA provide the details of the ecosystem for reporting of vulnerabilities. Additionally, in December 2025 the European Commission published a Delegated Regulation specifying the conditions for delaying the dissemination of notifications.
- 3. Who is responsible for establishing and managing the platform?
-
ENISA is tasked with establishing, managing, and maintaining the day-to-day operations of the CRA SRP. ENISA must also ensure the platform's security and implement appropriate technical and organizational measures to protect the information submitted.
- 4. When will the Single Reporting Platform be operational?
-
The platform is scheduled to be operational by 11 September 2026. This coincides with the date when the mandatory reporting obligations for manufacturers officially enter into application (art.14 of Cyber Resilience Act). A testing period is expected to take place before this date.
- 5. What must be reported via the platform?
-
Under CRA, manufacturers will be obliged to notify two specific types of occurrences:
- Actively Exploited Vulnerabilities: Vulnerabilities in products with digital elements for which there is reliable evidence that they have been exploited by a malicious actor;
- Severe Incidents: Incidents that have a severe impact on the security of the product with digital elements (e.g., compromising availability, authenticity, integrity, or confidentiality); the criteria for severity are defined in Article 14(5).
Open-source software stewards are subject to reporting obligations to the extent that they are involved with products with digital elements, as per Article 24(3) of CRA.
- 6. What else can be reported in the platform?
-
The platform will also offer functionality to allow voluntary reporting. This functionality to will be enabled in the CRA SRP after 11 September 2026.
Any natural or legal person may notify on a voluntary basis:
- Vulnerabilities contained in a product with digital elements;
- Cyber threats that could affect the risk profile of a product with digital elements;
- Incidents having an impact on the security of a product;
- Near misses that could have resulted in an incident.
- 7. What are the deadlines for reporting?
-
Reporting process starts at the moment manufacturer becomes aware of active exploitation of vulnerability or incident.
‘Actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner (CRA definition).
‘Incident having an impact on the security of the product with digital elements’ means an incident that negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of data or functions (CRA definition).
The manufacturers and open-source software stewards must adhere to specific deadlines:
- Early Warning: Without undue delay and in any case within 24 hours of becoming aware of the vulnerability or incident;
- Vulnerability/Incident Notification: Without undue delay and in any case within 72 hours of becoming aware, providing general information and an initial assessment;
- Final Report:
- For vulnerabilities: No later than 14 days after a corrective measure (e.g., patch) is available.
- For severe incidents: Within 1 month after the initial notification.
- 8. How does the Single Reporting Platform operate?
-
Manufacturers submit notifications electronically through the platform, which automatically routes them to the designated CSIRT coordinator (based on the manufacturer's main establishment) and ENISA simultaneously. The CSIRT then disseminates the information without delay to other relevant CSIRTs in Member States where the product is available, and to market surveillance authorities as needed. For sensitive reports, dissemination may be delayed on security grounds. More detailed information on the delayed dissemination process is provided in [Q21]. The platform incorporates security measures to protect confidentiality.
- 9. How will the platform be accessible and how the registration process will work?
-
Specific manual and instructions will be provided by ENISA in the course of June 2026.
- 10. Where can I get further information on of the application of the CRA?
-
To ensure smooth implementation of the CRA, the European Commission has set up a document “FAQs on the CRA Implementation”, which specifies in section 5 more details related to the reporting obligations under this Regulation. The Commission has also published a draft Communication intended to provide guidance on how to apply the CRA, which includes section 9.1 on reporting obligations. A final version of the Communication will be adopted shortly.
- 11. How is the term “actively exploited vulnerability” interpreted in practice?
-
The European Commission explains this term in its subsection 5.1 of its “FAQs on the CRA Implementation” – How can a manufacturer become aware of an actively exploited vulnerability or a severe incident?, alongside with other information related to the legal interpretation of CRA.
- 12. Do I need to report a vulnerability discovered in products made available before the entry into force of the CRA?
-
Please refer to the European Commission’s “FAQs on the CRA Implementation”, in particular for this context to the subsection 5.3 – Does a manufacturer need to report actively exploited vulnerabilities or severe incidents for products placed on the market before the CRA applies?
- 13. Do I need to report vulnerabilities that have been actively exploited before the CRA applies?
-
The manufacturer’s obligation to report actively exploited vulnerabilities applies once the manufacturer becomes aware of them. The European’s Commission draft guidance provides further explanations on when a manufacturer is regarded to have become aware (section 9.1). The obligation does not extend to reporting of vulnerabilities the active exploitation of which the manufacturer was already aware before the CRA reporting obligation applies.
- 14. If a vulnerability in my product has its source in a third-party component, am I still obliged to notify it?
-
Please refer to the European Commission’s FAQ in section 5.4 - If an actively exploited vulnerability is contained in a third-party component, are all manufacturers integrating that component required to notify it?
- 15. Can the notification workflow be automated for large number of notifications from one manufacturer?
-
Organisations might automate reporting workflows and integrate reporting requirements into their systems and databases, however no Application Programming Interfaces will be provided at this stage. The relevant data fields for reporting can be found in the next section of this FAQ (Q16).
- 16. What are the data fields to be filled in the reporting template?
-
The table below explains the fields that will be obligatory (stemming directly from CRA or identified by logical consequence) or optional at each stage of reporting:
Field
24h
72h
Final
Common fields
1
Notification type (Vulnerability/Incident) X
C
C
2
Notification level (24h/72h/Final) X
X
X
3
Reporting time - 24h A
A
A
4
Reporting time - 72h A
A
A
5
Reporting time - Final A
A
A
6
Reporter A
A
A
7
Name of manufacturer or open-source software steward X
C
C
8
Product X
C
C
9
Product Type (Default/Important/Critical) O
C
C
10
Product Category (If Product Type other than Default - CRA Annex III/IV) O
C
C
11
Member States where product available I
C
C
12
Title X
C
C
Vulnerability
v13
CVE ID O
C
C
v14
EUVD ID O
C
C
v15
General information, in particular: O
X
C
v16
a. General nature of the vulnerability O
X
C
v17
b. General nature of the exploit O
X
C
v18
Corrective or mitigating measures taken O
X
C
v19
Corrective or mitigating measures that users can take O
X
C
v20
Considered sensitivity of information O
I
C
v21
Date when corrective or mitigating measure has been available O
O
X
v22
Full description of the vulnerability, incl.: O
O
X
v23
a. Severity of the vulnerability O
O
X
v24
b. Impact of the vulnerability O
O
X
v25
Malicious actor that has exploited / is exploiting the vulnerability O
O
I
v26
Details about the security update / corrective measures available O
O
X
Incident
i13
Incident is suspected by unlawful or malicious acts X
C
C
i14
General information, about the nature of the incident O
X
C
i15
Date and time when the incident was detected O
X
C
i16
Date and time when the incident occurred O
X
C
i17
Initial assessment of the incident O
X
C
i18
Corrective or mitigating measures taken O
X
C
i19
Corrective or mitigating measures that users can take O
X
C
i20
Considered sensitivity of information O
I
C
Detailed description of the incident, incl.: O
O
X
i21
a. Severity of the incident: O
O
X
i22
1) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions;
2) it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elementsi23
b. Impact of the incident O
O
X
i24
Type of threat or root cause that is likely to have triggered the incident O
O
X
i25
Applied and ongoing mitigation measures O
O
X
A - automated (not visible for the submitter) X - obligatory C - by default copied from previous step, or updated O - optional I - obligatory if such information available - 17. Will any trainings be provided for the relevant parties?
-
ENISA recognises the need for sufficient preparation time to train all relevant contributors and reporting teams prior to the compliance deadline. Information that will support training and dry-run exercises will be available within the month of June.
- 18. How do I know what is the national CSIRT to which I should report through the CRA SRP?
-
The national CSIRT to which you should report through the SRP is essentially determined by your main location of establishment (or of the establishment of your authorised representative, if you are not established in the EU). The CRA Art.14(7) provides detailed information allowing for the manufacturer to identify the national CSIRT to report to.
Additional information (Iist of national CSIRTs designated as coordinators) will be provided by ENISA at the later stage.
- 19. What are the responsibilities of key entities involved with the CRA SRP?
-
- Manufacturers: Submit timely notifications and comply with the other obligations established by the CRA;
- Open-source software stewards: Submit timely notifications to the extent that they are involved with products with digital elements, as per Article 24(3);
- ENISA: Manages the platform, processes reports, prepares biennial trend reports (first due within 24 months of the reporting obligations starting), operates a helpdesk (especially for SMEs), and discloses fixed vulnerabilities to the European Vulnerability Database;
- CSIRTs Designated as Coordinators: Receive and assess reports, decide on dissemination delays, inform market surveillance authorities and the public if necessary, and provide helpdesk support alongside ENISA;
- European Commission: Adopts delegated and implementing acts (e.g., for delay criteria and report formats), evaluates the platform's effectiveness, and supports coordination of enforcement activities;
- Market Surveillance Authorities: Receive disseminated information and enforce compliance, such as through investigations or corrective actions.
- 20. Who receives the reports submitted to the platform?
-
As a general rule, when a manufacturer submits a report to the CRA SRP, it is simultaneously notified to:
- The CSIRT (Computer Security Incident Response Team) designated as the coordinator in the Member State where the manufacturer is established.
- ENISA (unless particularly exceptional circumstances apply).
The CSIRT designated as coordinator that initially receives the notification is then responsible for disseminating it without delay to other relevant CSIRTs across the EU via the platform.
- 21. Can the dissemination of a report be delayed or withheld?
-
Yes. In exceptional circumstances, the receiving CSIRT may decide to delay or withhold the dissemination of a notification to other Member States. This is strictly limited to cases where immediate dissemination is justified on security related grounds (e.g., if spreading the information would pose an even greater security risk).
The European Commission adopted a delegated act on 11 December 2025 to further specify the terms and conditions for applying these grounds.
In particularly exceptional circumstances, ENISA will not receive the full content of the 72-hour notification. This is only the case where, in the 72-hour notification, the manufacturer actively marks that at least one of the conditions listed in points (a) to (c) of Article 16(2) applies. In such case, ENISA only receives partial information, until the receiving CSIRT discloses the full notification.
- 22. How does the platform ensure security?
-
ENISA is legally required to take appropriate measures to manage risks to the platform's security and must notify the CSIRTs Network and the Commission of any security incidents affecting the platform itself.
Before its launch, the platform will be subject to user and security testing, to ensure its reliability. It will be also periodically re-checked.
- 23. How is the CSIRTs network involved?
-
As provided in CRA Article 16, ENISA is engaging the CSIRTs Network in development and future testing of the CRA SRP.