CRA Article 14 Notification Template, Field by Field

2026-09-26 · Yunus Yildiz

Article 14 of the Cyber Resilience Act has applied since 11 September 2026. The law says what each notification must contain; ENISA's single reporting platform decides what that looks like on screen. The two are not the same list. ENISA's field glossary (version 1.3, 25 September 2026) describes 39 fields. At the 24-hour early warning, eight of them are mandatory for a vulnerability and nine for an incident.

This post maps Article 14 to those fields, stage by stage, and ends with a template you can fill in before the clock starts. For the deadlines themselves and when a manufacturer "becomes aware", see the 24h/72h/14-day reporting clock.

Settle These Before Anything Happens

Four answers do not depend on the vulnerability, and each one costs time if it is worked out under a 24-hour deadline.

• Which CSIRT receives the notification. The one designated as coordinator in the Member State of your main establishment, which Article 14(7) defines as the Member State where decisions about the cybersecurity of your products are predominantly taken. If that cannot be determined, it is where you employ the most people in the Union. Manufacturers without an EU establishment follow the cascade in the same paragraph: authorised representative, importer, distributor, then users.
• Which end-point you use. Article 14(7) lets each coordinating CSIRT run its own electronic end-point on the platform. In the Netherlands, for example, the NCSC takes CRA notifications through MijnNCSC or a web form without an account, and forwards them to ENISA and the other CSIRTs concerned. The screens can differ from ENISA's; the content the law requires at each stage does not. The field names below are ENISA's.
• The official name and version scheme of each product. ENISA asks for "the same name that appears in product technical documentation or market information", and for every affected version, release or build, stated as a range where needed (both fields allow 255 characters).
• Where each product is on the market. The notification lists the Member States in which you are aware the product has been made available. The receiving CSIRT forwards it to the CSIRTs of those Member States (Article 16(2)).
• Who submits. A named role with backups, not one person. Registration on the platform is covered in the reporting clock post.

Stage 1: The 24-Hour Early Warning

What the law requires. For an actively exploited vulnerability, Article 14(2)(a) asks for an early warning "indicating, where applicable, the Member States on the territory of which the manufacturer is aware that their product with digital elements has been made available". For a severe incident, Article 14(4)(a) adds "at least whether the incident is suspected of being caused by unlawful or malicious acts".

What the platform requires. Mandatory at this stage:

Everything else is optional at 24 hours. That is deliberate: the early warning says that something is happening and where, not what it is. ENISA's guidance for the awareness time is that if the exact time is unknown, you enter the best supported estimate and say it is an estimate.

Stage 2: The 72-Hour Notification

What the law requires. For a vulnerability, Article 14(2)(b): general information about the product, "the general nature of the exploit and of the vulnerability", corrective or mitigating measures taken and those users can take, and "where applicable, how sensitive the manufacturer considers the notified information to be". For an incident, Article 14(4)(b): the nature of the incident, "an initial assessment of the incident", the same two kinds of measures, and the same sensitivity indication.

What the platform requires in addition to the early-warning fields:

• Vulnerability: General information (a high-level description of the vulnerability and how it is exploited) and the date and time the vulnerability occurred, known or estimated.
• Incident: General information about the nature of the incident, the date and time it occurred, and an initial assessment (preliminary severity, scope and likely impact, with confirmed findings kept apart from what is still under investigation).

Two fields are optional here but matter more than their label suggests, because they are what a CSIRT can rely on to delay passing your notification to other Member States:

• Considered sensitivity of information (max. 255 characters). Article 16(2) lets the receiving CSIRT delay dissemination "upon request by the manufacturer and in light of the level of sensitivity of the notified information as indicated by the manufacturer". ENISA asks for a concrete justification and says not to use "a generic confidentiality statement".
• Mitigating measure expected shortly (Yes / No). Delegated Regulation (EU) 2026/881, Article 3, lets the CSIRT delay dissemination where the risks of disseminating outweigh the benefits and cannot be contained by sharing restrictions such as the Traffic Light Protocol, and at least one condition is met. The first condition is that the manufacturer has told the CSIRT "an effective risk mitigation measure, such as a security update or user guidance, is expected to be made available within 72 hours". If it is not delivered in that time, the CSIRT disseminates the notification.

