On 11 September 2026, Article 14 of the Cyber Resilience Act becomes binding. That is five weeks from today. It arrives well ahead of full application in December 2027, and it does not wait for your product to go through conformity assessment. From that date, if a vulnerability in your product is actively exploited, you have 24 hours.
We have already covered when the duty begins, which events are in scope, the full set of timelines, and the data fields ENISA's platform collects. This post assumes you have read the obligation and asks a different question. If it happened this Saturday at 02:00, what would actually occur inside your company?
In our experience the gap is rarely the regulation. Compliance managers can recite 24, 72, and 14. The gap is procedural. Nobody has decided who is woken up, who has the authority to file before legal has reviewed it, or which CSIRT the report even goes to. Those questions take minutes to answer in August and they take hours you do not have during a live exploitation event.
So run the drill.
The scenario
It is Saturday, 02:00. A customer's security team emails your support alias with packet captures showing an attacker using an unauthenticated command injection in your device's web interface to gain shell access on their network. The evidence is credible. The product is in scope, it has been on the market since 2027, and the vulnerability is real.
Work through the following in order. Write down the answer, or write down that you do not have one, which is the useful outcome.
Stage 1, the trigger
Has the clock started?
Both Article 14 timelines start when the manufacturer becomes aware. Not when the engineer on call reads the mail on Monday. Not when it is escalated to management. The regulation binds the manufacturer, and a report landing in a monitored support alias at 02:00 on Saturday is arguable awareness at 02:00 on Saturday.
Is this actually an Article 14 event?
Two things trigger the duty. An actively exploited vulnerability contained in the product, and a severe incident having an impact on the security of the product. Actively exploited has a specific meaning, which is that there is reliable evidence a malicious actor has exploited the vulnerability in a system without the permission of its owner.
This scenario qualifies. Change one fact and it stops qualifying. If your own researcher had found the same command injection in testing and no exploitation had occurred, it would be a serious bug handled under Annex I Part II vulnerability handling, and Article 14 would not be engaged at all. That boundary between exploitable and exploited is the one most often got wrong, and we have written about the distinction in detail.
Drill question. Does your support alias have a documented rule that distinguishes an exploitation report from an ordinary bug report, and does the person reading it at 02:00 know that rule?
Stage 2, the 24-hour early warning
You now owe an early warning within 24 hours, so by 02:00 Sunday.
Who files it?
Name the person. Then name the backup, because the first person may be on a flight. Then confirm both have credentials to the reporting platform that were tested before the incident rather than created during it.
Where does it go?
This is where most drills stop dead. The report goes simultaneously to two recipients. The CSIRT designated as coordinator of the Member State where your company has its main establishment, and ENISA. Both, at the same time.
Main establishment is where your cybersecurity-related decisions are predominantly taken. If that is genuinely unclear, the fallback is where the largest number of your relevant employees sit. A manufacturer with no establishment in the Union reports instead to the CSIRT of the Member State where its products are most made available.
Drill question. Write down the name of your coordinator CSIRT. If you cannot write it from memory, you have found a gap, and it is a gap that costs you hours at 03:00 on a Sunday.
Submission runs through the single reporting platform ENISA operates under Article 16, with national electronic notification end-points feeding it.
Stage 3, the 72-hour notification
By 02:00 Tuesday you owe a fuller vulnerability notification. It carries general information about the product, an initial assessment of the vulnerability, and any corrective or mitigating measures taken or available. It also asks how sensitive the information you are supplying is.
Drill question. Can you produce, within 72 hours and while also fighting the fire, an accurate description of which product versions are affected? That answer comes from your SBOM and your product records. If it would take you three days to work out which firmware builds contain the vulnerable component, the 72-hour deadline is already unreachable, and the fix for that is inventory work you do now rather than reporting work you do then.
Stage 4, the final report, and the trap
Here is the detail that catches experienced people, so read it twice.
For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available.
For a severe incident, the final report is due within one month after the 72-hour incident notification.
Two different anchors. The vulnerability clock hangs off the availability of a fix. The incident clock hangs off the earlier notification. Swapping them is the single most common error we see, and it is easy to see why. Both look like "the last stage", so people file one rule for both.
If your Saturday event is exploitation of a vulnerability and you ship a patch on 30 September, your final report is due by 14 October. It is not due one month after your 72-hour filing.
Drill question. Which of the two anchors applies to the scenario above, and what date does it give you?
Stage 5, the users
Article 14 is not finished when the authorities have been told.
After becoming aware, you must inform the impacted users, and where appropriate all users, without undue delay, about the event. Where necessary that includes telling them about risk mitigations and corrective measures they can deploy themselves. If you fail to do it, the CSIRT or ENISA can require you to.
Drill question. Do you have a route to contact your users that does not depend on a distributor forwarding a message? For a company selling through resellers, this is frequently the weakest link in the whole chain, and it is worth discovering in a drill.
What failure costs
Article 14 failures sit in the top penalty tier, alongside Annex I breaches. That reaches fifteen million euro or 2.5 percent of worldwide annual turnover, whichever is higher.
We are not going to dress that number up. The realistic risk for a mid-sized manufacturer is not a maximum fine on day one. It is a market surveillance authority that asks for your reporting records and finds you had no process, and everything that follows from that. The number matters because it tells you how seriously the legislator treated the duty, and the reporting duty is the one arriving first.
The two-hour version
If you do nothing else before 11 September, do this.
- Write down your coordinator CSIRT, and the fallback logic that got you to it.
- Name the person who files, and their backup, and check both have working platform credentials.
- Write the rule that tells a support-alias reader that a report is exploitation rather than a bug.
- Confirm you can list affected product versions inside 72 hours.
- Write down both final-report anchors, on one page, in the two lines above.
- Confirm you can reach users without a distributor in the path.
Six answers. Most companies can produce four of them today and discover the other two are nobody's job.
Where to go from here
If the drill surfaced gaps in the regulation itself rather than in your process, our free CRA certification course covers Article 14 in full as one of eight modules, including both reporting timelines, the recipients, and the boundary against Annex I Part II. It is graded by exam and carries a verifiable certificate, it takes about five hours, and it costs nothing. The course is foundational and unproctored, and we say so plainly.
If the gaps were procedural, start with what is externally visible about your company today. Our exposure scanner checks whether you publish a security.txt and a disclosure policy, which is the route a finder uses to reach you before an authority does. And if you are not certain the CRA applies to your product at all, or which class it falls into, the classifier answers that in a few minutes with no account.
Five weeks is enough time to close every gap in the list above. It is not enough time to start on 10 September.