About the author: Kohei Kurihara, Privacy Expert
[Disclaimer] This article reflects the author's personal views. The author is not a licensed attorney, and this article is not intended as legal advice.
Introduction
The EU Cyber Resilience Act (hereafter, the EU CRA) was adopted on October 23, 2024. The law is designed to require that products with digital elements (connected products) placed on the EU market meet cybersecurity requirements.
For companies that sell products in Europe, the rules around cybersecurity are changing, so it's necessary to check the upcoming schedule and sort out what needs to be addressed. In particular, reporting obligations begin on September 11, so it's important to first confirm what requires an initial response.
Background to the Cyber Resilience Act and the upcoming schedule
As for the background to the law, while the EU had rules that applied to specific products, there was no framework requiring horizontal application of the law. The EU CRA was therefore adopted by amending the L-category framework regulation adopted on January 15, 2013, the EU Market Surveillance Regulation adopted on June 20, 2019, and the Representative Actions Directive adopted on November 25, 2020.
One point companies should watch closely is that the law has several links to data and consumer protection. According to the Official Journal of the European Union published on November 20, 2024, taking cybersecurity measures will protect the personal data of consumers and organizations, and the text also refers to protecting individuals' privacy.
At first glance, parts of it may look like a law simply to strengthen cybersecurity, but it explicitly states that market surveillance authorities will also cooperate with data protection authorities in their oversight, so companies are also expected to consider cybersecurity measures from the perspective of the consumers who use their products.
Preparations, including standardization, are underway ahead of full application on December 11, 2027. For the upcoming schedule, the author created a chronological timeline based on a site published by i46 s.r.o.
*This timeline reflects the projected schedule as of now, and things may not necessarily proceed according to it.
| Date | Milestone | Details and actions |
|---|---|---|
| September 11, 2026 | Reporting obligations apply | - Manufacturers' reporting obligations: When an actively exploited vulnerability or a severe incident occurs, manufacturers are required to report to the European Union Agency for Cybersecurity (hereafter, ENISA) and to national CSIRTs. - Platform readiness: ENISA is preparing to have the Single Reporting Platform (hereafter, SRP) set out in Article 16 operational by the deadline. |
| October 31, 2026 | Development of the initial core standards | - Development of the two core standards (secure development and vulnerability handling) is expected to be completed. *This date was pushed back two months from the original deadline of August 30, 2026, by a draft amendment in July 2026. |
| December 31, 2026 | Development of product-specific standards | - Product-specific standards are developed. *The original deadline was October 30, 2026, but a draft amendment by the European Commission in July 2026 pushed it back two months to December 31, 2026. |
| October 30, 2027 | Development of horizontal standards | - Horizontal standards are developed, and preparations are made so that manufacturers can comply with the standards that have been in development over the previous year. |
| December 11, 2027 | Full entry into application | - Compliance with all requirements: Manufacturers must comply with all requirements under the law. - CE marking: Products placed on the EU market must meet the essential requirements and obtain CE marking. |
Based on the projected timeline, most standards development is expected to progress by the end of the year, and before full application, development of horizontal standards, not just product standards, is expected to move forward as well. A reasonable approach is to first set "applying the reporting obligations," which begin on September 11, as the goal and move forward with measures step by step.
What applying the reporting obligations requires
Article 14 of the EU CRA requires manufacturers to report to ENISA on the status of vulnerabilities, with a CSIRT acting as coordinator. For the purpose of fulfilling the reporting obligation, Article 14 requires the following to be reported via the SRP provided by ENISA.
*CSIRT stands for Computer Security Incident Response Team. The Nippon CSIRT Association describes it as a general term for organizations that handle computer security incidents, which constantly collect and analyze incident-related information, vulnerability information, and information on signs of attacks, and carry out activities such as developing response policies and procedures.
| Stage | Deadline | Purpose of the report | Main report contents - Example actions |
|---|---|---|---|
| Stage 1: Early warning | Within 24 hours | Early sharing of the situation | - Notification that the issue has been discovered - Scope of impact within the EU (products and regions affected) |
| Stage 2: Interim report | Within 72 hours | Update on the current situation | - Detailed information on the vulnerability - Interim risk mitigation measures (workarounds and user-side measures) |
| Stage 3: Final report | Within 14 days after a corrective or mitigating measure becomes available | Post-incident review and report on permanent measures | - Implementation of mitigation measures (applying security updates, etc.) - Root cause and scope of impact of the vulnerability, and information on malicious actors (if known) - Security patches and details of specific measures |
*Table created by the author based on information published in the Official Journal of the European Union
The law also sets out reporting obligations for security incidents that pose a threat to products. For the purpose of fulfilling the reporting obligation, Article 14 requires the following to be reported via the SRP provided by ENISA.
| Stage | Deadline | Purpose of the report | Main report contents - Example actions | |
|---|---|---|---|---|
| Stage 1: Early warning | Within 24 hours | Early sharing of the situation | - Notification that the threat or incident has been discovered | - Scope of impact within the EU (products affected and extent of damage) |
| Stage 2: Interim report | Within 72 hours | Assessment of the situation and sharing of the response plan | - Incident details and assessment information | - Interim damage mitigation - Methods for containing damage |
| Stage 3: Final report | Within one month after submission of the 72-hour report | Post-incident review and report on implementation of mitigation measures | - Completion of damage mitigation measures - Confirmation of incident details and scope of impact | - Specifics of the threat that caused the incident - Incident mitigation measures underway and already implemented |
*Table created by the author based on information published in the Official Journal of the European Union
The CSIRT (coordinator) to which vulnerabilities and incidents are reported is the CSIRT of the Member State where the manufacturer's main establishment in the EU, where it primarily makes cybersecurity decisions, is located. Note that establishing a European base is not itself required for reporting. If a manufacturer has no main establishment in the EU, the competent Member State (CSIRT) is determined according to the following order of priority.
| Priority | Criterion | Applicable Member State (competent CSIRT) |
|---|---|---|
| 1st priority | Authorized representative | The Member State where the authorized representative acting on behalf of the manufacturer is established (based on the representative handling the largest number of the products concerned) |
| 2nd priority | Importer | The Member State where the importer that places the largest number of the manufacturer's products on the market is established |
| 3rd priority | Distributor | The Member State where the distributor that makes the largest number of the manufacturer's products available on the market is established |
| 4th priority | End users | The Member State with the largest number of users of the manufacturer's products |
*Table created by the author based on information published in the Official Journal of the European Union
The manufacturer must appropriately notify consumers of product vulnerabilities and security incidents that pose a threat. Notifications must state not only whether it is a vulnerability or an incident, but also risk mitigation measures and corrective actions. In addition, notifications must be provided in a structured, machine-readable format so that consumers can respond to vulnerabilities and incidents themselves.
If the manufacturer cannot notify consumers directly, it designates the CSIRT as coordinator to provide appropriate notification to consumers.
Working with ENISA's Single Reporting Platform
To make it easy to fulfill the reporting obligations described above through a system, Article 16 of the Cyber Resilience Act requires ENISA to establish the SRP. ENISA will design and manage the SRP, which is planned to allow reports to be submitted via electronic notification.
*Overview of the "Single Reporting Platform (SRP)" created by the author based on materials published by ENISA
When a report is submitted through the SRP, the notification reaches the CSIRT of the relevant EU market, and the same notification also reaches ENISA. The report is then passed via the CSIRT to that country's market surveillance authority, which decides whether to take enforcement action.
As per the schedule above, reporting obligations using the SRP apply from September 11, 2026, so companies need to sort out their readiness in advance, including whether they have anything to report.
How to register for the Single Reporting Platform (SRP)
From here, I'll walk through, step by step, how to register for the SRP, which becomes available from September 11.
1. Select the person who will act as representative and register for EU Login
To use the SRP, you need to appoint a representative called an Assigned Representative (hereafter, AR) to submit reports. The AR signs in to EU Login in advance with an email address and password and enters registration information.
*The EU Login page the author registered with
By registering the AR in advance and having the registration verified, manufacturers or open-source software stewards can submit reports through the AR. The AR is verified by the CSIRT (this is not an obligation for submitting a report), but because the verification process differs depending on the CSIRT of the country concerned, manufacturers or open-source software stewards are expected to handle verification themselves in cases where special notification is required.
2. Register with the SRP
To register with the SRP, you need to enter the required information following the form registration steps.
| Step | Task | Details and input |
|---|---|---|
| Preparation | EU Login authentication | Authenticate with the system using your EU Login account |
| Step 1 | Review consent items | Review and agree to the legal consent items (terms of use, privacy policy, etc.) |
| Step 2 | Confirm account information | Confirm that the pre-registered basic information (last name, first name, email address, official legal entity name) is correct |
| Step 3 | Enter manufacturer information | Enter the company's details (legal name, registered address, other required additional information) |
| Step 4 | Set role (AR registration) | Within the registration steps, select and register AR (Assigned Representative) as the user's role, then click "Continue" |
| Step 5 | Select competent CSIRT | Select the relevant CSIRT to be designated from the dropdown menu, then click "Continue" to finish |
*At the time this article was written, the SRP website had not yet been launched, so the author based this on the registration guidance published by ENISA (published July 31, 2026, updated August 3). ENISA itself notes that "the content is subject to change," so please check the latest guidance when actually registering.
Once registration is complete and approved, the AR is linked to the manufacturer, the account becomes active, and the AR is appointed to the primary role. Along with a confirmation email, if manufacturer information was entered, the manufacturer's information is also registered in the SRP.
*After the primary AR is registered, an invitation email may be sent to a secondary AR (a sub-AR under the primary AR) for registration. In this case, the sub-AR opens the email sent by the primary AR and completes the registration process. Since the invitation is sent by the primary AR, the sub-AR accepts the invitation to complete registration. After registration, the sub-AR acts as a backup user for the primary AR.
How to submit reports on the Single Reporting Platform (SRP)
The AR must submit report notifications through the SRP. There are two types of reports: reports of vulnerabilities (Actively Exploited Vulnerability, hereafter AEV) and reports of threatening incidents (Severe Incident, hereafter SI). The purpose of these reports is to request a review by the relevant CSIRT and consider the next steps. The early warning, 72-hour report, and final report are each handled according to the following steps.
| Reporting phase | Prerequisites and actions | Contents to enter | Finalize and submit | Follow-up and notes |
|---|---|---|---|---|
| Early warning | Select "New report notification" in the SRP (pre-registered AR information is loaded) | • Information required for the early warning notification • Manufacturer (select existing or register new) • Additional notes (optional: enter under "Additional items") | Select "Submit report notification" or "Save entries" | After submission, the CSIRT carries out verification. Once complete, "Verification complete" and the "Response date and time" are displayed |
| 72-hour report | After logging in to the SRP, open the dashboard, review the early warning contents, and select the relevant "Early warning" | Required fields in the 72-hour report tab | Select "Submit report notification" or "Save entries" | |
| Final report | After logging in to the SRP, open the dashboard, review the 72-hour report contents, and select the relevant "Final report" | Required fields in the final report tab | Select "Submit report notification" or "Save entries" |
*Table created by the author based on information published on the ENISA website
In addition to the steps in each reporting phase, you can amend the contents of a report notification if its amendment deadline has not yet passed or if the final report has not yet been submitted.
Review the report content template and get ready before the SRP launches on September 11
As described above, the SRP makes it easy to submit report notifications, so you need to review the reporting procedure in advance and prepare ahead of the September 11 launch.
Below is the template, published by ENISA in its FAQ, of the items to include when submitting a report notification.
| Common items | Early warning (within 24 hours) | 72-hour report | Final report | |
|---|---|---|---|---|
| 1 | Notification type (vulnerability/incident) | X | C | C |
| 2 | Notification type (early warning/72-hour report/final report) | X | X | X |
| 3 | Report time - early warning | A | A | A |
| 4 | Report time - 72-hour report | A | A | A |
| 5 | Report time - final report | 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 classification (whether the product type is default; see CRA Annex III/IV) | O | C | C |
| 11 | EU regions where the product is made available | I | C | C |
| 12 | Title | X | C | C |
| Vulnerability items | ||||
| v13 | CVE ID (Common Vulnerabilities and Exposures identifier) | O | C | C |
| v14 | European Vulnerability Database | O | C | C |
| v15 | General information | O | X | C |
| v16 | a. Description of the nature, characteristics, and mechanism of the vulnerability (security flaw) | O | X | C |
| v17 | b. Basic information broadly describing how the exploit works, what it targets, and what impact it has | O | X | C |
| v18 | Corrective and mitigating measures already taken for the vulnerability | O | X | C |
| v19 | Corrective and mitigating measures users can take for the vulnerability | O | X | C |
| v20 | Potentially sensitive information | O | I | C |
| v21 | Date when corrective and mitigating measures for the vulnerability will be made available | O | O | X |
| v22 | Detailed description of the vulnerability | O | O | X |
| v23 | a. Severity of the vulnerability | O | O | X |
| v24 | b. Impact of the vulnerability | O | O | X |
| v25 | Factors in the exploitation of the vulnerability | O | O | I |
| v26 | Details of security update status and corrective measures | O | O | X |
| Severe incident items | ||||
| i13 | Unlawful or malicious nature of the incident | X | C | C |
| i14 | General information about the incident | O | X | C |
| i15 | Date and time the incident was detected | O | X | C |
| i16 | Date and time the incident occurred | O | X | C |
| i17 | Initial assessment of the incident | O | X | C |
| i18 | Corrective and mitigating measures already taken for the incident | O | X | C |
| i19 | Corrective and mitigating measures users can take for the incident | O | X | C |
| i20 | Potentially sensitive information | O | I | C |
| Detailed information on the incident | O | O | X | |
| i21 | a. Severity of the incident | O | O | X |
| i22 | 1) Where 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) Where 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 | |||
| i23 | b. Impact of the incident | O | O | X |
| i24 | Type of threat and route that caused the incident | O | O | X |
| i25 | Incident mitigation measures already implemented and those currently underway | O | O | X |
*Table created by the author based on information published in ENISA's FAQ
A - Filled in automatically (not shown to the submitter)
X - Required field
C - By default, overwritten with a copy of the contents reported in the previous step or in updated information
O - Optional field
I - Required if the information is available
In this article, I've walked through, step by step, the points companies should prepare ahead of September 11. I suspect many readers are struggling with questions such as who should serve as the local AR, and what to base their preparations on once the SRP launches.
Even just submitting a report through the SRP requires many checks in advance, so it's important to first review the products you sell in Europe and pay close attention to vulnerabilities and threatening incidents.
When doing so, I believe the best approach is to prepare what needs to be reported in incident response by referring to the template in advance, adding points specific to your company as you go, and keeping it as comprehensive documentation.
There is also time to spare before full application on December 11, 2027, so it's necessary to keep monitoring announcements and standardization trends on the European side.
References
- REGULATION (EU) 2024/2847 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847 - REGULATION (EU) No 168/2013 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 15 January 2013 on the approval and market surveillance of two- or three-wheel vehicles and quadricycles
https://eur-lex.europa.eu/eli/reg/2013/168/oj/eng - REGULATION (EU) 2019/1020 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 20 June 2019
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32019R1020 - DIRECTIVE (EU) 2020/1828 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2020 on representative actions for the protection of the collective interests of consumers and repealing Directive 2009/22/EC
https://eur-lex.europa.eu/eli/dir/2020/1828/oj/eng - Where the CRA stands today
https://www.cyberresilienceact.eu/state-of-play.html - About the Nippon CSIRT Association
https://www.nca.gr.jp/outline/about.html - Single Reporting Platform (SRP)
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp - CRA SRP guidance - AR User registration
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registration - Frequently Asked Questions
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
About the author
Kohei Kurihara, Privacy Expert
While in university, he worked in a politician's office, and after graduating joined Rakuten. After two years in sales, he started his own company, helping overseas digital services expand into Japan and Japanese services expand abroad. Since 2017, he has served as the Japan representative of the Government Blockchain Association, a US nonprofit.
Later, while involved in founding startups, he spoke on blockchain at international conferences, including those hosted by UNESCO. In 2020, he founded the Privacy by Design Lab, a general incorporated association, where he works on building international forums centered on privacy advocacy. His areas of expertise are data protection (personal information protection), digital marketing, and blockchain. He runs "Privacy Talk," an interview media outlet featuring direct conversations with privacy leaders in Japan and around the world.