The platform also offers Particular Exceptional Circumstances at this stage only. They correspond to the three situations in the third subparagraph of Article 16(2): exploitation confirmed in only one Member State; further dissemination that would be contrary to that Member State's essential interests; or an imminent high cybersecurity risk from further dissemination. Selecting one limits what reaches ENISA immediately; it is for those cases, not for ordinary confidentiality.

Stage 3: The Final Report

When. For a vulnerability, no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)). For an incident, within one month of the 72-hour incident notification (Article 14(4)(c)). The two clocks start from different events.

What the law requires at least: for a vulnerability, a description including severity and impact, information on any malicious actor where available, and details of the security update or other corrective measure. For an incident, a detailed description with severity and impact, the likely type of threat or root cause, and applied and ongoing mitigation measures.

What the platform requires:

Everything submitted earlier is copied forward and can be updated, so the final report is a completion of the same case, not a new form.

What the Platform Does Not Cover

Two obligations sit outside the three submissions.

• Informing users. After becoming aware, the manufacturer "shall inform the impacted users ... and where appropriate all users" of the vulnerability or incident and of mitigation they can deploy, "where appropriate in a structured, machine-readable format that is easily automatically processable" (Article 14(8)). If you do not do it in time, the CSIRT may. A security advisory in a machine-readable format such as CSAF is one way to meet this; the Regulation does not name a format.
• Intermediate reports. The receiving CSIRT may ask for status updates between the notification and the final report (Article 14(6)).

The Template

Fill in the first block once per product and keep it with the incident runbook. The rest is filled in per case.

== PER PRODUCT (prepare now) ==
Product name (as in technical documentation):
Version scheme and how to express an affected range:
Components that can be named separately (name + version):
Member States where the product is made available:
Product type / class / category (Default | Important I/II | Critical):
End of support reached? (Yes/No, per version):
Coordinating CSIRT (Member State of main establishment, Art. 14(7)):
Submitting role and backups:

== 24 HOURS: EARLY WARNING ==
Notification type: Vulnerability | Incident
Title (<=255):
Summary (<=4000): what is happening, which product, current status
Member States concerned:
Product name / affected versions:
Became aware (UTC, mark if estimated):
[Incident] Suspected unlawful or malicious acts: Yes | No | Unknown

== 72 HOURS: NOTIFICATION ==
[Vulnerability] General information: the vulnerability and how it is exploited
[Vulnerability] Occurred since (UTC, known or estimated):
[Incident] Nature of the incident:
[Incident] Occurred at (UTC):
[Incident] Initial assessment: severity, scope, impact; confirmed vs open
Measures taken so far:
Measures users can take now:
Sensitivity of the information (concrete reason, <=255):
Mitigating measure expected within 72 hours: Yes | No
Particular exceptional circumstances (Art. 16(2), third subparagraph): none | (a) | (b) | (c)

== FINAL REPORT ==
[Vulnerability] due: 14 days after the fix or mitigation is available
[Incident] due: one month after the 72-hour notification
Date the fix or mitigation became available (UTC):
Details of the security update or corrective measure:
Severity, with rating and rationale:
Impact: systems, components, data, users affected:
[Vulnerability] Malicious actor (if known, <=100):
[Incident] Type of threat or root cause (<=255):
Applied and ongoing mitigation:

== USERS (Art. 14(8)) ==
Advisory published (where, format):
Users informed (impacted / all), date:

Where Per-Release Evidence Pays Off

The fields that are hardest to fill in under time pressure are not the narrative ones. They are Product version and Component name: which of your releases contain the vulnerable component, stated exactly. That is an inventory question, and it is answered in minutes if every release carries its own SBOM bound to the artifact, or in days if someone has to reconstruct it from build logs. The same record answers the final report's question about when the fix became available, because the release that contains it has a date.

Sources

• Regulation (EU) 2024/2847, Article 14 and Article 16, verbatim Official Journal text on this site.
• ENISA, CRA SRP Glossary, version 1.3, last updated 25 September 2026: field names, stage requirements and character limits.
• Commission Delegated Regulation (EU) 2026/881 of 11 December 2025, EUR-Lex: grounds on which the receiving CSIRT may delay dissemination.
• NCSC, Melden onder de Cyber Resilience Act: the Dutch end-point.

This article reflects our reading of the Regulation and of ENISA's published glossary as of the date above. The platform's fields may change; check the current glossary before relying on a specific field. It is not legal advice.