Reporting through the Single Reporting Platform

Early Warning

Submitted within 24 hours of becoming aware. You declare whether it is an incident or a vulnerability (the form then shows the matching fields), give it a title and summary, and select the countries of distribution, which determines who else is notified.

Only the fields that must be filled in to submit an Early Warning. Everything else on the form is optional at this stage and can be added later — see Every field, explained.

1. 1Select notification type. Depending on the choice (Incident or Vulnerability), the matching fields are shown.
2. 2Multiple products. If one vulnerability affects several products or versions, they can be captured in a single notification.
3. 3Select countries of distribution carefully. This selection determines which additional national CSIRTs are notified.
4. 4Save draft. Notifications can be saved as drafts.
5. 5Submit. The notification and its status then appear on the dashboard; the national CSIRT receives the Early Warning for review and, where applicable, release.
6. 6Editable. After submission, notifications can be adjusted at any time within their current status; the system records all changes.

1. 1

   Start the notification

   

   The Dashboard is also where you come back to everything later. The tabs count what needs attention: All, Needs Submission, Corrective Measures Required, Closed (Previously Valid), Closed (Previously Invalid), Draft. “Valid” and “Invalid” are the CDaC's verdict on the notification; “Closed” is separate — it means nothing further is expected on it — so the two Closed tabs record both at once. You can search by ID, manufacturer or title.

   From practice. No panic, and no early drafts. Nothing in the portal starts a clock until you submit: the 72-hour and Final Report counters run from the moment the Early Warning goes in. The 24-hour obligation itself runs from awareness, and that one the portal does not know about — track it in your own incident ticket. Drafts are visible only to the AR who created them and cannot be handed over — ENISA now says why: a draft is stored in that AR’s own account. So a draft is not a shared working document and the portal is no place to coordinate a globally distributed team; do that outside, and open the portal when there is something to file. Once it is filed, though, it stops being one person’s: any AR of the same manufacturer can open the notification and carry it through the later stages. That changes the staffing question — whoever files the Early Warning no longer has to be the person who will still be there for the Final Report.

2. 2

   Type, title, summary

   

   The type is the first thing you choose and it decides the rest of the form — vulnerability and incident have different field sets from here on.

   Field on this screen	Status	What goes in it
   Notification Type (Vulnerability / Incident)1	Required	“I want to report a Vulnerability” or “I want to report an Incident”. Everything below adapts to this choice.
   Title2	Required	Max. 255 characters. Enough to recognise the product and the issue; no confidential detail that is not needed for identification.
   Summary3	Required	Max. 4,000 characters: what happened, the affected product or version, the known impact, the current mitigation status.

   The screenshot is cropped here. The rest of this form — product, Member States, dates, and the type-specific fields — is in Every field, explained.

   From practice. Decide the type by what triggered it: a vulnerability in your product that is being exploited is an AEV; an attack on your own infrastructure that affects products is a SI. The type cannot be changed afterwards. Title by a fixed pattern — product, affected versions, nature of the problem — so your own list stays sortable months later. Put your internal ticket number in the summary, so what the portal holds can always be matched to what you hold. Mark anything uncertain as an estimate: an Early Warning may be incomplete, it must not be wrong. And never fill a required field with a space or a full stop to get past validation. If there is nothing to say, say that — “no patch will be provided for this end-of-life product” belongs in the measures field, as a measure.

3. 3

   Pick the manufacturer

   

   A pending validation does not block you here.

   Field on this screen	Status	What goes in it
   Manufacturer4	Required	Select one you are associated with, or “+ Add Manufacturer” to create another association on the spot.

   From practice. Pick — or create — the legal entity under whose name the product is on the market, not the company that employs you and not the group parent. That entity is what every CSIRT downstream will match the product against, and it is copied into the notification read-only. Creating a manufacturer from inside a notification works and costs nothing in time: the association starts as Unverified and you may still file up to 20 notifications for it.

4. 4

   Submit, or save a draft

   

   Submitting stores the notification and makes it available to your CDaC and to ENISA; both are alerted by e-mail. Other CSIRTs see it only after the CDaC disseminates it manually. A draft is visible only to you — not to colleagues sharing the same manufacturer.

   From practice. What you type here should already be agreed before it reaches the portal. The draft is visible to nobody but you, so there is no reviewing inside the platform — alignment with Legal, product and management happens outside, in your own incident channel, and the portal gets the settled version. Submit when the required fields are settled; what comes later goes in through Update while the notification is still editable.

