CRA reporting is designed to accommodate information that develops during an investigation. Manufacturers can update an open notification before the Final Report is submitted. The SRP alerts the coordinating CSIRT and relevant recipients when submitted notification information is updated.
Submitted Notifications Can Be Updated
ENISA's current SRP guidance provides an Update an Existing Notification workflow for both actively exploited vulnerabilities and severe incidents. An Assigned Representative can open an existing notification and change the necessary fields under the Notification tab. This is important because the CRA reporting sequence begins quickly, while product-security investigations can continue for days or weeks. Information submitted during an early warning or 72-hour stage may therefore need to be refined as the affected versions, technical cause, impact, exploitation evidence or mitigation status become clearer.
- Updates are supported for actively exploited vulnerability notifications.
- Updates are supported for severe-incident notifications.
- Open the existing notification rather than automatically creating a duplicate case.
- Update the fields that need to reflect the developed evidence.
The Notification Must Still Be Open
ENISA lists several preconditions for an update. The Assigned Representative must have Active user status and be logged into the SRP. A notification must already have been submitted or saved as a draft. The notification must not be closed, because closed notifications cannot be updated. The Final Report must also not already have been submitted. These controls mean the manufacturer should review developing facts before the regulatory case reaches its final non-editable state.
- The AR user must be Active.
- The notification must exist as a draft or submitted notification.
- Closed notifications cannot be updated.
- A submitted Final Report makes the notification non-editable.
Use Update for Changed or Better Information
The update function is useful when previously submitted information needs correction, clarification or development. For example, the manufacturer may identify additional affected versions, refine the known exploitation path, update the incident assessment, change mitigation information or correct a factual field. The goal should be to keep the regulatory case aligned with the best available evidence. Internal records should identify what changed, why it changed and which technical or investigative evidence supports the revision.
- Correct factual errors when identified.
- Add developed technical information.
- Update scope and affected-version information.
- Update mitigation and corrective-measure status.
- Preserve an internal record explaining material changes.
Mandatory Fields Still Apply During an Update
The SRP continues to validate mandatory information when an update is submitted. ENISA states that if required data is omitted and the AR selects Update, the platform returns an error identifying the missing data. A correction should therefore not accidentally remove information required for the current reporting state. Reporting teams should review the complete form rather than concentrating only on the single field they intended to change.
- Review mandatory fields before selecting Update.
- Do not remove required information accidentally.
- Resolve SRP validation errors before completing the update.
- Keep the updated regulatory record internally traceable.
The SRP Alerts Regulatory Recipients
When an existing notification is updated, ENISA states that the SRP automatically notifies the CSIRT Designated as Coordinator by alert and email. ENISA and any concerned CSIRTs that previously received the notification through dissemination are also notified. The update is therefore not merely a private change in the manufacturer's dashboard. It becomes part of the regulatory information flow associated with the existing CRA case.
- The coordinating CSIRT receives an update alert.
- ENISA is notified.
- Previously concerned CSIRTs are notified where applicable.
- Treat submitted updates as regulatory communications.
Do Not Create a New Notification Just to Correct an Existing Case
Where the underlying actively exploited vulnerability or severe incident is the same regulatory case, the existing notification should remain the central case record unless current ENISA instructions or the coordinating CSIRT direct otherwise. Creating unnecessary duplicate notifications can fragment the reporting history and make it harder to understand which early warning, 72-hour notification and Final Report belong together. The SRP update function exists specifically so developing information can be maintained within the existing case.
- Keep one regulatory case coherent across reporting stages.
- Use the existing notification's update function for developing information.
- Avoid unnecessary duplicate notifications.
- Preserve the relationship between early warning, 72-hour stage and Final Report.
Final Report Submission Changes the Position
ENISA's current guidance states that once the Final Report has been submitted, the notification becomes non-editable. A closed notification likewise cannot be updated. This makes the Final Report a meaningful control point in the reporting lifecycle. Before submission, the reporting owner should therefore verify the developed technical findings, mitigation details, severity or impact information and other final-report content with the relevant teams. Current ENISA self-service guidance does not describe ordinary editing of a submitted Final Report through the AR interface.
- Review the case carefully before Final Report submission.
- A submitted Final Report makes the notification non-editable.
- Closed notifications cannot be updated.
- Do not assume a submitted Final Report can be edited like an earlier notification stage.
Maintain an Internal Change Log
A manufacturer should maintain an internal change log alongside the SRP case. The record can identify the notification ID, original submission time, field changed, previous understanding, updated understanding, supporting evidence, person approving the change and update submission time. This is especially useful where the investigation evolves quickly or multiple Assigned Representatives work on the same case. It creates a defensible history of how the manufacturer kept its Article 14 reporting aligned with the evidence available at each stage.
- Record the SRP notification ID.
- Record material corrections and updates.
- Record why each material change was made.
- Record supporting technical evidence.
- Record the AR and time of each submitted update.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.