Guide Last updated 8 October 2026 11 min read

Early warning, notification, final report: what goes into each of the three stages

Article 14 does not require a complete notification within 24 hours, but three stages with growing content. For each stage, this page shows what the Regulation requires, what the ENISA platform asks for and what the early warning may deliberately leave out.

A notification under Article 14 of Regulation (EU) 2024/2847 has three stages: an early warning notification within 24 hours, a notification within 72 hours and a final report. For an actively exploited vulnerability this is governed by Article 14(2), for a severe incident by Article 14(4). The first two deadlines run from the point "of the manufacturer becoming aware of it". The third deadline depends on the trigger: 14 days after a corrective or mitigating measure is available for a vulnerability, one month after the 72-hour notification for an incident. The early warning is meant to be fast, not complete. What it contains fits into a few lines.

Key points

Early warning within 24 hours, notification within 72 hours, final report: vulnerabilities under Article 14(2), incidents under Article 14(4).
The 24-hour and the 72-hour deadlines both run from awareness, in parallel, not one after the other.
The early warning needs seven mandatory items and the time of detection. The cause, the patch, the severity and the attacker do not belong in it.
The final report has two different deadlines: 14 days after a corrective or mitigating measure is available (vulnerability) or one month after the 72-hour notification (incident).
Submission is made on ENISA's single reporting platform, in English, by the manufacturer's Assigned Representative.

Three stages, two triggers: an overview

The Regulation has two triggers, the actively exploited vulnerability and the severe incident. The same three steps apply to both; the content and the last deadline differ.

Stage	Deadline	Content	Article
Early warning, vulnerability	24 hours from awareness	That a vulnerability is being actively exploited; where known, the Member States in which the product has been made available	Article 14(2)(a)
Notification, vulnerability	72 hours from awareness	General information about the product, the nature of the vulnerability and of the exploitation, corrective or mitigating measures taken, measures users can take; where applicable, how sensitive the manufacturer considers the information to be	Article 14(2)(b)
Final report, vulnerability	no later than 14 days after a corrective or mitigating measure is available	Description of the vulnerability with its severity and impact, information about the malicious actor where available, the remedial measure	Article 14(2)(c)
Early warning, incident	24 hours from awareness	That a severe incident has occurred; whether it is suspected of being caused by unlawful or malicious acts; where applicable, the Member States in which the product has been made available	Article 14(4)(a)
Notification, incident	72 hours from awareness	General information about the nature of the incident, an initial assessment, corrective or mitigating measures taken, measures users can take; where applicable, how sensitive the manufacturer considers the information to be	Article 14(4)(b)
Final report, incident	within one month after the 72-hour notification	Detailed description with severity and impact, type of threat or root cause, applied and ongoing mitigation measures	Article 14(4)(c)

In addition, under Article 14(6) the coordinating CSIRT can request an intermediate report, and under Article 14(8) the manufacturer informs the impacted users in parallel, without a fixed deadline in hours (see the guide Informing users under Article 14(8)).

The early warning: little content, but fast

The Commission guidance C(2026) 5252 describes the early warning in paragraph 215 as a stage "containing limited information", to be supplemented later. The ENISA form is built in exactly this way. According to the SRP glossary (version 1.4 of 1 October 2026), the Early Warning tab asks for:

Notification type: actively exploited vulnerability or severe incident.
Title and summary: two free-text fields in English, kept short.
Manufacturer name: as registered in the commercial register.
Affected Member States: where the product is in use, as far as known.
Product name and product version: unambiguous, so that the CSIRT knows what is being reported.
Date and time of detection.
Incidents only: whether the incident is suspected of being caused by unlawful or malicious acts (Article 14(4)(a)).