5. 5

   After the CSIRT validates

   

   Validation runs in parallel and never blocks a submission. How many notifications you may send before it becomes mandatory is a number ENISA gives twice, differently: the FAQ says 20 for a non-validated AR, while the interface guidance says 10 for an unverified AR who has just added a manufacturer. Both are reproduced here because neither can be shown to supersede the other.

   Status you will see	What it means, in the manual’s words
   Submitted	Sent through the SRP and available for the next workflow step. The stage names are “EW Submitted”, “72h Submitted” (or “72h Submitted under PEC”) and “FR Submitted”.
   Valid	The designated CSIRT has reviewed and accepted the notification. The SRP sends an alert or e-mail when this happens.
   Invalid	The designated CSIRT has reviewed it and marked it as not valid. This is one of the red alerts.
   Closed	No further action is expected for that notification in the current workflow.

   From practice. Unverified changes nothing about what you do: report as normal, the allowance is 20 notifications, and verification is the CSIRT’s job on its own timetable — no calls, no chasing. An Invalid status is the one red alert you can get, and honest word on it: there is no experience yet of what a CSIRT tells you when it rejects a notification, or in what form. What is clear is what not to do — do not simply re-submit. Read what the CSIRT gives you, clarify, and only then file a corrected notification.

6. 6

   Additional notes, at any time

   

   A free channel to the CDaC, outside the staged fields.

   Field on this screen	Status	What goes in it
   AR Note40	Optional	Free text. Writable only by the AR who created the notification — every other AR of the same manufacturer opens it read-only and cannot add to it. The screen carries its own warning: “This field will be shared during the dissemination” — whatever you write here travels with the notification.

   From practice. Treat Additional Notes as public to every CSIRT that receives the dissemination — the banner on the screen says so, and there is no way to send a note only to your own CDaC. Anything you would not want in fifteen national inboxes belongs in a direct call instead.

Screenshots: ENISA, CRA SRP guidance — AR Notification submission and update, retrieved 7 September 2026. Reproduced with acknowledgement per the ENISA Legal Notice. Additional screenshots from ENISA’s CRA SRP – AR User Manual (PDF, Version 1.1), retrieved 10 September 2026. Field meanings from the SRP Glossary.

72 h Notification

Added to the same notification, with the general nature of the vulnerability or incident, an initial assessment and the corrective measures taken so far. Here you can also state reasons against onward dissemination.

Fields that become mandatory now. Everything from the Early Warning is already there, carried over and editable — see Every field, explained.

1. 1Continue the notification. The 72-hour notification is added in the same way as the Early Warning.
2. 2Non-dissemination (optional, vulnerabilities only). For an actively exploited vulnerability — not for an incident — the manufacturer can state reasons against forwarding to other national CSIRTs (Particular Exceptional Circumstances, PEC). See steps 3 and 4 below.
3. 3CSIRT review. If reasons are given, the national CSIRT reviews dissemination and may withhold the notification. The legal basis is Delegated Regulation (EU) C(2025) 8407.
4. 4Partial information to ENISA. Where the manufacturer marks at least one of the conditions of Article 16(2)(a)–(c) CRA, ENISA only receives partial information until the receiving CSIRT discloses the full notification.

1. 1

   Reopen the notification

   

   There is no second notification. You open the existing one and move to the next tab.

2. 2

   The fields that become mandatory now

   

   

   Everything from the Early Warning is carried over and can be corrected. These are the ones that stop being optional.

   Field on this screen	Status	What goes in it
   Considered sensitivity of information15	If available	Free text, not a confidentiality label: name the sensitive element and what premature disclosure would cause.
   Corrective or mitigating measures taken16	Required	What you have already done — containment, configuration changes, withdrawal, credential rotation, monitoring. Max. 2,000 characters.
   Corrective or mitigating measures that user can take17	Required	What users should do themselves, with the version that fixes it.
   General informationv21	Required	Vulnerability only: the vulnerability and its exploitation.
   Date and time when the Actively Exploited Vulnerability occurred (UTC time)v26a	Required	Vulnerability only, and new since 26 September 2026. When the vulnerability occurred — not when you became aware of it, which is a different field. An estimate is fine if marked as one.
   General information about nature of incidenti32	Required	Incident only.
   Initial assessment of the incidenti39	Required	Incident only: severity, scope, affected functions or data. Separate what is confirmed from what is still under investigation.

   Seen on the form, stated nowhere else. The three measures fields — taken, users can take, applied and ongoing — are repeatable: “+ Add another…” adds a further entry rather than making you list several in one box. Narrative fields cap at 4,000 characters; Considered sensitivity of information, Attack vector and Type of threat or root cause at 255. The date-and-time fields are entered as date, hour and minute in separate controls, in UTC.

   From practice. File on time; the 72 hours are a deadline, not a target, and what is not yet confirmed can go in as an estimate — marked as one. The 72-hour notification stays editable until the Final Report is submitted, so a corrected figure is an update, not a failure. The field that is hard in practice is measures users can take. Three honest situations, none of which allows leaving it blank: the product is out of support or is a legacy product placed on the market before 11 December 2027, so no remedy is owed — say exactly that; the product runs in different operating environments and the advice differs — give it per environment; nothing can be recommended yet — say so, and what users should do meanwhile.

