The Cyber Resilience Act defines three reporting stages: early warning, detailed report and final report. Deadlines and triggers for vulnerabilities and security incidents compared.
The CRA reporting deadlines link to two reportable event types distinguished in Article 14: actively exploited vulnerabilities (paragraphs 1 and 2) and serious security incidents affecting the product’s security (paragraphs 3 and 4). Both paths start the same way, with an early warning within 24 hours and a detailed report within 72 hours. However, the deadlines for the final report differ significantly in both duration and trigger.
This distinction is not a formal detail. It determines which internal processes must kick in, which information must be available within which time window, and when the clock for the final report actually starts running.
cra-reporting-1024×476.webp
Stage 1 early warning within 24 hours
As soon as a manufacturer becomes aware of an actively exploited vulnerability or a serious security incident, it must submit an early warning within 24 hours. This goes simultaneously to the competent CSIRT and to ENISA, in future via the single reporting platform that ENISA is setting up under Article 16.
Which details the early warning must contain depends on the event type. It is intentionally brief:
- For an actively exploited vulnerability, the Member States in whose territory the affected product is provided, to the manufacturer’s knowledge, must be indicated (Article 14(2)(a)).
- For a serious security incident, it must at least be indicated whether there is suspicion that the incident is due to unlawful or malicious actions. Where relevant, the affected Member States should also be named (Article 14(4)(a)).
A full analysis is neither required nor realistic at this point. The purpose of the early warning is to enable the competent authorities to classify the situation early and, if necessary, coordinate a response.
In practice this means: within one working day it must be clear that a reportable event exists, the notification must be drafted and submitted via the platform. That requires pre-defined responsibilities, decision paths and access credentials for the reporting platform.
Stage 2 detailed report within 72 hours
Within 72 hours of becoming aware of the event an expanded report must follow. Which information it must contain again depends on the event type:
- For an actively exploited vulnerability, the manufacturer must provide, where available, general information about the affected product, the general nature of the exploitation and the vulnerability, and any corrective or risk mitigation measures taken, as well as measures users can take themselves (Article 14(2)(b)).
- For a serious security incident, the manufacturer must provide general information on the nature of the incident, an initial assessment, and corrective or risk mitigation measures taken and measures for users (Article 14(4)(b)).
In both cases the manufacturer can indicate how sensitive it considers the reported information to be. Severity and information on malicious actors do not yet belong in the 72-hour report but only in the final report.
The 72-hour report builds on the early warning and supplements it with insights from the first three days. It is therefore not a completely new report but an update of information already available.
For manufacturers without a functioning Product Security Incident Response Team (PSIRT) or a structured incident-response process, this deadline is an operational challenge. Typically, technical analysis, internal coordination between development, product management and legal, and informing affected users all run in parallel with the reporting. Those who want to set up the necessary process in a structured way will find an established framework for secure product development including vulnerability handling in IEC 62443-4-1.
Stage 3 final report where the paths diverge
The decisive difference between the two reporting paths becomes apparent at the third stage. The split lies in the trigger for the start of the deadline: in one path it is the availability of a fix, in the other it is the previous report.
Actively exploited vulnerabilities 14 days after the availability of the corrective or risk mitigation measure
For actively exploited vulnerabilities the final report must be submitted no later than 14 days after the availability of a corrective or risk mitigation measure (Article 14(2)(c)). Thus the start of the deadline is not linked to the time of becoming aware but to the moment a security update or a workaround is available. The report includes a description of the vulnerability including severity and impact, any available information about malicious actors, and details of the provided security updates or corrective measures.
This has an important consequence: as long as no corrective or risk mitigation measure is available, the 14-day clock does not start. At the same time the obligation remains to update the report when new information becomes available. The CSIRT named as coordinator may, if necessary, request an interim report with status updates (Article 14(6)). That applies to both reporting paths.
Serious security incidents one month after the 72-hour report
For serious security incidents a different logic applies. The final report must be submitted no later than one month after the detailed 72-hour report (Article 14(4)(c)). The start of the deadline is tied to the second reporting stage, not to the availability of a fix.
When an incident qualifies as serious is defined in Article 14(5). It is serious if it negatively affects or can affect the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. It is also serious if it led or can lead to the introduction or execution of malicious code in the product itself or in a user’s network and information system.
This deadline structure is demanding. The final report must be submitted after one month, regardless of whether the technical analysis is complete or a full root-cause analysis is available.
The deadlines at a glance
Both reporting paths go through the same three stages. Only the deadline for the final report differs, both in duration and in its trigger.
| Reporting stage | Actively exploited vulnerability | Serious security incident |
|---|---|---|
| Early warning | 24 hours after becoming aware | 24 hours after becoming aware |
| Detailed report | 72 hours after becoming aware | 72 hours after becoming aware |
| Final report | 14 days after availability of the corrective measure | 1 month after the 72-hour report |
A placement of these dates in the wider context is provided in our overview on the transition periods of the Cyber Resilience Act.
How reporting via the SRP platform works
The deadlines run against a concrete tool: the single reporting platform (SRP) that ENISA is building under Article 16. Early warnings, the detailed report and the final report are all submitted through it.
The following information reflects the status as of June 2026. The platform is in test operation, the fields are not final and may change before the reporting obligations start on 11 September 2026.
Prior registration requirement to meet the 24-hour deadline
Registration is via a web portal. In June 2026 the test operation runs under portal.test-cra-srp.enisa.europa.eu; the address crasrp.eu has been registered for live operation. The portal language is English.
Login is via a personal EU Login. The person who registers is then associated with the manufacturer for whom they act in the portal. As of June 2026 up to two people per company can be registered and the assignment is provisional. Note: the portal uses its own label for this role which is not to be equated with the legal concept of an authorised representative under the Cyber Resilience Act. It simply means the person entered in the portal who acts for the manufacturer.
During registration the manufacturer selects the national endpoint, i.e. the CSIRT responsible for them (for a German company, for example, CSIRT Germany). The manufacturer itself must clarify which CSIRT is responsible. The portal does not perform this check.
The person-to-manufacturer assignment is validated by the national CSIRT. How it does so, e.g. by phone or e-mail, is for the CSIRT to decide. Which procedure the BSI will choose was still open in June 2026. A report can be submitted even if access validation has not yet been completed. An account can be assigned to CSIRTs of multiple EU countries, which benefits manufacturers with establishments in several Member States. For that the manufacturer switches the national endpoint per country.
Registration and validation require lead time. Those who only start registering in the emergency will lose time the 24-hour deadline does not allow.
The reporting workflow in the portal stage by stage
The early warning is submitted via a form. Depending on whether the manufacturer selects a vulnerability or an incident, the portal displays different fields. Mandatory information includes, among others, title, summary, manufacturer and the Member States where the product is available. Optional fields include a CVSS score, the affected product and its version. The selection of distribution countries controls which additional national CSIRTs are notified.
A vulnerability report can cover multiple products and versions at once. If the same vulnerability affects several products, a separate report per product is not required.
Reports can be saved as drafts. After submission the dashboard shows the report along with its status. At the same time the national CSIRT receives the report for review and may release it for forwarding to other CSIRTs.
In the follow-up report after 72 hours the manufacturer can optionally state why the report should not be forwarded to additional national CSIRTs. The CSIRT reviews these reasons and may withhold the report if necessary, supported by a delegated act (EU) 2026/881 of the Commission. The fields of the follow-up report are not final. For example, corrective measures are optional because they may not be available after 72 hours.
The portal serves only the legal reporting obligation under Article 14. Voluntary reports from third parties or a file repository are, at least at introduction, not provided for.
What the dashboard does for the deadlines
The dashboard visibly tracks the deadlines. Forty-eight hours after the early warning it indicates that the follow-up report is still outstanding and is due at the latest after 72 hours. What consequences a missed follow-up report will have was not known in June 2026.
Submitted reports can be further edited within their current status. The system logs changes and additions. Once the final report is submitted the case is closed and no further changes are possible.
What this means for preparation
The CRA reporting deadlines are not extendable. Those who want to meet them need pre-defined processes, not ad hoc actions in an emergency. Three points are decisive:
- the ability to make a qualified initial assessment and submit the early warning within 24 hours,
- the organizational assignment of reporting responsibility, i.e. who decides internally on the reporting obligation and who technically submits the report,
- a clear distinction between the two event types.
Preparation also includes prior registration on the SRP, because without an established account the first deadline is hard to meet in an emergency.
Companies that already have a PSIRT or a structured incident-response process will find it easier to integrate the requirements into existing workflows. Those who still need to build these structures should use the remaining time until September 2026. This applies not only to new products: existing products are subject to the reporting obligations once an actively exploited vulnerability or a serious incident becomes known.
The reporting process does not have to be written by you
The template set defines responsibilities, escalation paths and deadline monitoring. You fill in names, roles and contact details and have a documented CRA reporting process that you can apply in practice from 11 September 2026.
Download templates for free
Distinction from NIS 2 reporting obligations
The CRA deadlines are not identical to the reporting obligations under the NIS 2 directive, even if the deadline structure bears similarities. The decisive difference is the reference point: NIS 2 targets operators of essential and important entities and concerns the security of network and information systems at the organisational level. The CRA, by contrast, is product-centred and obliges the manufacturer.
Companies that fall under both frameworks must fulfil both reporting obligations independently. The same incident can therefore trigger two separate reporting chains with their own deadlines and recipients.
Fines for missing deadlines
Violations of the reporting obligations can be sanctioned with fines under the CRA. The CRA provides for fines of up to 15 million euros or 2.5 percent of the total worldwide annual turnover of the preceding financial year (for companies), whichever is higher.
There is a narrowly defined relief for micro and small enterprises. If they alone miss the 24-hour deadline for the early warning, they will not be fined for that alone. The reporting obligation itself remains, and all other deadlines apply unchanged. The relief therefore concerns only the sanction for missing the first deadline. We place the background in the article Clarification on the CRA.
Conclusion
The CRA reporting deadlines follow a clear three-stage logic: early warning, detailed report, final report. The real complexity lies in distinguishing between vulnerabilities and security incidents, because the two paths have different deadlines and different triggers for the final report. Failing to reflect this distinction cleanly in internal processes risks missed deadlines — not out of negligence but because incorrect assumptions about timing are made in an emergency.
The deadlines are fixed; the preparation effort depends on product landscape and existing processes. If you want to understand how the reporting deadlines concretely affect your products, responsibilities and workflows, this can be well clarified in a non-binding conversation.
