At 09:10 on Monday, support forwards a message from a customer. The customer has found signs that an unknown actor exploited a flaw in the login function of your locally installed administration client. The logs look credible, but you do not yet know which versions are affected, how many customers use them or whether the vulnerability has been exploited elsewhere.
Who decides whether the signal is an actively exploited vulnerability? When did the company, acting as the manufacturer, become aware of it? And who owns the first warning to the authorities?
Those questions cannot wait for the complete root-cause analysis. From 11 September 2026, the 24-hour clock may be running while material facts are still missing.
The first CRA date is 11 September 2026
The Cyber Resilience Act is the EU regulation on cybersecurity requirements for products with digital elements. It places obligations on manufacturers that develop, or have such products developed, and market them under their name or trademark.
The regulation generally applies from 11 December 2027. But Article 14 applies from 11 September 2026. It covers the manufacturer's reporting of two different matters: actively exploited vulnerabilities in the product and severe incidents that affect the security of the product.
For both branches, the process begins with an early warning without undue delay and in any event within 24 hours after the manufacturer becomes aware of the matter. A fuller notification follows no later than 72 hours after T0. The final-report requirement then differs between the two branches.
This exercise follows an actively exploited vulnerability:
| Time | Deliverable |
|---|---|
| T0 | The manufacturer becomes aware of the active exploitation |
| No later than 24 hours | Early warning |
| No later than 72 hours | Vulnerability notification |
| No later than 14 days after a corrective or mitigating measure is available | Final report |
The exercise tests the first operational reporting route. The rest of the CRA programme sits outside this scenario.
Before the exercise: test the product, not the industry label
Do not begin with the question, “Are we a software company?” Begin with a specific product, how it is made available and your role.
Among other things, the CRA defines a manufacturer as the person or company that develops or manufactures a product with digital elements, has it designed, developed or manufactured, and markets it under its own name or trademark. Hardware, locally installed software and connected products may therefore be relevant.
SaaS is not automatically in scope. The Commission's July 2026 guidance explains that a web application accessed only through a browser is not a product with digital elements merely on that basis. Remote data processing that is necessary for a product may, however, form part of an in-scope product.
That is guidance, not the wording of the law. If the boundary is unclear, resolve it separately. The tabletop exercise can still show whether your reporting route is usable.
Tabletop: one product, one signal, five owners
Choose a locally installed B2B client that customers use to administer access to their equipment. The client is marketed under your name. A customer has sent logs suggesting that an unknown actor bypassed authentication and gained access without permission.
Bring together product, security, development, legal and user communication. Give them the same incomplete information. Name one incident lead and one owner of regulatory reporting.
Keep the group focused on the four connected decisions the organisation must make while the investigation continues. The vulnerability itself can remain unresolved during the exercise.
Decision 1: do you have reliable evidence of active exploitation?
A vulnerability is not automatically reportable under Article 14. The legal text distinguishes between a vulnerability that can be exploited and an actively exploited vulnerability.
An actively exploited vulnerability requires reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. In this scenario, the team must therefore assess the customer's logs, the affected product version and the link between the flaw and the unauthorised access.
The decision must leave a record. Note the evidence supporting the assessment, the versions that may be affected, who approved the classification and when the manufacturer became aware of the active exploitation.
Put an exact time on that awareness. The clock does not start on the day the faulty code was written. For this reporting route, the legal text ties the deadline to the manufacturer's awareness of the actively exploited vulnerability.
Decision 2: what can you stand behind after 24 hours?
The early warning must be submitted without undue delay and in any event within 24 hours after T0. It goes through ENISA's Single Reporting Platform to the coordinating CSIRT in the Member State where the manufacturer has its main establishment in the EU, and is simultaneously accessible to ENISA.
For an actively exploited vulnerability, Article 14 requires the warning, where applicable, to identify the Member States in which the manufacturer knows the product has been made available.
That is a narrow legal minimum. Your internal working draft should also make the product and version, evidence status, responsible owner and any information sensitivity easy to see. Those fields are practical preparation for the next steps. Do not present them as a complete restatement of the statutory minimum.
Can the team find the necessary market information, obtain approval from the responsible owner and submit the warning while the cause and extent are still being investigated?
Decision 3: is the 72-hour notification usable?
The vulnerability notification follows no later than 72 hours after T0, unless the relevant information has already been provided. Under Article 14, the manufacturer must provide the available information about the product, the general nature of the exploit and the vulnerability, and any corrective or mitigating measures taken. The notification must also describe measures users can take and, where applicable, state how sensitive the manufacturer considers the information to be.
The investigation may still be open after 72 hours. The notification must still be usable. If the team cannot identify the affected versions, explain the general nature of the exploitation or give users a defensible temporary action, the exercise has found a real break in the response route.
User communication runs in parallel. The manufacturer must inform affected users and, where appropriate, all users about the vulnerability and the necessary risk-mitigation or corrective measures. Article 14 does not set a separate 24-hour deadline for this information. It should not be paused merely because regulatory reporting follows its own process.
The other branch: A severe incident also requires an early warning within 24 hours and an incident notification within 72 hours. Its final report is due no later than one month after the incident notification and has different required content. Test that branch in a separate scenario.
Decision 4: correct, communicate and close the case
Reporting does not end after 72 hours. The team must follow the correction, keep users informed and be able to document what was done.
For the actively exploited vulnerability, the final report must be submitted no later than 14 days after a corrective or mitigating measure becomes available. At a minimum, it must describe the vulnerability, its severity and impact, available information about the actor that exploited it, and the security update or other corrective measures.
That makes the availability of a patch or other mitigation another important timestamp in the case. If development, support and reporting use different times or product names, the final report becomes unnecessarily difficult.
The exercise should therefore continue until the team can connect the vulnerability, affected versions, correction, user information and final report in the same trail.
Debrief: six breaks to find now
The tabletop is useful when it finds weak handovers before a real case does. Finish with six questions:
- Owner: Is it clear who can declare T0 and who submits the warning and notification?
- Product and version: Can you quickly connect a vulnerability to the affected product versions and customers?
- Market: Do you know in which Member States the product has been made available?
- Evidence: Do support, security and development have one known route for receiving, preserving and assessing signs of active exploitation?
- Reporting channel: Do the named people know how to access the Single Reporting Platform, and who can step in outside normal working hours?
- Users: Can you reach affected users with precise information about the risk, temporary measures and correction?
This is an operational checklist derived from the reporting process, not a verbatim list from the regulation. If one answer is unclear, you have found a specific task. Give it an owner and a date.
Run the exercise before 11 September
Choose one product that is likely to be in scope. Use a credible signal of active exploitation, set T0, and let the team work through 24 hours, 72 hours, user information and the final report.
Find the first handover that breaks and repair it before the clock starts in a real case.