3. 3

   Only for a vulnerability: flag PEC

   

   ENISA published a dedicated guidance page for this on 8 September 2026, and it narrows the scope: PEC applies only to the 72-hour notification of an actively exploited vulnerability. Not to incidents, not to the Early Warning, not to the Final Report.

   Field on this screen	Status	What goes in it
   Malicious actor that has exploited / is exploiting the vulnerabilityv27	If available	Visible just above the toggle. Both the screen and the glossary state the limit: max. 100 characters.
   Particular Exceptional Circumstances (PEC)v28	Optional	A toggle, off by default. Turning it on reveals the reasons below.

   From practice. PEC is not a decision the manufacturer takes alone. Before the toggle goes on, the assessment should already have been agreed with your CDaC — by phone, before the 72-hour notification is filed — so that what arrives is a request the CSIRT is expecting, not a surprise it has to rule on under time pressure. If that conversation has not happened, do not toggle it.

4. 4

   Choose the ground, and say why

   

   Invoking PEC sets the dissemination status to “72h Submitted under PEC”. ENISA then receives only limited information under Art. 16(2); the CDaC decides whether to disseminate, and shares the full notification manually.

   Field on this screen	Status	What goes in it
   PEC Delay Reasonv29	Optional	Three checkboxes, one per legal ground: exploitation confined to the CDaC’s own Member State; dissemination contrary to that Member State’s essential interests; imminent high cybersecurity risk from dissemination.
   Please provide further informationv30	Optional	Justification for the CDaC. The screen states max. 800 characters — a limit that appears nowhere in the glossary.

   Three ENISA spellings, one field. The guidance page writes “PEC Delay Reson” in its text while the screenshot shows “Reason”; the platform labels the toggle “Particular Exceptional Circumstances(PEC)” without a space; the FAQ calls the concept “particularly exceptional circumstances”. The second checkbox reads “essential intrests” on screen. All reproduced as found.

   From practice. The justification in the 800-character box is the one agreed with the CDaC, in the words agreed. Its job is to let the CSIRT confirm what has already been discussed, not to persuade it: which of the three grounds, the facts that carry it, and how long the delay is needed for. Anything the CDaC has not heard before belongs in the call, not in this field.

Screenshots: ENISA, CRA SRP guidance — AR Notification submission and update, retrieved 7 September 2026. Reproduced with acknowledgement per the ENISA Legal Notice. Additional screenshots from ENISA’s CRA SRP – AR User Manual (PDF, Version 1.1), retrieved 10 September 2026. Field meanings from the SRP Glossary. PEC screens: ENISA, CRA SRP guidance — Particular Exceptional Circumstances (PEC), retrieved 8 September 2026 — the page appeared that day. Reproduced with acknowledgement per the ENISA Legal Notice.

Final Report

The closing report: a full description with severity and impact, and details of the corrective measure. For vulnerabilities, no later than 14 days after a corrective or mitigating measure is available; for severe incidents, within one month after the 72h notification. Once submitted, the notification is closed.

The last fields to become mandatory. The two description pairs are the substance of the report — severity and impact are separate fields, not a duplicate.

1. 1Complete the remaining fields and submit within 14 days after a corrective or mitigating measure becomes available (vulnerability) or one month after submitting the 72h notification (incident).
2. 2Additional notes serve as an exchange channel with the national CSIRT.
3. 3Closing. Once the Final Report is submitted, the notification is closed; subsequent changes are no longer possible (confirmation dialog “Are you sure?”).

1. 1

   Reopen it one last time

   

   Once this is submitted the notification closes and nothing further can be changed — the platform asks “Are you sure?” first.

   From practice. For a vulnerability, the 14 days between the corrective measure becoming available and the Final Report are not slack — they are the window for informing users under Article 14(8). Use them for that, unless something obvious stands in the way. Once every required piece of information is in hand, file; holding a finished report gains nothing, and after the deadline it is late.

