The Cyber Resilience Act sets three reporting stages: early warning, detailed report and final report. Deadlines and triggers for vulnerabilities and security incidents are compared.
The CRA reporting deadlines apply to two reportable event types distinguished in Article 14: actively exploited vulnerabilities (paragraphs 1 and 2) and serious security incidents affecting a 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 in which time window, and when the clock for the final report actually starts running.
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 establishes under Article 16.
What the early warning must contain depends on the event type. It is deliberately concise:
- For an actively exploited vulnerability, the Member States in whose territory the affected product has been made available, to the manufacturer’s knowledge, must be indicated (Article 14 paragraph 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 applicable, the affected Member States must also be named (Article 14 paragraph 4(a)).
A full analysis is neither required nor realistic at this stage. The purpose of the early warning is to enable the competent authorities to assess the situation early and, if necessary, to coordinate a response.
In practice this means: within one working day it must be established that a reportable event exists, the notification must be drafted and submitted via the platform. That requires that responsibilities, decision paths and access credentials for the reporting platform are clarified in advance.
Stage 2 — detailed report within 72 hours
Within 72 hours of becoming aware of the event, an extended report must follow. What it must contain again depends on the event type:
- For an actively exploited vulnerability, manufacturers 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 that users can take (Article 14 paragraph 2(b)).
- For a serious security incident, manufacturers must provide general information about the nature of the incident, an initial assessment, and any corrective or risk mitigation measures and measures for users (Article 14 paragraph 4(b)).
In both cases the manufacturer may indicate how sensitive it considers the reported information to be. Severity and details about malicious actors do not yet belong in the 72-hour report but are reserved for the final report.
The 72-hour report builds on the early warning and supplements it with findings from the first three days. It is therefore not an entirely new notification but an update of information already provided.
For manufacturers without a functioning Product Security Incident Response Team (PSIRT) or a structured incident-response process, this deadline becomes an operational challenge. Typically the technical analysis, internal coordination between development, product management and legal, and the notification of affected users run in parallel with the report. Those who want to set up the required process in a structured way will find an established framework for secure product development and vulnerability handling in IEC 62443-4-1.
Stage 3 — final report where the paths diverge
The decisive difference between the two reporting paths appears at the third stage. The splitting point is the trigger for when the deadline starts: for one path the clock starts when a remediation or mitigation becomes available, for the other it starts from the previous report.
Actively exploited vulnerabilities — 14 days after a corrective or mitigation measure becomes available
For actively exploited vulnerabilities, the final report must be submitted no later than 14 days after a corrective or risk mitigation measure becomes available (Article 14 paragraph 2(c)). The start of the deadline is therefore not tied to the time of discovery but to the moment a security update or workaround is provided. The report includes a description of the vulnerability including severity and impact, available information about malicious actors, and details on the provided security updates or corrective measures.
This has an important consequence: as long as no corrective or mitigation measure is available, the 14-day clock does not start. At the same time, the obligation to update the notification with new findings remains. The CSIRT named as coordinator can, if necessary, request an interim status update (Article 14 paragraph 6). This 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 paragraph 4(c)). The start of the deadline is firmly tied to the second reporting stage here, not to the availability of a fix.
When an incident qualifies as serious is defined in Article 14 paragraph 5. It is serious if it negatively affects or could 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 has led to or could lead to the introduction or execution of malicious code in the product itself or in a user’s network and information system.
This deadline construct is demanding. The final report must be submitted a month after the 72-hour report, 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 a corrective measure becomes available | 1 month after the 72-hour report |
A contextual overview of these dates is available in 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. The early warning, the detailed report and the final report are submitted via this platform.
The following information reflects the status as of June 2026. The platform is in test mode, the fields are not final and may change before the reporting obligations begin on 11 September 2026.
Prior registration required to meet the 24-hour deadline
Registration is done through a web portal. In June 2026 the test portal was available at portal.test-cra-srp.enisa.europa.eu; the live address crasrp.eu has been registered for production. The portal language is English.
Login is via a personal EU Login. The registering person is then associated with the manufacturer on whose behalf they act in the portal. As of June 2026 up to two people per company can be linked and the association is provisional. Note: the portal uses its own label for this role, which is not identical to the legal notion of an authorised representative under the Cyber Resilience Act; it simply denotes the person entered in the portal who acts for the manufacturer.
At registration the manufacturer selects the national endpoint, i.e. the competent CSIRT (for a German company, for example, CSIRT Germany). The manufacturer must determine in advance which CSIRT is competent. The portal does not carry out that check.
The association of person and manufacturer is validated by the national CSIRT. How it performs this validation, for example by phone or email, is up to the CSIRT. 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 associated with CSIRTs of several EU countries, which benefits manufacturers with subsidiaries in several Member States; the manufacturer then switches the national endpoint per country.
Registration and validation require lead time. Those who start registering only during an incident will lose time that 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 fields include, among others, title, summary, manufacturer and the Member States where the product is available. Optional fields include a CVSS score, the affected product and the version. The selection of distribution countries determines 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 for each product is not required.
Reports can be saved as drafts. After submission the dashboard shows the report and its status. At the same time the national CSIRT receives the report for review and may authorize forwarding to other CSIRTs.
In the follow-up report after 72 hours the manufacturer can optionally indicate why the report should not be forwarded to additional national CSIRTs. The CSIRT reviews these reasons and may withhold the report if necessary, based on 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 is intended solely to fulfil the legal reporting obligation under Article 14. Voluntary third-party reports or a file repository are not planned at least for the initial rollout.
What the dashboard does for the deadlines
The dashboard visibly supports the deadlines. Forty-eight hours after the early warning it notes that the follow-up report is still outstanding, which is due no later than 72 hours. What consequences a missed follow-up report will have was not known as of June 2026.
Submitted reports can be further adjusted 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. To meet them you need predefined processes in place, not just actions taken during an incident. Three points are decisive:
- the ability to make a qualified initial assessment and submit the early warning within 24 hours,
- the organisational assignment of reporting responsibility, i.e. who internally decides about 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 access it will be difficult to meet the first deadline in an incident.
Companies that already have a PSIRT or a structured incident-response process will find it easier to integrate the requirements into existing workflows. Those that still need to build these structures should use the time remaining until September 2026. This applies not only to new products: CRA reporting obligations for existing products also apply once an actively exploited vulnerability or a serious incident becomes known.
Are you prepared for the deadlines?
In an incident there is no time to sort out responsibilities, access or approvals. We can help set up the CRA reporting process in advance so that early warning, follow-up report and final report work operationally.
Distinction from NIS‑2 reporting obligations
The CRA deadlines are not identical to the reporting obligations under the NIS-2 directive, even though there are parallels in the deadline structure. The decisive difference is the point of reference: NIS‑2 is aimed at 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 missed deadlines
Violations of the reporting obligations can be sanctioned with fines under the CRA. The CRA provides for fines of up to EUR 15 million or 2.5 percent of the total worldwide annual turnover of the preceding financial year (for companies), whichever amount is higher.
There is a narrowly defined relief for micro and small enterprises. If they miss only 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 affects only the sanction for a sole failure to meet the first deadline. We explain the background in 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 properly in internal processes risks missing deadlines — not out of negligence but because incorrect assumptions about the timing are made in the heat of an incident.
The deadlines are fixed; the preparation effort depends on your product portfolio and existing processes. If you want to understand how the reporting deadlines will concretely affect your products, responsibilities and workflows, that can be assessed in a non-binding conversation.
