CRA Reporting Deadlines for Vulnerabilities and Severe Incidents

Since September 11, 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through the central EU reporting platform. Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA, sets out a three-stage reporting procedure with fixed deadlines. On paper, this looks manageable. In practice, it is a stress test, because the CRA provides for two different reporting paths, each with its own deadlines.

Our overview of the CRA reporting obligations explains how the obligations are structured as a whole. This article focuses on the deadlines themselves: their stages, their triggers, and what they mean for your operations. They sit within the wider set of requirements of the Cyber Resilience Act.

Contents

1. Two reporting paths, one common start
2. Stage 1: early warning notification within 24 hours
3. Stage 2: detailed notification within 72 hours
4. Stage 3: final report, where the paths split
   1. Actively exploited vulnerabilities: 14 days after a corrective or mitigating measure is available
   2. Severe incidents: one month after the 72-hour notification
5. The deadlines at a glance
6. How reporting works on the single reporting platform
   1. Registration: what you can do in advance
   2. Reporting in the portal, stage by stage
   3. How the dashboard tracks the deadlines
7. What this means for your preparation
8. How CRA reporting differs from NIS2 reporting
9. Fines for missed deadlines
10. Why the distinction between the paths matters

Two reporting paths, one common start

The CRA reporting deadlines attach to two types of reportable event that Article 14 distinguishes:

• actively exploited vulnerabilities (Article 14(1) and (2))
• severe incidents having an impact on the security of the product (Article 14(3) and (4))

Both paths start the same way, with an early warning notification within 24 hours and a detailed notification within 72 hours. The deadlines for the final report, however, differ considerably, both in length and in what triggers them.

This distinction is not a formality. It determines which internal processes must kick in, which information must be available in which time window, and when the deadline for the final report starts to run at all.

Stage 1: early warning notification within 24 hours

As soon as a manufacturer becomes aware of an actively exploited vulnerability or a severe incident, it must submit an early warning notification within 24 hours. The notification goes simultaneously to the competent CSIRT and to ENISA, the EU Agency for Cybersecurity. It is submitted via the single reporting platform that ENISA operates under Article 16.

The content of the early warning depends on the type of event. It is deliberately brief:

• For an actively exploited vulnerability, you must indicate the Member States in whose territory the affected product has been made available, as far as you are aware (Article 14(2)(a)).
• For a severe incident, you must at least indicate whether the incident is suspected of being caused by unlawful or malicious acts. Where applicable, you must also name the affected Member States (Article 14(4)(a)).

A full analysis is neither required nor realistic at this point. The purpose of the early warning is to put the competent bodies in a position to assess the situation early and to coordinate a response if needed.

In practice, this means that within 24 hours you must establish that a reportable event has occurred, write the notification, and submit it via the platform. That only works if responsibilities, decision paths, and access to the reporting platform have been settled in advance.

Stage 2: detailed notification within 72 hours

Within 72 hours of becoming aware, a more detailed notification follows. Its content again depends on the type of event:

• For an actively exploited vulnerability, you must provide general information, as available, about the product concerned, the general nature of the exploit and of the vulnerability, and any corrective or mitigating measures taken. You must also describe the measures that users can take themselves (Article 14(2)(b)).
• For a severe incident, you must provide general information about the nature of the incident, an initial assessment, any corrective or mitigating measures taken, and the measures that users can take (Article 14(4)(b)).

In both cases, you can indicate how sensitive you consider the notified information to be. The severity and information about malicious actors do not belong in the 72-hour notification. They come later, in the final report.

The 72-hour notification builds on the early warning and adds what you have learned in the first three days. It is not an entirely new notification but an update of the information already available.

For manufacturers without a working product security incident response team (PSIRT) or a structured incident response process, this deadline becomes an operational challenge. The notification typically runs in parallel with the technical analysis, with internal coordination between development, product management, and the legal department, and with informing affected users. If you want to set up this process in a structured way, IEC 62443-4-1 provides an established framework for secure product development, including vulnerability handling.

Stage 3: final report, where the paths split

The third stage shows the decisive difference between the two reporting paths. The split lies in what starts the clock: for one path, it is the availability of a fix; for the other, it is the previous notification.

Actively exploited vulnerabilities: 14 days after a corrective or mitigating measure is available

For actively exploited vulnerabilities, you must submit the final report no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)). The deadline is therefore not tied to becoming aware. It is tied to the moment a security update or a workaround is available. The report covers:

• a description of the vulnerability, including its severity and impact
• available information about malicious actors
• details of the security updates or other corrective measures made available

This has an important consequence. As long as no corrective or mitigating measure is available, the 14-day deadline does not start. At the same time, you remain obliged to update the notification when new findings emerge. Where necessary, the CSIRT designated as coordinator can request an intermediate report with status updates (Article 14(6)). This applies to both reporting paths.

Severe incidents: one month after the 72-hour notification

A different logic applies to severe incidents. The final report must be submitted within one month after the detailed 72-hour notification (Article 14(4)(c)). Here the deadline is firmly linked to the second reporting stage, not to the availability of a fix.

Article 14(5) defines when an incident counts as severe. It is severe if it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. It is also severe if it has led, or is capable of leading, to the introduction or execution of malicious code in the product itself or in a user's network and information systems.

This deadline structure is demanding. You must submit the final report after one month, whether or not the technical analysis is complete and whether or not 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, in both length and trigger.

