CRA Vulnerability Reporting Template: All 6 Report Forms Mapped Field by Field to ENISA’s Platform

Short answer: a complete CRA vulnerability reporting template has six forms, not one. Article 14 of the Cyber Resilience Act sets up two reporting tracks, actively exploited vulnerabilities and severe incidents, and each runs through three stages: a 24-hour early warning, a 72-hour notification and a final report. The law sets the minimum content of each stage in Article 14(2)(a)–(c) and 14(4)(a)–(c). ENISA’s Single Reporting Platform (SRP), where every filing must go, adds its own list of 41 numbered fields and marks each one required or optional at each stage. A usable template has to satisfy both lists at once, and in a few places they disagree.

Most free “CRA vulnerability templates” you’ll find are public security advisories. That’s the notice to users under Article 14(8), a different document with a different audience. This guide covers the three regulatory filings on both tracks, field by field, against version 1.5 of ENISA’s field glossary (15 October 2026) and the SRP release of 12 October 2026.

One disclosure: we sell a CRA reporting pack that contains report templates. Weigh the product mention below with that in mind. Every legal and platform claim here is sourced to the Official Journal, ENISA or the European Commission.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Who has to file these six forms

In plain terms: if you’re the manufacturer of a connected hardware or software product sold in the EU, these forms have applied to you since 11 September 2026. That includes products you placed on the market years ago.

Article 71(2) of Regulation (EU) 2024/2847, the Cyber Resilience Act, applies Article 14 from 11 September 2026, fifteen months before the rest of the Regulation. Article 69(3) extends it to every in-scope product “placed on the market before 11 December 2027”. Article 64(2) puts breaches of Article 14 in the top fine bracket: up to €15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher.

Your situation	Do you file?	Basis
Manufacturer of a product with digital elements made available in the EU	Yes, since 11 September 2026, including legacy products	CRA Art. 14, 69(3), 71(2)
Non-EU manufacturer	Yes, through the CSIRT picked by the fallback order (authorised representative, importer, distributor, users)	CRA Art. 14(7)
The exploited flaw sits in a third-party component you integrate	Yes. The component’s maker files too, if it placed the component on the market	Commission FAQ 5.4
Medical or in-vitro diagnostic device, or vehicle type-approval product	No, the CRA does not apply	CRA Art. 2(2)
Open-source software steward	From 11 December 2027	CRA Art. 71(2); ENISA FAQ 29
Researcher, customer or other non-manufacturer	Not through these mandatory forms; contact the national CSIRT	ENISA FAQ 30

If the first two rows describe you, plan for all six forms. For legacy products, the Commission’s CRA FAQ (section 5.3) adds a useful limit: you must notify, but the CRA doesn’t require you to apply its other obligations, such as vulnerability handling, to those older products. Where the CRA sits among your other duties is covered in our cyber resilience act compliance guide.

Statute versus platform: why every form needs two columns

In plain terms: the law says what each report must contain at minimum. The platform decides which boxes stop you from pressing “submit”. Fill in whichever list asks for more at each stage.

Article 14 uses “at least” for the final reports and “as available” for the 72-hour notifications. ENISA’s CRA SRP Glossary turns that into 41 numbered fields, one of them with a sub-field, and marks each one required, optional, required if available, or carried forward at each stage. ENISA’s FAQ 16 explains that “required” means the field stems directly from a CRA obligation “or identified by logical consequence”. That second phrase is why the platform asks for things the Regulation never mentions.

When we checked our own report templates against Glossary v1.5, the differences fell into three groups:

Where	What the CRA says	What the SRP enforces	What your template should do
24-hour early warning	Track, plus the Member States “where applicable”	Title, summary, product name and product version are all required, and so is at least one Member State	Collect product version and distribution data before an incident, not during it
72-hour notification	Measures taken and measures users can take are part of the notification	Fields 16 and 17 are optional at 72 hours and become required only at the final report	Fill them at 72 hours anyway; the statutory text lists them
Sensitivity	Listed in the 72-hour notification, Art. 14(2)(b) and 14(4)(b)	Field 15 is optional at both the early warning and the 72-hour stage	If you want dissemination delayed, state it at the early warning (see below)

The sensitivity row has a drafting quirk behind it. Article 16(2) lets a CSIRT delay passing on a notification “in light of the level of sensitivity of the notified information as indicated by the manufacturer under Article 14(2), point (a)”. Point (a) is the early warning, but the sensitivity indication itself is listed in point (b). The platform settles this by offering field 15 at both stages. In practice, that means a sensitivity request belongs in your first filing.

