The person who understands the exploit may not be the person allowed to submit the report. You can discover that during an incident, or put 45 minutes on the calendar and find out now. This exercise tests whether your team can get a reporting decision to somebody who can act on it.
Run the rehearsal
Find the missing handoff before a real reporting deadline
- 1Give the team a fictional signal with a fixed awareness time.
- 2Prepare the reporting decision and hand it to the backup owner.
- 3Assign every exposed gap and repeat the failed handoff.
Know which deadline you are rehearsing
Article 14 reporting applies from 11 September 2026, ahead of the CRA’s main application date of 11 December 2027. The transitional rule also brings in-scope products already placed on the market before the main application date into the reporting duties. Do not limit the exercise to your next release.
The exercise below assumes you are the manufacturer of an in-scope product. It rehearses an actively exploited vulnerability. If scope or role remains unresolved, assign that review first rather than guessing an answer to keep the exercise moving.
Sources: European Commission — summary of the CRA·European Commission — CRA reporting obligations
Use the scope guide if you have not established the product and operator role.
Minutes 0–10: give the team an incomplete signal
Create a fictional case in a separate practice workspace. Label the product, case and notes “EXERCISE”. Do not send fictional notifications to an authority or use customer exploit material just to make the rehearsal feel realistic.
Use this scenario: at 09:00 UTC on 11 September 2026, the manufacturer becomes aware of reliable evidence that a malicious actor has exploited a vulnerability in its connected gateway without the system owner’s permission. Release 3.2 is confirmed affected. Whether 3.1 is affected remains unknown. A mitigation is being tested.
Ask the team to identify the affected product, record the evidence and separate the unknown version from the confirmed one. The awareness time is fixed for this exercise; the team should not move it to the time somebody senior approves the decision.
Minutes 10–25: produce the decision and first draft
Assign a technical assessor, a person responsible for the reporting decision and a person authorised to submit. One colleague can hold several responsibilities, but the team must know who takes over if that colleague is unavailable.
For the exercise’s assumed facts, the 24-hour early-warning limit is 09:00 UTC on 12 September. The 72-hour vulnerability-notification limit is 09:00 UTC on 14 September, unless the relevant information has already been provided. Both duties require action without undue delay: these are outer limits, not recommended waiting times.
Prepare the early-warning draft and list what still needs to be established for the fuller notification. In CRA Operations, open the Actively exploited vulnerability notification assessment for the practice case. Before 11 September 2026, the live assessment correctly selects its pre-application rules. Entering a future awareness timestamp does not advance that rule clock: keep the scenario’s calculated deadlines in the exercise notes instead of expecting live reporting deadlines.
On or after 11 September, rerun the reporting assessment, submit it and compare the saved Record and Reports view with the independent calculations above. A pre-application completion cannot establish that the in-force reporting path passed. Keep that final check assigned if you are rehearsing before the date.
Sources: European Commission — CRA reporting obligations·Regulation (EU) 2024/2847 — official text
Review the reporting threshold and route before using this scenario.
Minutes 25–35: remove the usual owner
Have the usual owner stop helping. Ask the backup to find the product version, reporting decision, remaining unknowns and prepared draft. If the backup needs a private message explaining where everything is, record that as a failed handoff.
Check who will have access to the official Single Reporting Platform and which coordinating CSIRT endpoint applies. ENISA’s published guidance says the platform is due to be operational by 11 September 2026. Before that date, record any access check you cannot complete as an outstanding action; do not claim it passed.
One preparation step does not have to wait: ENISA’s 4 September FAQ says assigned representatives need an EU Login account with multi-factor authentication enabled, and can create that account in advance. Ask the intended submitter and backup to prepare their own accounts. Keep actual SRP registration and permissions as separate checks once the platform is available.
The backup should be able to explain where a real report would be sent and where its receipt would be retained. CRA Operations prepares and tracks the work. It does not submit the notification to ENISA.
Sources: ENISA — Single Reporting Platform·ENISA — SRP access and registration FAQ·European Commission — CRA reporting obligations
Minutes 35–45: turn the failures into assigned work
Finish with a short gap list. Each item needs an owner, a due date and a specific retest. “Improve reporting readiness” is too vague; “backup submits a draft to the internal approver without help from the usual owner” is testable.
Add a second exercise event: a corrective measure becomes available at 12:00 UTC on 15 September. For this vulnerability route, the final report is due no later than 12:00 UTC on 29 September unless its required information has already been supplied. A severe-incident case uses a different final-report clock: one month after the incident notification. Do not reuse the vulnerability calculation for that route.
- Ready for this scenario: the backup can locate the facts and decision, explain the deadlines and continue the draft.
- Open access gap: the real submission route or backup’s access still needs verification.
- Open decision gap: the team cannot resolve the scope, route or responsible person without more review.
Keep the exercise record and repeat the part that broke
Keep the fictional scenario, assessment Record and gap tasks together. Retest the failed handoff after fixing it. A successful rehearsal covers the scenario you supplied; it does not show that every vulnerability or severe incident will follow the same path.
You now have something more useful than a calendar reminder for 11 September: evidence of what your team can do, and named work for what it cannot yet do.
This article explains an operational approach to CRA preparation. It does not replace the Regulation, official guidance or advice for a specific product and organisation.
Not lawyer-reviewed.