2. 2

   The closing fields

   

   

   The substance of the report. The two description pairs are separate fields, not a duplicate. On this tab the measures fields that were optional at 72 h — taken, users can take, applied and ongoing — carry the “Required” badge for an incident.

   Field on this screen	Status	What goes in it
   Date when corrective or mitigating measure has been availablev22	Required	Vulnerability only — and the date the 14-day deadline runs from.
   Full description of the severity of the vulnerabilityv24	Required	Max. 4,000 characters. ENISA calls the incident equivalent “Detailed description of the Severity”.
   Full description of the impact of the vulnerabilityv25	Required	A separate field from the severity description.
   Malicious actor that has exploited / is exploiting the vulnerabilityv27	If available	Mandatory if known. Do not speculate about attribution.
   Applied and ongoing mitigation measuresi33	Required	Incident only. The FAQ writes “applied and ongoing”, the glossary “applied or ongoing”.
   Detailed description of the Severity of the incidenti34	Required	Incident only. Max. 4,000 characters.
   Detailed description of the Impact of the incidenti35	Required	Incident only. Separate from severity.
   Type of threat or root cause that is likely to have triggered the incidenti36	Required	Incident only.

   After “Proceed” the notification is read-only for you. The manual is explicit: after the Final Report is submitted, the notification is no longer editable by the AR. Anything still wrong has to go through the CSIRT. Until then, every earlier stage can still be corrected with “Update”, and each update alerts the CDaC and whoever already has access.

   From practice. At this stage the measures fields become mandatory, and “none” is a valid answer only if it is written out: no corrective measure, no user measure, and why — end of support, a legacy product placed on the market before 11 December 2027, or a mitigation that removes the need. What is not acceptable is a placeholder to get past the badge. Read the confirmation dialog literally: after Proceed nothing here can be changed by you.

Screenshots: ENISA, CRA SRP guidance — AR Notification submission and update, retrieved 7 September 2026. Reproduced with acknowledgement per the ENISA Legal Notice. Additional screenshots from ENISA’s CRA SRP – AR User Manual (PDF, Version 1.1), retrieved 10 September 2026. Field meanings from the SRP Glossary.

Accounts and roles

Registration creates one account, but a manufacturer normally needs several people able to report — and needs them to stay able to report when someone leaves. The platform handles this with two roles and a set of self-service functions, all under Settings. None of this requires the CSIRT.

1. 1

   Invite a Secondary AR

   

   Primary AR only, and only once your own association shows Verified — the manual and the guidance page agree on that since 9 September. The invitee receives the invitation and completes registration with the manufacturer details pre-filled; someone who already has an SRP account uses the same link to add the association — see Registration, step 5.

   

   Until they accept, the record holds only their email address and the manufacturer, with no role assigned. The link expires after seven days.

   From practice. The button appears only once your own association is Verified — if it is missing, that is why. Invite at least one Secondary early. Since ENISA’s September revision a Secondary is a genuine deputy rather than a spare key: they can open and continue the notifications you filed. Only drafts stay behind — those never leave the account that created them, in either direction.

2. 2

   Claim the Primary role

   

   

   This is the succession path. Without it, an account nobody controls would keep hold of the manufacturer entity when the Primary AR leaves — so agree in advance who claims it.

   From practice. Hand over while the outgoing Primary is still in the company and reachable: the claim goes to the CSIRT for approval, and whether that involves questions back to the manufacturer is not yet known from experience. Do not let a departure and a claim coincide.

3. 3

   Remove an association

   

   Available only while the association is Verified. Use this when someone leaves, rather than abandoning the account. Removing the last association leaves the manufacturer without a representative, so hand the Primary role over first.

   If it is not verified yet, you cannot do it yourself. ENISA spelled out the alternative on 21 September: either wait until verification completes and then remove the association yourself, or contact the CDaC and ask them to reject the AR–manufacturer association. The same FAQ states the permission split for the first time outside the manual — a Primary AR may remove their own association or a Secondary’s; a Secondary AR may remove only their own. ENISA points to section 4.5, “Manage Manufacturer Association”, of the AR User Manual for the procedure.

   From practice. Only after the new Primary has been approved — never before. A manufacturer whose last Primary deletes their association has nobody left who can see all of its notifications.

