The Cyber Resilience Act defines three reporting stages: early warning, detailed report and final report. This article compares the deadlines and triggers for vulnerabilities and security incidents.
Die CRA-Meldefristen knüpfen an zwei meldepflichtige Ereignistypen an, die Artikel 14 unterscheidet: aktiv ausgenutzte Schwachstellen (Absätze 1 und 2) und schwerwiegende Sicherheitsvorfälle, die sich auf die Sicherheit des Produkts auswirken (Absätze 3 und 4). Beide Pfade beginnen identisch, mit einer Frühwarnung innerhalb von 24 Stunden und einer detaillierten Meldung innerhalb von 72 Stunden. Die Fristen für den Abschlussbericht unterscheiden sich jedoch erheblich, sowohl in der Dauer als auch im Auslöser.
Diese Unterscheidung ist kein formales Detail. Sie bestimmt, welche internen Prozesse greifen müssen, welche Informationen in welchem Zeitfenster vorliegen müssen und ab wann die Frist für den Abschlussbericht überhaupt zu laufen beginnt.
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 will establish under Article 16.
What 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, to the manufacturer’s knowledge, made available 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. If applicable, 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 assess the situation early and to coordinate a response if necessary.
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 responsibilities, decision paths and access credentials for the reporting platform to be clarified in advance.
Stage 2 detailed report within 72 hours
Within 72 hours of becoming aware of the event an extended report must follow. The required information 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 actions that users can take themselves (Article 14(2)(b)).
- For a serious security incident, manufacturers must provide general information about 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 may indicate how sensitive it considers the reported information to be. Severity and data about 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 the findings from the first three days. It is therefore not a completely new notification 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 becomes an operational challenge. Typically, parallel to the reporting, technical analysis, internal coordination between development, product management and legal, and informing affected users take place. Those who want to set up the necessary process in a structured way can use IEC 62443-4-1 as an established framework for secure product development including vulnerability handling.
Stage 3 final report where the paths split
The decisive difference between the two reporting paths becomes apparent at the third stage. The divergence lies in the trigger that starts the deadline: in one path the clock starts when a fix or mitigation is available, in the other it starts from the earlier report.
Actively exploited vulnerabilities 14 days after availability of the fix or mitigation
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(2)(c)). The start of the deadline is therefore not tied to the time of discovery but to the moment when a security update or workaround is available. The report includes a description of the vulnerability including severity and impact, available information about malicious actors and details about 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 notification with new findings. The CSIRT named as coordinator can, if necessary, request an interim report with status updates (Article 14(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(4)(c)). The start of the deadline is firmly linked to the second reporting stage here, not to the availability of a fix.
Article 14(5) defines when an incident is considered serious. 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 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 structure is demanding. The final report must be submitted within a 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 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 |
An assessment of these dates in the bigger picture is available in the overview on transition periods of the Cyber Resilience Act.
How reporting works via the SRP platform
The deadlines apply to a concrete tool: the single reporting platform (SRP) that ENISA is establishing under Article 16. Early warnings, detailed reports and final reports are 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 begin on 11 September 2026.
Pre-registration requirement to meet the 24-hour deadline
Registration is done 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 registering 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 registered and the association 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 on behalf of the manufacturer.
During registration the manufacturer chooses the national endpoint, i.e. the CSIRT responsible for them (for a German company, for example, CSIRT Germany). Which CSIRT is responsible must be clarified by the manufacturer in advance. The portal does not check this.
The association of person and manufacturer is validated by the national CSIRT. How they do this, e.g. by phone or e-mail, is up to them. Which procedure the BSI will choose was still open in June 2026. A notification can be submitted even if access validation has not yet been completed. An account can be assigned to CSIRTs of several EU countries, which helps manufacturers with establishments in multiple Member States. For that the manufacturer switches the national endpoint per country.
Registration and validation take time. Those who only start registering in the emergency will lose time the 24-hour deadline does not allow.
The reporting process in the portal step by step
The early warning is submitted as a form. Depending on whether the manufacturer selects a vulnerability or an incident, the portal displays different fields. Mandatory information includes, among other things, 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 controls which additional national CSIRTs are notified.
A vulnerability notification can cover multiple products and versions at once. If the same vulnerability affects several products, individual notifications per product are therefore not required.
Notifications can be saved as drafts. After submission the dashboard shows the notification and its status. At the same time the national CSIRT receives the notification 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 notification should not be forwarded to other national CSIRTs. The CSIRT reviews these reasons and can withhold the notification if necessary, based on a delegated act (EU) 2026/881 of the Commission (https://eur-lex.europa.eu/eli/reg_del/2026/881/oj/eng). 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 third-party reports or a file repository are not planned, at least for the introduction phase.
What the dashboard does for the deadlines
The dashboard visibly tracks the deadlines. 48 hours after the early warning it reminds that the follow-up report is still outstanding and due no later than 72 hours. What consequences a missed follow-up report will have was not known in June 2026.
Submitted notifications 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 advance, not only in the event of an incident. Three points are crucial:
- 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 on the reporting obligation and who technically submits the notification,
- a clear distinction between the two event types.
Preparation also includes prior registration on the SRP, because without an established account the first deadline will be 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: reporting obligations also apply to existing products as soon as an actively exploited vulnerability or a serious incident becomes known.
The reporting process does not have to be written by you
Templates specify responsibilities, escalation paths and deadline monitoring. They include names, roles and contact channels and provide a documented CRA reporting process that you can apply from 11 September 2026 in an actual incident.
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 shows parallels. 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 is product-centred and obliges the manufacturer.
Companies covered by both frameworks must comply with 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 alone miss the 24-hour deadline for the early warning, they will not be fined for that. The reporting obligation itself remains, and all other deadlines apply without restriction. The relief therefore only concerns the sanction for missing the first deadline. We explain the background in the 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 both paths have different deadlines and different triggers for the final report. If that distinction is not clearly reflected in internal processes, there is a risk of missed deadlines — not from carelessness, but because wrong assumptions about the timing are made in an emergency.
The deadlines are fixed; the preparation effort depends on your product portfolio and existing processes. If you want to understand how the reporting deadlines concretely affect your products, responsibilities and workflows, this can be clarified in a non-binding conversation.