The CRA timings also don’t match the NIS2 ones you may already have templates for. NIS2’s 24 hour early warning needs only two facts. By law the CRA early warning is just as short, but the SRP’s required fields make it a real form.

The common block: fields every one of the six forms carries

In plain terms: eighteen fields appear on both tracks. Seven of them are required in the first 24 hours, and all seven can be pre-filled today for every product you sell.

The glossary shows each common field carried forward from stage to stage, so whatever you enter in the early warning becomes the starting point for the 72-hour notification. A sloppy title at hour 3 follows the case to the final report. The table lists the fields with ENISA’s character limits, because a limit you discover at hour 23 costs time.

Glossary field	Required at	Limit	Drafting rule
1 Notification type	Early warning	Select	Vulnerability or incident. This choice changes the fields that follow
2 Title	Early warning	255	Product + version + issue, with no exploit detail
3 Summary	Early warning	4,000	What happened, affected versions, known impact, mitigation status
4 Manufacturer name	Early warning	Auto	Filled from your SRP registration; check it matches your technical documentation
5 Member States (concerned CSIRTs)	Early warning	Select	Your coordinator CSIRT is preset; add every Member State where the product is sold
6–7 Product name and version	Early warning	255 each	Exact identifiers or a range, e.g. “4.0 to 4.2.1”
8–10 Product type, class, category	Optional	Select	Default, important (class I or II) or critical, per Annexes III and IV
11 End of support	Optional	Yes/No	Worth flagging for legacy products
12 Component name	Optional	255	The affected library or module, with version
13 Mitigating measure expected shortly	Optional	Yes/No	Tick “Yes” only with a remediation plan behind it (see below)
14, 17 User actions	17 at final report	4,000	Steps users can take: the fix first, then workarounds
15 Sensitivity	Optional	255	Name the sensitive element and the harm of early disclosure. ENISA says: no generic confidentiality statements
16 Measures taken	Final report	2,000	Completed actions, with dates
18 Attack vector	Optional (72h, final)	255	Interface, protocol, access path

Field 13 deserves more care than its yes/no format suggests. Commission Delegated Regulation (EU) 2026/881 lists the grounds on which the receiving CSIRT may delay passing your notification to other CSIRTs. Article 3(a) covers the case where the manufacturer has said “an effective risk mitigation measure, such as a security update or user guidance, is expected to be made available within 72 hours”. If it doesn’t arrive in that window, the CSIRT must disseminate. The glossary wording of field 13 closely follows that sentence. Our reading: a “Yes” here is a promise of a fix within 72 hours, not a hope. The CSIRT still decides, and Article 3 also requires that the risks of dissemination outweigh its benefits and can’t be handled with sharing restrictions such as the Traffic Light Protocol.

Vulnerability track: Forms 1 to 3, field by field

In plain terms: the early warning says “this product is being exploited”. The 72-hour notification explains how and what users can do. The final report, due 14 days after a fix exists, gives the full picture and the fix.

Form	CRA anchor	SRP fields that become required	What to write
1 Early warning (24h)	Art. 14(2)(a)	1–7, plus v26 awareness time (not yet live)	Common block; awareness time in UTC; optional CVE (v19) or EUVD ID (v20) if one exists
2 Vulnerability notification (72h)	Art. 14(2)(b)	v21 General information; v26a when the exploitation occurred	Vulnerability class, how the exploit works in general terms, measures taken (16), user measures (17), sensitivity (15)
3 Final report (14 days after fix)	Art. 14(2)(c)(i)–(iii)	v24 severity, v25 impact, v27 malicious actor (if available), v22 fix date, v23 update details, 16, 17	Full description with severity rating and rationale, actor information, patch versions and channel

Three details catch teams out on this track. First, the glossary footnotes field v26, the time you became aware of the exploitation, as arriving “in the next release”. Until then, the platform has nowhere to record the timestamp your 24-hour clock runs from. Put it in the summary and in your own log. Second, field v27, information on the malicious actor, has a 100-character limit. That’s enough for “Unknown actor; indicators in ref. CRA-2026-014” and little else, so keep the indicator set in a document you can share through the CSIRT’s secure channel. Third, the statute only asks for actor information “where available”. Writing “no reliable information available” is a valid answer; speculative attribution is not.