Reporting stage	Actively exploited vulnerability	Severe incident
Early warning notification	24 hours after becoming aware	24 hours after becoming aware
Detailed notification	72 hours after becoming aware	72 hours after becoming aware
Final report	14 days after the corrective measure is available	1 month after the 72-hour notification

For how these dates fit into the overall timeline, see our overview of the transition periods of the Cyber Resilience Act.

How reporting works on the single reporting platform

The deadlines run against a concrete tool: the single reporting platform (SRP) that ENISA operates under Article 16. The early warning notification, the detailed notification, and the final report are all submitted through it.

The platform has been in operation since September 11, 2026. The following information is based on the test operation in June 2026 and on ENISA's documents from October 2026. ENISA can still change details.

Registration: what you can do in advance

Only a person registered in the portal at portal.cra-srp.enisa.europa.eu as an Assigned Representative (AR) for the manufacturer can submit notifications. You sign in with a personal EU Login account with multi-factor authentication. ENISA advises registering only when a notification is due. You can set up the EU Login and decide who submits in an emergency beforehand. Because the CSIRT validates the account in parallel with the notification, registration does not hold up the 24-hour deadline. How registration works and which CSIRT to select is covered in our article on registering for the CRA single reporting platform.

Reporting in the portal, stage by stage

The early warning notification is a form. Depending on whether you select a vulnerability or an incident, the portal shows different fields. Mandatory fields include the title, a summary, the manufacturer, and the Member States in which the product is available. Optional fields include a CVSS score, the affected product, and the version. The selection of countries of distribution determines which other national CSIRTs are notified.

A vulnerability notification can cover several products and versions at once. If the same vulnerability affects several products, you do not need a separate notification for each product.

You can save notifications 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, where applicable, approves forwarding it to other CSIRTs.

In the follow-up notification after 72 hours, you can optionally state why the notification should not be forwarded to other national CSIRTs. The CSIRT reviews these reasons and withholds the notification if necessary, based on the Commission's Delegated Regulation (EU) 2026/881. The fields of the follow-up notification were not final during the test operation. For example, corrective measures are optional, because they do not have to be available after 72 hours.

The portal serves only the legal reporting obligation under Article 14. Voluntary reports by third parties and file storage are not planned, at least not at launch.

How the dashboard tracks the deadlines

The dashboard shows the deadlines, but it does not replace your own deadline tracking. The platform currently sets the due date of the 72-hour notification to 48 hours after the early warning notification was submitted. The legal deadline, however, runs 72 hours from when you became aware. A notification can therefore appear overdue although time remains. The ENISA FAQ on the SRP announces that a future release will calculate the due date from the time of awareness that you enter.

For the final report on a severe incident, the dashboard shows a due date one month after the 72-hour notification. For the final report on a vulnerability, there is no counter, because that deadline only starts once a corrective or mitigating measure is available. The counters trigger reminder emails and alerts about reports that may be overdue. You remain responsible for meeting the deadlines in Article 14.

You can continue to edit submitted notifications within their current status. The system logs changes and additions. Once you submit the final report, the case is closed and no further changes are possible.

What this means for your preparation

The CRA reporting deadlines cannot be extended. To meet them, you need processes defined in advance, not improvised when an event occurs. Three points matter most:

• the ability to make a qualified initial assessment and submit the early warning notification within 24 hours
• clear assignment of reporting responsibility: who decides internally whether a report is required, and who submits it technically
• a clean distinction between the two types of event

This preparation also includes setting up the EU Login of the people who will report and deciding in advance who submits on the SRP when an event occurs.

Companies that already have a PSIRT or a structured incident response process will find it easier to integrate the requirements into existing workflows. If you still have to build these structures, you should do so without further delay. This applies not only to new products: the reporting obligations also apply to products already on the market as soon as you become aware of an actively exploited vulnerability or a severe incident.

How CRA reporting differs from NIS2 reporting

The CRA reporting deadlines are not the same as the reporting obligations under the NIS2 Directive, even though the deadline structure has parallels. The main difference is the point of reference. NIS2 addresses essential and important entities and concerns the security of network and information systems at the organizational level. The CRA, by contrast, is product-centered and places the obligation on the manufacturer.

Companies that fall under both acts must meet both reporting obligations independently of each other. A single incident can therefore trigger two separate reporting chains, each with its own deadlines and its own recipients.

Fines for missed deadlines

Infringements of the reporting obligations can be sanctioned with fines under the CRA. The CRA provides for administrative fines of up to €15 million or, for undertakings, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher.

A narrowly defined relief applies to microenterprises and small enterprises. If they only miss the 24-hour deadline for the early warning notification, they are not fined for it. The reporting obligation itself remains, and all other deadlines apply in full. The relief therefore only concerns the penalty for missing the first deadline. Our page on CRA penalties explains the relief for microenterprises and small enterprises and its background.

Why the distinction between the paths matters

The CRA reporting deadlines follow a clear three-stage logic: early warning notification, detailed notification, final report. The real complexity lies in the distinction between vulnerabilities and incidents, because the two paths have different deadlines and different triggers for the final report. If your internal processes do not reflect this distinction cleanly, you risk missing deadlines. The cause is rarely negligence. More often, wrong assumptions about the time frame are made when an event occurs.

The deadlines are fixed. The effort to prepare depends on your product portfolio and your existing processes. If you want to understand how the reporting deadlines affect your products, responsibilities, and workflows, a no-obligation call is a good way to work this out.