Optional fields at this stage include the product type and product class, an indication that support has ended and the name of an affected component. Also optional: the CVE and EUVD identifiers (the vulnerability's numbers in the public databases), whether a fix is expected soon, an immediate measure for users, and a short explanation of which information is sensitive and why (free text, at most 255 characters). Everything else can be added at the next stage.

What the early warning does not need

The early warning is not a report. It does not need: the cause of the vulnerability, a patch or a timetable for one, a severity rating, information about the attacker, a list of affected customers, proof of damage. Nor is sign-off by senior management legally required; if your company requires it internally, give it to the Assigned Representative in advance, so that the deadline is not missed for want of a signature.

The 72-hour notification: the first assessment

On the platform, the second stage is a tab of the same notification and requires the early warning to have been submitted. According to the SRP glossary, the mandatory fields are general information about the vulnerability or the incident and the date and time it occurred; for incidents, the initial assessment as well. This matches what Article 14(2)(b) and (4)(b) require: the nature of the vulnerability and of the exploitation, or of the incident, measures already taken and measures users can take; for incidents, an initial assessment in addition, and in both cases, where applicable, how sensitive the manufacturer considers the information to be. The Regulation only asks for a description of the severity in the final report. Optional additions are the attack vector, measures taken, mitigating measures for users and the explanation of how sensitive the information is.

In exceptional circumstances, the coordinating CSIRT can delay dissemination to other CSIRTs on cybersecurity-related grounds for as long as strictly necessary, in particular at the manufacturer's request. This applies to vulnerabilities and incidents; only the CSIRT may decide (Article 16(2), second subparagraph). There is one special feature that applies only to vulnerabilities: in "particularly exceptional circumstances", where one of the three situations listed in the provision applies, ENISA too initially receives only basic information (third subparagraph). The details of this (referred to as "PEC" in the ENISA glossary), with the reasons, belong in the 72-hour notification and nowhere else.

Important for planning: the 72 hours run from awareness, not from the early warning. According to the ENISA FAQ of 3 October 2026, the counter in the portal currently shows a due date 48 hours after the early warning was sent, and is only due to be switched to the moment of awareness in a later release. What counts is the moment you documented yourself; see the guide When does the 24-hour deadline start? Awareness under Article 14 CRA.

The final report: two different deadlines

The third stage concludes the notification. This is where vulnerabilities and incidents differ most:

Vulnerability (Article 14(2)(c)): no later than 14 days after a corrective or mitigating measure is available. So the deadline only starts with the fix. Mandatory on the platform: the date the fix became available, details of the security update, a full description of severity and impact, measures taken, mitigating measures for users, and information about the malicious actor where available.
Incident (Article 14(4)(c)): within one month after the 72-hour notification, whether or not the incident has been closed. Mandatory: ongoing mitigation measures, severity, impact, type of threat or root cause, and, as for vulnerabilities, measures taken and mitigating measures for users.

Once the final report has been submitted, the notification can no longer be edited on the platform. Submit it too early and you cannot correct anything. Until then, each stage can be supplemented with the update button, and the CSIRT can request an intermediate report under Article 14(6).

How vulnerabilities and incidents differ

The subject. The vulnerability sits in the product at the user's end. A severe incident typically affects the manufacturer itself, such as its build environment, update server or signing keys; recital 68 mentions malicious code introduced into the release channel for security updates. The test is set out in Article 14(5).
The early warning. For incidents, there is the additional question of whether unlawful or malicious acts are suspected; for vulnerabilities, the CVE and EUVD identifiers are optional.
The 72-hour notification. Only vulnerabilities have the information on particularly exceptional circumstances (PEC). Only incidents expressly require an initial assessment.
The final report. 14 days after the fix versus one month after the 72-hour notification. For vulnerabilities, the date of the fix and details of the update are mandatory; for incidents, the type of threat or root cause.

Sample wording for the free-text fields

Keep the free-text fields short. The examples come from a fictitious manufacturer of packaging machines; the product and the figures are invented. They show the scope, not the wording for your own case.

Early warning, title and summary:

Title: Active exploitation of authentication weakness in
packaging line controller, firmware 4.2

Summary: On 2026-10-10 two customers reported unauthorised
administrator logins on the remote service interface of
our packaging line controller (firmware 4.2.0 and 4.2.1).
Log evidence indicates active exploitation. Affected
products are deployed in DE, IT and PL. Investigation
ongoing; a workaround will be sent to affected customers.

72-hour notification, general information:

The remote service interface accepts a session token
without validating its expiry. An attacker with network
access can obtain administrator rights. Exploitation
confirmed on two customer systems; first occurrence
2026-10-09 approx. 22:00 UTC. Mitigation: customers were
advised to disable remote service access (sent 2026-10-10).
Fix in firmware 4.2.2 planned, release date to follow.

Final report, measures:

Firmware 4.2.2 released 2026-10-16, closes the token
validation issue. All registered customers notified by
e-mail on 2026-10-16; advisory published on our website.
Severity assessed as high (unauthorised administrative
access). No indication of exploitation after 2026-10-11.
Actor unknown.

Free templatesCRA Reporting KitAll mandatory fields and the most important optional fields of the three reporting stages for vulnerabilities and incidents, with sample wording in English ready to adapt. Plus a playbook, call chain and deadline calculator.Request the kit

Who submits and who prepares

Article 14 is addressed to the manufacturer. Submission on the single reporting platform is made by its Assigned Representative, a designated person with a personal EU Login account. How to get there is explained in the guide ENISA Single Reporting Platform step by step. Everything that comes before pressing submit can be prepared: receiving and assessing the report, alerting the people responsible, tracking the running deadlines and drafting the three stages in English. Of these, CRA Response Center takes on recognising, notifying and recording awareness and deadlines; the assessment, the draft and the submission stay with the manufacturer.

Common mistakes

Waiting for the full root cause analysis before sending the early warning.
Counting the 24 and 72 hours one after the other, or taking the portal counter for the legal deadline.
Treating both final reports the same: 14 days from the fix is not one month from the notification.
Submitting the final report while information is still missing; after that, nothing can be changed.
Informing users only with the final report, although Article 14(8) expects this "in a timely manner" and a workaround was possible long before.

Frequently asked questions

Do I have to state the cause in the early warning?

No. According to paragraph 215 of the Commission guidance, the early warning contains "limited information"; on the platform this means the product, version, Member States, a short summary and the time of detection. The cause, severity and fix follow in the later stages.

Do the 24 and 72 hours run one after the other?

No, both run from awareness. If you send the early warning after 20 hours, you have 52 hours left for the notification, not 72.

When is the final report due for a vulnerability?

No later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)). If there is no fix yet, this deadline has not started; the CSIRT can, however, request intermediate reports.

And for an incident?

Within one month after the 72-hour notification (Article 14(4)(c)), even if the follow-up work is still going on. Ongoing measures are described as such.

Can I correct a stage afterwards?

Yes, with the update button on the platform, until the final report has been submitted. Every update triggers notifications to the CSIRT and ENISA.

May I hold back details that would help attackers?

The platform has a free-text field in which the manufacturer briefly explains which information is sensitive and why (at most 255 characters), and under Article 16(2) the manufacturer can ask for dissemination to other CSIRTs to be delayed. The notification to the coordinating CSIRT is still due. Only for vulnerabilities, and only in particularly exceptional circumstances, does ENISA initially receive just the basic information until the full notification is passed on.

Sources

Regulation (EU) 2024/2847, Articles 14 and 16, recital 68, Official Journal of the EU, 20 November 2024.
Commission guidance C(2026) 5252, Annex, paragraphs 209 to 221, European Commission, 27 July 2026.
CRA SRP Glossary, Version 1.4, ENISA, 1 October 2026.
Guidance: AR Notification Submission and Update, ENISA, 12 September 2026.
CRA Single Reporting Platform: Frequently Asked Questions, ENISA, as of 3 October 2026.
Single Reporting Platform (CRA) (in German), BSI, as of September 2026.