CRA Single Reporting Platform Checklist: What to Prepare for the 24-Hour and 72-Hour Reports
Published September 2026 by Solarc Labs
The reporting clock is easier to manage when the basic product facts already have an owner
ENISA describes the CRA Single Reporting Platform as the single entry point for mandatory reports of actively exploited vulnerabilities and severe incidents affecting products with digital elements. Its current FAQ says the reporting process starts when the manufacturer becomes aware of the relevant vulnerability or incident, with an early warning within 24 hours and a fuller notification within 72 hours. The practical preparation job is therefore not to pre-write a legal conclusion. It is to make sure the organisation knows who can access the reporting workflow, who owns the manufacturer and product facts, who records the awareness point and who can assemble the evidence needed for staged updates.
For the 24-hour stage, prepare identity, product and event facts that can be stated without guessing
ENISA’s published reporting-field table includes common fields such as notification type and level, reporter, manufacturer or open-source software steward, product, title and related product context. Some information is required immediately while other fields become mandatory or are carried forward at later stages. Do not turn unknown incident detail into invented certainty just because the first deadline is short. Preserve what is actually known at the awareness point, identify the affected product accurately and keep an evidence trail for later refinement.
The 72-hour notification is an update to the same case, not a fresh disconnected document
ENISA’s operator guidance shows that the 72-hour notification is submitted from an existing notification after the early warning. The workflow asks the authorised reporter to add the mandatory and relevant optional information for that stage, and the platform records the submission state. That means your incident process should preserve continuity from detection through awareness, early warning, technical assessment and follow-up. Product version, affected scope, mitigation, exploitation evidence and responsible owners should not live in separate unlinked notes if the team expects to update the same regulatory case under time pressure.
Final-report timing also needs an owner before the incident is over
The Commission and ENISA describe different final-report deadlines for actively exploited vulnerabilities and severe incidents: vulnerability reporting continues through the corrective-measure stage, while severe-incident reporting has a later final-report deadline after the initial notification. A team that treats the 72-hour submission as the end of the workflow can therefore lose the evidence and ownership needed to close the case properly. Record the follow-up owner, corrective or mitigating measure evidence and the event history needed to prepare the final stage. Keep legal reportability and the content of an actual regulatory filing with the responsible human decision-makers.
Use a tabletop to test the handoff before a real SRP deadline
A useful rehearsal asks whether the team can identify the affected product, capture the awareness timestamp, preserve the initial evidence, assign technical and legal review, assemble the staged reporting facts and maintain continuity into the final report. The objective is to expose missing ownership and evidence paths before an actual reporting clock begins. CRA Incident Desk is scoped to that readiness problem. It can structure one private tabletop with human triage, preparation clocks, evidence capture and an exportable preparation pack. It does not decide whether a case is legally reportable, submit to ENISA or a CSIRT, or certify CRA compliance.
Primary sources
Sources used for this article
Continue the job