September 11, 2026: CRA Reporting Requirements Take Effect — How Software Companies Should Prepare for the 24-Hour Early Warning System
Author of this article
Privacy Expert
Kohei Kurihara
[Disclaimer] This article is based on the author’s personal views, and the author is not a licensed attorney. Please note that this article is not intended to provide legal advice.
Introduction
On October 23, 2024, the European Cyber Resilience Act (hereinafter referred to as the EU CRA) was enacted. This law is designed to ensure that products connected to digital elements (communications) within the European Union meet the required cybersecurity standards.
For companies that market their products in Europe, changes to cybersecurity regulations mean they need to review their future schedule and identify the necessary actions to take. In particular, since reporting obligations take effect on September 11, it is important to first identify the items that require immediate action.
Background of the Cyber Resilience Act and Future Timeline
The background to the enactment of this law is that, while systems applying to specific products within the European Union had been established, there was no system in place to ensure cross-border enforcement. Consequently, the EU Consumer Rights Act (CRA) was enacted as an amendment to the Category L Framework Regulation, which was adopted on January 15, 2013; the European Market Surveillance Regulation, adopted on June 20, 2019; and the Directive on Collective Redress for Consumers, adopted on November 25, 2020.
One key point companies should keep in mind regarding the EU CRA is that this legislation appears to be linked in several ways to data protection and consumer protection. According to the Official Journal of the European Union published on November 20, 2024, the legislation states that implementing cybersecurity measures will protect the personal data of consumers and organizations, and it also addresses the protection of individual privacy.
At first glance, some parts of the law may appear to be aimed at strengthening cybersecurity; however, it also explicitly states that market regulators will work in conjunction with data protection regulators to carry out oversight, and requires that cybersecurity measures be considered from the perspective of consumers who use the products.
Preparations, including standardization, are underway in anticipation of the law taking effect on December 11, 2027. Regarding the future schedule, the author has created a chronological timeline based on information published on the website maintained by i46 s.r.o.
*Please note that this timeline is a projected schedule as of now and may not necessarily proceed exactly as outlined.
Date | Milestones | Details and Actions to Be Taken |
|---|---|---|
September 11, 2026 | Application of Reporting Requirements | ・Manufacturers’ Reporting Obligations: In the event of confirmed exploitation of a vulnerability or a serious incident, manufacturers are required to report such incidents to the European Union Agency for Cybersecurity (hereinafter “ENISA”) and the CSIRTs of each country. |
October 31, 2026 | Development and Maintenance of Initial Core Standards | ・We expect the development of the two core standards (security development and vulnerability response) to be completed. *This schedule was postponed by two months from the original deadline of August 30, 2026, following a draft amendment in July 2026. |
December 31, 2026 | Development and Maintenance of Standards for Each Product | ・We will conduct standard development and maintenance for each product. *The original deadline was October 30, 2026, but it was pushed back by two months to December 31, 2026, following a draft amendment by the European Commission in July 2026. |
October 30, 2027 | Development and Maintenance of Cross-Cutting Standards | ・We will develop and establish cross-functional standards and make preparations so that manufacturers can comply with the standard items we have been working on for the past year. |
December 11, 2027 | Full Implementation and Complete Application of the Law | ・Compliance with All Requirements: Compliance with all requirements mandated by law is required. |
Based on the anticipated timeline, it is expected that general standard development will proceed by the end of the year, and that cross-cutting standard development—not limited to product standards—will also progress before the regulations take effect. It seems reasonable to set the “application of reporting requirements,” which begins on September 11, as the initial goal and to proceed with countermeasures in stages.
Requirements for Compliance with Reporting Obligations
Article 14 of the EU CRA stipulates that manufacturers are required to report the status of vulnerabilities to ENISA, with the CSIRT acting as the coordinator. In accordance with the purpose of fulfilling this reporting obligation, Article 14 requires manufacturers to submit reports containing the following information through the SRP provided by ENISA.
*CSIRT stands for Computer Security Incident Response Team. According to the Japan CSIRT Association (a general incorporated association), it is “a general term for organizations tasked with responding to computer security incidents. These teams continuously collect and analyze incident-related information, vulnerability information, and early warning signs of attacks, and engage in activities such as formulating response policies and procedures.”
Stages | Deadline | Purpose of the Report | Key Report Contents |
Phase 1: Initial Report | Within 24 hours | Early Situation Sharing | ・Notification of the Incident |
Phase 2: Interim Report | Within 72 hours | Update on the Current Situation | ・Details on the vulnerability: |
Phase 3: Final Report | Within 14 days of the corrective or mitigating measures becoming available | Report on Post-Incident Review and Permanent Countermeasures | ・Implementation of mitigation measures (application of security updates, etc.) |
*The table was compiled by the author based on information published in the Official Journal of the European Union.
It also establishes reporting requirements for security incidents that pose a threat to products. Article 14 requires that the following information be reported through the SRP provided by ENISA, in accordance with the purpose of fulfilling the reporting obligations.
Stages | Deadline | Purpose of the Report | Key Report Contents | |
Phase 1: Initial Report | Within 24 hours | Early Situation Sharing | ・Notifications of Threats and Incidents | ・Scope of Impact Within Europe (Products Affected and Extent of Damage) |
Phase 2: Interim Report | Within 72 hours | Sharing Situation Assessments and Response Strategies | ・Incident Details and Assessment Information | ・Temporary Damage Mitigation |
Phase 3: Final Report | Within one month of submitting the 72-hour report | Report on Post-Event Review and Implementation of Mitigation Measures | ・Completion of damage mitigation measures ・Determination of incident details and scope of impact | ・Specific details of the threat that caused the incident |
*The table was compiled by the author based on information published in the Official Journal of the European Union.
The CSIRT (coordinator) to which vulnerabilities and incidents must be reported is the CSIRT of the Member State in which the manufacturer’s European location (principal place of business)—where cybersecurity-related decision-making is primarily carried out—is situated. Note that establishing a European location is not itself a requirement for reporting purposes. If a manufacturer does not have a principal place of business within the European Union, the competent Member State (CSIRT) is determined according to the following order of priority.
Priority | Criteria for Decision-Making | Applicable Member States (Competent CSIRTs) |
Top Priority | Authorized Representative | The Member State in which the authorized representative acting on behalf of the manufacturer has its place of business (based on the representative handling the largest volume of the products in question) |
Second Priority | Importer | The member state in which the importer that distributes the largest volume of a manufacturer's products to the market has its place of business |
Third Priority | Retailer | The Member State in which the distributor that supplies the largest volume of a manufacturer's products to the market has its place of business |
4th Priority | End User | The member state with the largest number of users of the manufacturer's products |
*The table was compiled by the author based on information published in the Official Journal of the European Union.
The manufacturer in question must properly notify consumers of product vulnerabilities and security incidents that pose a threat. In addition to specifying whether the issue is a vulnerability or an incident, the notification must also include information on risk mitigation measures and corrective actions. Furthermore, notifications must be provided in a structured, machine-readable format so that consumers can address vulnerabilities and incidents on their own.
If a manufacturer is unable to notify consumers directly, it shall designate a CSIRT as the coordinator to ensure that consumers are properly notified.
Compliance with the Single Reporting Platform provided by ENISA
To facilitate the reporting obligations described above through the system, Article 16 of the Cyber Resilience Act stipulates that ENISA shall establish an SRP. ENISA will be responsible for the design and management of the SRP, which is intended to be designed to enable reporting via electronic notification.
*Based on materials published by ENISA, the author has created an overview of the “Single Reporting Platform (SRP).”
After SRP issues a notification, the relevant European market’s CSIRT will receive the notification, and ENISA will also receive a similar notification. In addition, the report is forwarded through the CSIRT to the market supervisory authority in the relevant country, which will then determine whether or not to take enforcement action.
As outlined in the schedule mentioned earlier, the reporting requirements using the SRP will take effect on September 11, 2026; therefore, it is necessary to assess your compliance status in advance, including whether reporting is required.
Registration Procedures for the Single Reporting Platform (SRP)
From here on, we will walk you through the SRP registration process step by step, which will become available starting September 11.
1. Select a representative and register them with EU Login
To use the SRP, you must appoint a representative known as an “Assigned Representative” (hereinafter “AR”) to submit reports. The AR must first log in to the EU system using their email address and password and enter their registration information.
*The EU Login page where the author registered
By registering an AR in advance and verifying its contents, manufacturers or open-source stewards will be able to submit reports through the AR. While ARs are verified by the CSIRT (though this is not a mandatory requirement for submitting a report), verification processes vary by the CSIRT of the relevant country; therefore, in cases where special notification is required, manufacturers or open-source stewards are expected to perform the verification themselves.
2. Register with SRP
To register with SRP, you must fill out the required information by following the form registration instructions.
Step | Work to Be Performed | Details and Input Information |
Preparation | EU Login Authentication | Authenticate with the system using your EU Login account |
Step 1 | Confirmation of Terms and Conditions | I have read and agree to the legal terms and conditions (Terms of Service, Privacy Policy, etc.) |
Step 2 | Verify Account Information | Verify that the basic information provided during pre-registration (last name, first name, email address, and official company name) is correct. |
Step 3 | Entering Manufacturer Information | Provide detailed company information (legal name, business address, and any other necessary additional information) |
Step 4 | Role Configuration (AR Registration) | During the registration process, select and register "AR" (Assigned Representative) as your user role, then click "Continue." |
Step 5 | Selecting the Appropriate CSIRT | Select the appropriate CSIRT from the drop-down menu, then click "Continue" to finish. |
*Since the SRP website had not been launched at the time this article was written, the author has based this information on the registration guidance published by ENISA (released on July 31, 2026; updated on August 3). As ENISA itself states that “the content is subject to change,” please be sure to check the latest guidance when actually registering.
Once registration is complete and approved, the AR will be linked to the manufacturer. In addition to the account becoming active, the AR will be assigned a primary role. Along with the confirmation email, if the manufacturer’s information has been provided, it will also be registered in the SRP.
*After the primary AR has been registered, an invitation email may be sent to the secondary AR (the secondary AR, if the primary AR is designated as the main account) to complete its registration. In this case, the secondary AR must open the email sent by the primary AR and complete the registration process. Since the invitation is sent from the primary AR, the secondary AR must accept the invitation to complete registration. Once registered, the secondary AR will serve as a backup user for the primary AR.
Reporting Procedures on the Single Reporting Platform (SRP)
ARs must submit reports via the SRP. There are two types of reports: vulnerability reports (Actively Exploited Vulnerability; hereinafter “AEV”) and severe incidents (Severe Incident; hereinafter “SI”). The purpose of these reports is to request a review by the relevant CSIRT and to discuss future response measures. Reports must be submitted in accordance with the following procedures for the initial report, the 72-hour report, and the final report, respectively.
Reporting Phase | Preliminary Checks and Procedures | Contents | Determining and Submitting the Content of the Notice | Follow-up Procedures and Notes |
| Select “New Report Notification” from SRP (to load pre-registered AR information) | • Information required for the initial report notification | Select either “Submit Report” or “Save Details” | After submission, the CSIRT will conduct a verification. Once complete, "Verification Complete" and the "Date and Time of Action" will be displayed. |
72-Hour Report | After logging in to SRP, open the dashboard, review the initial report details, and select the appropriate "Initial Report." | Required Fields in the 72-Hour Report Tab | Select either “Submit Report” or “Save Details” | |
Final Report | After logging in to SRP, open the dashboard, review the 72-hour report, and select the applicable “Final Report.” | Required fields in the Final Report tab | Select either “Submit Report” or “Save Details” |
*The table was created by the author based on information published on the ENISA website.
In addition to the procedures for the report notification phase, you may revise the contents of the report notification if the deadline for revisions has not yet been reached or if the final report has not been submitted.
Please review the report template and get everything ready before the SRP is released on September 11.
As explained above, using the SRP makes it easier to submit reports and notifications; therefore, it is important to review the reporting and notification procedures in advance and make the necessary preparations before the system goes live on September 11.
The following is a template of the information that should be included in a report notification, as published by ENISA in its FAQs.
Common Items | Initial Report (Within 24 Hours) | 72-Hour Report | Final Report | |
1 | Notification Type (Vulnerability/Incident) | X | C | C |
2 | Notification Type (Initial Report/72-Hour Report/Final Report) | X | X | X |
3 | Reporting Time - Initial Report | A | A | A |
4 | Reporting Time - 72-Hour Reporting | A | A | A |
5 | Reporting Time - Final Report | A | A | A |
6 | Reporter | A | A | A |
7 | Name of the manufacturer or open-source software steward | X | C | C |
8 | Products | X | C | C |
9 | Product Type (Default/Important/Critical) | O | C | C |
10 | Product Classification (See CRA Annex III/IV to determine whether the product type is the default) | O | C | C |
11 | European regions where the products are available | I | C | C |
12 | Title | X | C | C |
Vulnerability Items | ||||
v13 | CVE ID (Common Vulnerability and Exposure) | O | C | C |
v14 | European Vulnerability Database | O | C | C |
v15 | General Information | O | X | C |
v16 | a. An explanation of the nature, characteristics, and mechanism of the vulnerability (security flaw) | O | X | C |
v17 | b. Basic information that broadly explains “how an attack method (exploit) works, what it targets, and what impact it has” | O | X | C |
v18 | Methods for Fixing and Mitigating Addressed Vulnerabilities | O | X | C |
v19 | Methods for Users to Fix and Mitigate Vulnerabilities | O | X | C |
v20 | Potentially Sensitive Information | O | I | C |
v21 | The date on which fixes and mitigation measures for resolved vulnerabilities will be implemented | 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 Contributing to the Exploitation of Vulnerabilities | O | O | I |
v26 | Details on Security Updates and How to Fix Them | O | O | X |
Incident Items Involving Threats | ||||
i13 | Illegality and Malicious Intent of the Incident | X | C | C |
i14 | General Information About Incidents | O | X | C |
i15 | Date and time the incident was detected | O | X | C |
i16 | Date and time of the incident | O | X | C |
i17 | Details of the Initial Incident Assessment | O | X | C |
i18 | Methods for Resolving and Reducing Resolved Incidents | O | X | C |
i19 | Ways for Users to Resolve and Reduce Incidents | O | X | C |
i20 | Potentially Sensitive Information | O | I | C |
Incident Details | O | O | X | |
i21 | a. Severity of the incident | O | O | X |
i22 | 1) Where it adversely affects or is likely to adversely affect the ability to protect the confidentiality, availability, authenticity, integrity, or confidentiality of confidential or critical data or functions in a product containing digital elements; | |||
i23 | b. Impact of the Incident | O | O | X |
i24 | Types and Routes of Threats That Caused the Incident | O | O | X |
i25 | Measures Already Implemented to Reduce Incidents and the Methods Currently Being Used | O | O | X |
*The table was created by the author based on information published in ENISA’s FAQ.
A - Filled in automatically (not visible to the submitter)
X - Required field
C - By default, copies of reports regarding previous procedures or update information are overwritten.
O - Selection Options
I - Required fields if the information has been obtained
In this article, we’ve provided a step-by-step guide to the key points companies should prepare for ahead of September 11. We suspect that many of you are struggling with questions such as who should be responsible for on-site AR and what criteria to use for your preparations once the SRP is released.
Since even submitting a report through the SRP requires numerous prior reviews, it is important to first review all products currently on the market in Europe and closely monitor and verify any incidents involving vulnerabilities or threats.
In such cases, I believe the best approach is to prepare the information required for incident response reports using a predefined template, and to keep updating the document with company-specific details as needed to ensure it remains a comprehensive record.
Furthermore, since there is still ample time before the full implementation on December 11, 2027, we need to continue monitoring announcements and standardization trends from the European side.
Reference Materials
REGULATION (EU) 2024/2847 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of October 23, 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%3A32024R2847REGULATION (EU) No. 168/2013 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of January 15, 2013 on the approval and market surveillance of two- or three-wheeled vehicles and quadricycles
https://eur-lex.europa.eu/eli/reg/2013/168/oj/engREGULATION (EU) 2019/1020 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of June 20, 2019
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32019R1020DIRECTIVE (EU) 2020/1828 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of November 25, 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/engThe Current Status of the CRA
https://www.cyberresilienceact.eu/state-of-play.htmlAbout the Japan C-SART Council
https://www.nca.gr.jp/outline/about.htmlSingle Reporting Platform (SRP)
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srpCRA SRP Guidance - AR User Registration
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registrationFrequently Asked Questions https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
Frequently Asked Questions
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
Author of this article
Privacy Expert
Kohei Kurihara
While in college, he worked at a politician’s office and joined Rakuten after graduation. After two years in sales, he started his own business. He supports the expansion of foreign digital services into Japan and the global expansion of Japanese services. Since 2017, he has served as the Japan representative for the U.S.-based nonprofit Government Blockchain Association.
Since then, while involved in founding startups, he has spoken at international conferences—including those organized by UNESCO—on blockchain-related topics. In 2020, he established the general incorporated association Privacy by Design Lab, where he focuses on advocacy for privacy and works to create international platforms for dialogue. His areas of expertise include data protection (personal information protection), digital marketing, and blockchain. He runs “Privacy Talk,” an interview-based media platform that features direct conversations with leaders in the privacy industry both in Japan and abroad.
Share this article
List of Helpful Articles