4. 4

   Add another manufacturer

   

   One account can represent several manufacturers. Each new association is verified separately by the CSIRT of that manufacturer’s Member State, and starts out “Unverified” — with the same 20-notification allowance while it is. The form ends with “Save”, and the SRP confirms the request by e-mail. Acceptance also lands as an in-platform alert, verbatim: “[SRP] AR Association Request - Accepted” — “Your association request with a manufacturer has been accepted by the Designated CSIRT.”

   From practice. One association per legal entity that places products on the market, each verified by the CSIRT of that entity’s own Member State. The person is the same; the coordinator can differ.

5. 5

   Check your details

   

   

   Worth doing before a deadline rather than during one: this is where you confirm the manufacturer is verified and the CDaC is the one you expect.

   From practice. Worth a glance before an incident rather than during one: is the association Verified, is the CDaC the one you meant, is the account still Active.

6. 6

   Watch the dashboard and the alerts

   

   

   Every submission is confirmed twice — by email and by an alert — to you and to all other ARs of that manufacturer. An invalidated notification shows up here, not in your inbox alone.

   What the manual adds about the Dashboard. Every AR of the manufacturer, Primary or Secondary, sees and can update every notification it has filed — the manual reversed the opposite rule on 17 September (see the note below). Drafts are the one exception, and they are private from everyone, the Primary included. Search works on notification ID, manufacturer or title. The default sort is last update, newest first. In the Alerts tab, light blue is unread, grey is read, and red is reserved for critical events such as a CSIRT invalidating a submission. The full filter panel (“All Filters”) adds a checkbox per report stage — Early Warnings, 72h Notifications, Final Reports — alongside the Member State multi-select, separate from the “All Types” AEV/Incident dropdown. Notification identifiers follow the pattern SRP-<country>-<V|I>-<year>-<sequence>, e.g. SRP-GR-V-2026-00000018 for a vulnerability from Greece — not published anywhere, read off ENISA’s own tutorial video. A notification submitted under PEC carries its own status label, “Submitted Under PEC”, in place of the plain checkmark, on the dashboard list and on the notification’s own stage tracker.

   From practice. Any AR of the manufacturer can now pull the full list — for management, for a CSIRT enquiry, for the next audit — so the overview is no longer the Primary AR’s to fetch alone. The one thing nobody else can retrieve is an unfinished draft sitting in a colleague’s account; if that colleague is unreachable, the work is gone and the notification has to be started again.

7. 7

   The profile menu, and logging out

   Click your name, top right, on any logged-in screen. The menu carries an internal user ID (“ID: n…”, not needed for anything a report-filer does), then Settings, FAQ, Contact Support and Logout — there is no separate logout control anywhere else on the page.

   Your account's system role shows as “AR Primary User” or “AR Backup User” internally — the same distinction as “Primary AR” and “Secondary/Backup AR” used everywhere else on this page, just under different names. If EU Login authentication ever fails or the signed-in account is not associated with the portal, the SRP shows a “You are not Authorised” screen: “It seems like you don't have permission to use this portal. Please sign in with a different account”, with a button to sign in as someone else and a link to Contact Support.

Screenshots: ENISA, CRA SRP guidance — AR Interface functions, retrieved 7 September 2026. Reproduced with acknowledgement per the ENISA Legal Notice. Additional screenshots from ENISA’s CRA SRP – AR User Manual (PDF, Version 1.1), retrieved 10 September 2026.

Every field, explained

The phase tables above show what each stage requires. This is the whole form: all 42 fields ENISA itemises, with what each one means, how ENISA says to complete it, its worked example and its expected format. Read it as cards, one field at a time, or switch to the full table below. The source is ENISA’s CRA SRP Glossary, as it stood on 4 October 2026; the meanings, instructions and examples are quoted from it. The character limits come from the running platform, not from ENISA’s documentation — they appear in the form’s own placeholders and are published nowhere, so treat them as accurate as of 13 September 2026 rather than as a specification. They matter when drafting: the field for the malicious actor holds 100 characters.

Field meanings, completion instructions, examples and formats: ENISA, CRA SRP Glossary, version 1.4, as it stood on 4 October 2026. Reproduced with acknowledgement per the ENISA Legal Notice. Field numbers follow the Glossary. They previously followed the data-field table in SRP FAQ question 16, which ENISA removed on 10 September 2026 — that answer now defers entirely to the Glossary, so the Glossary’s numbering is the only one still maintained. See the conversion table below if you are working from an older reference.

Questions & answers

ENISA’s official Single Reporting Platform FAQ, reproduced in full — all 33 questions as they stood on 4 October 2026. Wording is ENISA’s. Read it at the source.