Most CRA reporting guidance stops at the deadlines. The 24-hour early warning, the 72-hour notification, the final report. What it rarely tells you is the part that actually consumes your time during a live incident, which is the specific information each of those reports must contain. ENISA has now published the data fields the Single Reporting Platform (SRP) will collect, and the structure tells you a great deal about how to prepare.
This post maps every field across the three reporting stages, separates the vulnerability fields from the incident fields, and explains what the staged "mandatory now, confirmed later" design means for your internal process. It complements our walkthroughs of how reporting is routed to ENISA and national authorities and the reporting timelines and follow-up obligations.
Why the field map matters before an incident
The SRP is built around a single idea. A manufacturer files once, and the platform routes the notification to the designated coordinating CSIRT and ENISA at the same time, with onward distribution to other affected member states. Filing once sounds simple. It is simple only if you can produce the required fields under a 24-hour clock that starts the moment you become aware of an actively exploited vulnerability or a severe incident.
The fields are not the same at each stage. The early warning asks for very little, by design, so you can notify fast on a preliminary basis. The 72-hour notification asks for a real assessment. The final report asks for the full description and the remediation detail. Knowing which fields land at which stage lets you pre-build templates and assign owners, so that nobody is hunting for a product category or a CVE identifier while the clock runs.
The legend, decoded
ENISA marks each field with an indicator showing how it behaves at each stage. The four markers are worth learning, because they tell you what is genuinely required versus what the system fills for you.
- X means mandatory. It is a core requirement at that stage and the report is incomplete without it.
- C means confirmed or carried forward. The value you gave earlier is brought forward and confirmed or refined at the later stage.
- O means optional. You may provide it if you have it, but it is not required at that stage.
- A means automated. The platform fills it for you, typically a timestamp or reporter identity.
- I means informational, provided if applicable.
The pattern to notice is the migration from X to C as a report matures. A field that is mandatory at 24 hours becomes a confirmed field at 72 hours and final. A field that is optional at 24 hours often becomes mandatory at 72 hours once you have had time to assess. The form is engineered to match what a manufacturer can realistically know at each point in an unfolding event.
Common fields, every notification
These fields apply to both vulnerability and incident notifications.
| Field | 24h | 72h | Final |
|---|---|---|---|
| Notification type (Vulnerability / Incident) | Mandatory | Confirmed | Confirmed |
| Notification level (24h / 72h / Final) | Mandatory | Mandatory | Mandatory |
| Reporting time, 24h | Automated | Automated | Automated |
| Reporting time, 72h | Automated | Automated | Automated |
| Reporting time, Final | Automated | Automated | Automated |
| Reporter | Automated | Automated | Automated |
| Name of manufacturer or open-source software steward | Mandatory | Confirmed | Confirmed |
| Product | Mandatory | Confirmed | Confirmed |
| Product type (Default / Important / Critical) | Optional | Confirmed | Confirmed |
| Product category (if not Default, CRA Annex III/IV) | Optional | Confirmed | Confirmed |
| Member States where product available | If applicable | Confirmed | Confirmed |
| Title | Mandatory | Confirmed | Confirmed |
The takeaway from the common block is that the early warning is genuinely lightweight. You need the type, the level, who you are, which product, and a title. Everything else in this block is automated, optional, or refined later. If your product catalogue already maps each product to its CRA classification under Annex III or IV, you can populate the product type and category immediately rather than treating them as later work.
Vulnerability-specific fields
When the notification concerns an actively exploited vulnerability, these fields apply on top of the common block.
| Field | 24h | 72h | Final |
|---|---|---|---|
| CVE ID | Optional | Confirmed | Confirmed |
| EUVD ID | Optional | Confirmed | Confirmed |
| General information | Optional | Mandatory | Confirmed |
| a. General nature of the vulnerability | Optional | Mandatory | Confirmed |
| b. General nature of the exploit | Optional | Mandatory | Confirmed |
| Corrective or mitigating measures taken | Optional | Mandatory | Confirmed |
| Corrective or mitigating measures users can take | Optional | Mandatory | Confirmed |
| Considered sensitivity of information | Optional | If applicable | Confirmed |
| Date corrective or mitigating measure became available | Optional | Optional | Mandatory |
| Full description of the vulnerability | Optional | Optional | Mandatory |
| a. Severity of the vulnerability | Optional | Optional | Mandatory |
| b. Impact of the vulnerability | Optional | Optional | Mandatory |
| Malicious actor exploiting the vulnerability | Optional | Optional | If applicable |
| Details about the security update / corrective measures | Optional | Optional | Mandatory |
Two things stand out. First, the 72-hour notification is where the substance lands. The general nature of the vulnerability and the exploit, plus the corrective measures taken and the measures users can take, all become mandatory at 72 hours. That is the assessment stage, and it is the one most manufacturers underestimate. Second, the final report is dominated by remediation evidence. The date the fix became available, the full description with severity and impact, and the details of the security update are all mandatory at the end. The final report is, in effect, the proof that you closed the loop.
The "considered sensitivity of information" field deserves attention. It is where you flag that wide circulation of technical detail would itself increase risk before a fix is widely deployed. That flag connects directly to the delayed-dissemination mechanism the Commission set out in its December 2025 Delegated Regulation, which lets a coordinating CSIRT hold back distribution of a notification on security grounds.
Incident-specific fields
When the notification concerns a severe incident rather than a vulnerability, these fields apply on top of the common block.
| Field | 24h | 72h | Final |
|---|---|---|---|
| Incident suspected to be caused by unlawful or malicious acts | Mandatory | Confirmed | Confirmed |
| General information about the nature of the incident | Optional | Mandatory | Confirmed |
| Date and time the incident was detected | Optional | Mandatory | Confirmed |
| Date and time the incident occurred | Optional | Mandatory | Confirmed |
| Initial assessment of the incident | Optional | Mandatory | Confirmed |
The incident path front-loads one judgement at the 24-hour mark, which is whether the incident is suspected to stem from unlawful or malicious acts. That flag is mandatory in the early warning. Everything else, the nature, the detection and occurrence timestamps, and the initial assessment, becomes mandatory at 72 hours. Note the deliberate split between when an incident was detected and when it occurred. The platform wants both, so capture both timestamps from the start of your internal handling.
No API at launch, so design for manual entry
One operational constraint shapes how you should prepare. ENISA has stated that no application programming interface will be provided at this stage. Manufacturers can build internal workflows that assemble the required data fields ahead of time, but the submission itself will be manual through the platform interface, at least initially.
For a manufacturer that anticipates a high volume of notifications, this matters. You cannot pipe reports straight from an internal tracker into the SRP on day one. The practical response is to treat the field map above as the schema for your own intake. Capture and structure the data internally so that, when an event qualifies, a human can transcribe a complete, pre-assembled notification quickly rather than composing it from scratch. The fields ENISA marks as automated will be filled by the platform, so your internal preparation should focus on everything marked mandatory or confirmed.
What to do with this now
Build three templates, one per stage, populated with the fields above. Pre-fill everything you can know in advance, which is your manufacturer name, your product list, each product's CRA classification, and the member states where each product is available. Assign an owner for the 72-hour assessment fields, because that is where the real work concentrates. And decide in advance who makes the sensitivity-of-information call, because that decision interacts with whether and when your report is disseminated onward.
The SRP rewards manufacturers who treat the reporting form as a known quantity rather than a surprise. The field map is published. The preparation is yours to do before the obligation starts to apply on 11 September 2026.