A filled-in CRA early warning: every field, with an example

A CRA early warning is the first of three Article 14 filings, due within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident in your product. On ENISA's Single Reporting Platform it has seven required fields for a vulnerability and eight for an incident. Below is every field, which ones the platform requires, their character limits, and a worked example you can use as a template.

What does the Regulation require in a CRA early warning?

Very little, on purpose. Article 14(2)(a) asks a vulnerability early warning only to indicate, where applicable, the Member States where you know the product has been made available. Article 14(4)(a) asks an incident early warning for the same, plus whether the incident is suspected of being caused by unlawful or malicious acts.

Both are due "without undue delay and in any event within 24 hours" of the manufacturer becoming aware.Art. 14⁠(2)⁠⁠(a)⁠Art. 14⁠(4)⁠⁠(a)⁠ Both go to the CSIRT designated as coordinator and to ENISA at the same time, through the single reporting platform.Art. 14⁠(7)⁠

The early warning is not meant to be complete. The 72-hour notification adds the nature of the exploit or incident and the measures taken. The final report adds severity, impact and root cause. If you try to write the final report at hour twenty-three, you will either miss the deadline or guess.

Which fields does the ENISA SRP ask for in an early warning?

ENISA publishes a field-by-field data definition for the platform, the CRA SRP Glossary. Declara's packet is aligned to Version 1.3, 10 September 2026. The platform asks for more than the article text: a notification type, a title, a summary, the product and versions, and the awareness time. Where the two disagree, the form is what you meet at hour twenty-three.

Every field Declara carries for an early warning is listed below, in the platform's order. "Glossary row" is the reference in ENISA's glossary. A dash means the platform has no such field and the value is for your own record.

That gives seven required fields for a vulnerability: notification type, title, summary, product name, versions, Member States and awareness time. An incident adds the unlawful-acts question, for eight. Field-by-field guidance, including what the platform's validation does not check, is on how to file on the ENISA Single Reporting Platform.

Two of these deserve a note.

Member States applies to both kinds. A strict reading of Article 14(4)(a) could leave it off an incident, but the platform marks it required for both, because it uses the answer to decide which national teams are concerned. Fill it in either way.

The unlawful-acts question has three answers, not two. ENISA's guidance says to select Unknown while the cause remains unresolved. At hour six you often do not know whether you are looking at an attack or a misconfiguration that resembles one. We explain why that matters in why "suspected unlawful" is three states, not a checkbox.

What does a filled-in early warning look like?

The example below is fictional. Example GmbH, its product and every detail in it are invented to show the fields filled in. They describe no real company, vulnerability or customer.

Example GmbH is a manufacturer in Germany. It sells a small industrial gateway, the Example Gateway EG-200, in Germany, Austria and the Netherlands. On a Thursday afternoon, a customer's operations team sends logs showing administrator sessions opened from an unknown external address without valid credentials. Example's firmware lead reproduces an authentication bypass in the web admin interface. At 14:10 local time (12:10 UTC) she records the decision that the vulnerability is being actively exploited against the product. That is the moment of awareness, and the 24 hours run from it.

The summary, about 700 characters against a 4,000-character limit:

An authentication bypass in the web administration interface of Example Gateway EG-200 firmware 3.0 to 3.4.1 allows a remote party with network access to the interface to open an administrator session without valid credentials. On 24 September 2026 a customer provided logs showing such sessions from an external address; we reproduced the bypass internally the same day. We are aware of exploitation at one customer site. Impact observed so far: configuration read access. We have not yet established whether configuration was changed. No fix is available yet. We have advised affected customers to restrict the admin interface to their management network while a firmware update is prepared. A CVE has been requested.

Each sentence does one job: product and range, how Example knows and when, what is observed versus not yet established, and mitigation status. That is what the glossary asks of a summary.

Had this been a severe incident rather than a vulnerability, the notification type would read Incident, and one more field would appear. If Example could not yet tell whether the sessions came from an attacker or from a misused service account, the honest answer would be Unknown.

What should you not put in an early warning?

Leave out anything that helps an attacker, anything you have not established, and anything that belongs to a later stage. The early warning is read by a national CSIRT and ENISA, and may be shared further under Article 16. Write it as if it will travel.

1. Exploit detail. No proof of concept, no request payloads, no endpoint paths beyond what identifies the component. The guidance on the title field asks for no confidential technical detail, and the Regulation asks for the general nature of the exploit only at 72 hours.Art. 14⁠(2)⁠⁠(b)⁠
2. A root cause you have not established. "Caused by a misconfigured load balancer" at hour eight becomes a correction at hour seventy. The root cause belongs to the incident final report.Art. 14⁠(4)⁠⁠(c)⁠
3. Attribution guesses. For a vulnerability, information on the malicious actor is a final-report item, and only where available.Art. 14⁠(2)⁠⁠(c)⁠ Naming a group on a hunch helps nobody.
4. Personal data. Customer names, user accounts or log lines that identify a person do not belong here. Say "one customer site". If personal data was breached, that is a separate GDPR notification to a different authority.
5. Reassurance you cannot support. "No customer data was affected" is a finding. If you have not looked, write "not yet established".
6. The product class as a reason for urgency or delay. Class affects conformity assessment from December 2027. It never changes an Article 14 clock.

Two more things people hold the early warning back for, and should not. You do not need a CVE identifier: write "requested" and carry it into the notification. You do not need a fix. The vulnerability final report runs 14 days from when a corrective or mitigating measure is available, so a case can rest after its 72-hour notification until one is.Art. 14⁠(2)⁠⁠(c)⁠

How is the awareness time decided?

The awareness time is the moment someone at your company concluded the product was affected, not the moment a signal arrived. A catalogue listing, an EPSS score or a scanner hit tells you something about a component, not about your product. It opens an assessment. It does not start a clock.

In the example, the customer's email arrived before 14:10. Awareness is 14:10 because that is when Example's firmware lead had enough to conclude the product was being exploited. Keep the reasoning: who decided, when, and on what evidence. If the exact time is unknown, enter your best supported estimate and say so in the summary. The judgement is examined in more detail in what becoming aware actually means.

The platform shows times in UTC. A team in Berlin that types its local 14:10 into a field read as UTC has recorded awareness two hours late, and every deadline computed from it is two hours later than the real one. That is the dangerous direction to be wrong in. Convert before you paste.

How does the early warning carry into the 72-hour notification?

Most of it carries forward. The notification repeats the title, summary, product and Member States, and adds the nature of the exploit, the measures you have taken and the measures users can take.Art. 14⁠(2)⁠⁠(b)⁠ Article 14 qualifies each later report with "unless the relevant information has already been provided", so what you have already given need not be given twice. That makes the next stage shorter. It does not let you skip it on the strength of a long early warning.

If you have the 72-hour content inside the first 24 hours, you may file the early warning and the notification close together. The step-by-step for the first filing is in file an initial Article 14 report, and the clocks themselves are set out on Article 14, in plain language. The Regulation's own text is on EUR-Lex, and ENISA's material on the platform is on its Single Reporting Platform page.

Where to start

1. Pre-fill the stable fields for every product now: official name, current version range, Member States where it is sold, and support status. None of them should be researched at hour twenty.
2. Write a one-paragraph summary skeleton (product and range, how you know and when, observed impact, not yet established, mitigation status) and keep it beside your vulnerability handling process and disclosure policy outlines.
3. Decide who records the awareness time, in UTC, with a written reason, and rehearse it once on a fictional case like the one above.
4. Run your SBOM through the free KEV check to see which components would open an assessment today.