Form 2 is also the only place where Particularly Exceptional Circumstances (PEC) can be claimed. ENISA’s PEC guidance puts the toggle at the bottom of the 72-hour template. It offers the three Article 16(2) grounds: exploitation confined to the coordinator’s Member State, essential national interests, or an imminent high risk from further dissemination. It also gives an 800-character justification field (v30). If you claim PEC, ENISA receives only limited information until the CSIRT decides. Where the vulnerability is moving through coordinated disclosure, read our note on zero-day disclosure under NIS2 Article 12, since Article 16(6) of the CRA ties into that procedure.

Severe-incident track: Forms 4 to 6, field by field

In plain terms: the incident early warning must say whether you suspect a malicious or unlawful cause. The 72-hour notification gives an initial assessment. The final report, due one month after the 72-hour filing, names the root cause.

Form	CRA anchor	SRP fields that become required	What to write
4 Early warning (24h)	Art. 14(4)(a)	1–7, i31 suspected unlawful or malicious acts, i37 awareness time	“Yes”, “No” or “Unknown” plus a factual basis, in 255 characters
5 Incident notification (72h)	Art. 14(4)(b)	i32 nature of the incident, i38 when it occurred, i39 initial assessment	Confirmed facts kept apart from what’s under investigation; measures taken (16) and user measures (17)
6 Final report (1 month after Form 5)	Art. 14(4)(c)(i)–(iii)	i34 severity, i35 impact, i36 threat type or root cause, i33 applied and ongoing measures, 16, 17	Timeline, affected products and functions, root cause, completed and open remediation with target dates

The platform has no field for which severity criterion applies, (a) loss of protection for sensitive or important data or functions, or (b) malicious code. Article 14(5) makes that the reason the incident is reportable at all, so name the criterion in the summary of Form 4. Root cause (i36) is limited to 255 characters. Treat it as a classification plus one sentence, such as “Supply-chain compromise: unauthorised change to the update package”, and put the evidence in i34. Field i37 is currently labelled “date and time when the incident was detected”, but the glossary explains it as the moment you became aware. Detection by a tool and awareness by the manufacturer can be hours apart, so record both in your log and enter the awareness time.

If your company is also an essential or important entity under NIS2, the same compromised build server can trigger a second report with a different final-report clock. Compare the CRA’s one-month rule with the NIS2 72 hour notification requirements and the NIS2 one-month final report, which runs from a different filing.

What the platform does with your forms: five traps in the current release

In plain terms: the SRP helps, but its counters and locks don’t match the law exactly. Your own log, not the platform, has to hold the deadlines.

1. The 72-hour counter keys off your early warning, not your awareness. ENISA’s SRP FAQ (question 26) says the counter shows a due time 48 hours after the early warning is submitted. File the early warning at hour 4 and the counter warns you at hour 52, which is harmless. File it late, at hour 30, and the counter shows hour 78, six hours after the statutory deadline. ENISA plans to switch to the awareness field in a later release.
2. There’s no counter for the vulnerability final report. The same answer confirms the 14-day clock depends on when a fix becomes available, so the SRP doesn’t count it. The severe-incident counter does run, one month from the 72-hour submission. For how all four Article 14 deadlines are counted, including the weekend rule for the 14-day and one-month reports, see CRA reporting requirements.
3. You can’t skip a stage. Article 14(2)(b) and (c) apply “unless the relevant information has already been provided”. But ENISA’s submission guidance makes a submitted early warning a precondition for the 72-hour tab, and both earlier stages a precondition for the final report. If you already have everything at hour 40, file the 72-hour notification and then the final report straight away.
4. The case locks at the final report. The platform’s route for an intermediate report a CSIRT asks for under Article 14(6) is the update function, and each update alerts the coordinator, ENISA and any CSIRT that has already received the case. Once the final report is submitted, the guidance says the notification can no longer be edited. Don’t file it until it’s accurate.
5. Mistakes and outages run through the CSIRT. Only the coordinator CSIRT can close a notification filed in error (FAQ 34). If the platform is down, you may contact your CSIRT directly but must still file on the SRP once it’s back (FAQ 25). There’s no API at launch, and the interface is English-only.

Picking the right coordinator also isn’t the same exercise as finding a NIS2 portal. Article 14(7) works from where your product cybersecurity decisions are “predominantly taken”, which may not be your registered office. Our map of national CSIRT reporting portals covers the NIS2 side.

Who fills which field

In plain terms: one person cannot write all six forms at 2 a.m. Split the fields by who actually holds the facts, and name a backup for each.

Field group	Owner	Prepared before any incident?
Track choice, awareness time (1, v26, i37)	PSIRT lead or CRA compliance officer	Decision criteria, yes
Product identity and distribution (5–12)	Product management with sales operations	Yes, per product and version
Technical narrative (v21, v24, v25, i32, i34–i36, i39)	PSIRT or incident lead	Wording patterns only
Measures and fixes (14, 16, 17, v22, v23)	Engineering release manager	Update channels and workaround library
Sensitivity, delay, PEC (13, 15, v28–v30)	Legal or compliance with the CISO	Criteria, yes
Submission	Primary and secondary assigned representatives registered on the SRP	Registration, yes

For a CISO, the work is in the narrative fields and their character limits. For a compliance officer, it’s the two-column check and an evidence log that records each submission time and SRP reference, because the platform’s counters aren’t proof of on-time filing. For a small manufacturer with one product line, the minimum is shorter: register two representatives, pre-fill fields 1 to 12 for every product version you ship, and keep a timestamped log. That covers most of what the platform requires in the first 24 hours.

The public advisory is a seventh document

In plain terms: Article 14(8) requires you to tell affected users, and that notice is separate from the six regulatory forms.

Article 14(8) requires you to inform “the impacted users … and where appropriate all users” and, where needed, of the mitigation steps they can take, “where appropriate in a structured, machine-readable format”. If you don’t do it in time, the notified CSIRTs may inform users themselves. Draft field 17 so it can be reused word for word in the advisory, and the two will never contradict each other. The public advisory templates online are useful for this step. They don’t replace Forms 1 to 6.

Frequently asked questions

Is there an official ENISA or Commission template for CRA reports?

No downloadable one. The SRP web forms and ENISA’s glossary are the closest thing. Article 14(10) says the Commission “may” set the format by implementing act, and as of 19 October 2026 the Commission’s CRA reporting page lists only the delegated act on dissemination delays.

Do I need a CVE ID before I file the early warning?

No. CVE (v19) and EUVD (v20) fields are optional and should be left empty if no ID exists. ENISA is a CVE Numbering Authority and may contact you about adding a publicly known vulnerability to the EU Vulnerability Database (FAQ 35).

Can I combine the 72-hour notification and the final report?

In law, yes, where the information was already provided. On the platform, no: the final report tab opens only after the 72-hour notification has been submitted, so file them one after the other.

What counts as the moment I “became aware”?

The CRA doesn’t define a channel. The Commission’s FAQ 5.1 gives examples: a customer report backed by reliable evidence, threat intelligence, a government agency’s notice, or your own telemetry. Log the time reliable evidence reached you, in UTC, because the platform’s own field for it isn’t live yet on the vulnerability track.

Which fields can I complete before any incident?

Fields 4 to 12 for every product and version, your Member State distribution list, your assigned representatives, and decision criteria for fields 13 and 15. That leaves the title, summary and timestamps for the day itself.

Sources

1. Regulation (EU) 2024/2847 (Cyber Resilience Act) — Official Journal of the European Union, EUR-Lex. Articles 2(2), 14, 16, 64(2), 69(3) and 71(2).
2. Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 on delaying the dissemination of notifications — Official Journal of the European Union, EUR-Lex. Articles 3 to 5.
3. ENISA. CRA SRP Glossary, version 1.5 (15 October 2026) — EU Agency for Cybersecurity.
4. ENISA. Frequently Asked Questions, CRA Single Reporting Platform — EU Agency for Cybersecurity. Questions 15, 16, 25, 26, 29, 30, 34 and 35.
5. ENISA. CRA SRP Guidance — AR Notification submission and update — EU Agency for Cybersecurity, last updated 12 September 2026.
6. ENISA. CRA SRP Guidance — Particularly Exceptional Circumstances (PEC) — EU Agency for Cybersecurity, last updated 12 October 2026.
7. ENISA. Single Reporting Platform (SRP) — EU Agency for Cybersecurity, platform upgraded to version 1.1 on 12 October 2026.
8. European Commission. FAQs on the Cyber Resilience Act — Commission services, sections 5.1 to 5.4.
9. European Commission. Cyber Resilience Act: reporting obligations — Shaping Europe’s digital future.