Nine Weeks to 11 September: Dry-Run Your Article 14 Reporting Before It Counts

As of this week, just over nine weeks remain until 11 September 2026, the day Article 14 of the Cyber Resilience Act starts to apply. From that date, a manufacturer that becomes aware of an actively exploited vulnerability or a severe incident affecting one of its products has 24 hours to submit an early warning — with fines for Article 14 failures reaching EUR 15 million or 2.5% of worldwide annual turnover (Article 64(2)).

We have covered what the deadline requires and how the reporting clocks work in detail. This post is about the last mile: testing the process before the regulation does. A reporting workflow that exists only as a document is a hypothesis. Nine weeks is enough time to run a full dry-run, find out where the hypothesis breaks, and fix it — twice, if you start now.

First, Be Honest About Scope

Two facts determine how big your day-one exposure is, and both are commonly misread:

The obligation covers your installed base. Article 69(3) applies the Article 14 duties to all in-scope products placed on the market before December 2027 — not just new releases. The product you shipped in 2021 and still support is reportable from 11 September. Your dry-run scenario should therefore be drawn from your oldest widely deployed product, not your newest: that is where the awareness signals are weakest and the version records are messiest.

The triggers are two, and they are defined. You report an actively exploited vulnerability — one where there is "reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner" (Article 3(42)) — and you report a severe incident having an impact on the security of the product, where "severe" means it affects (or can affect) the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or it has led (or can lead) to the introduction or execution of malicious code in the product or in users' systems (Article 14(5)). Neither trigger waits for a patch, a root cause, or legal sign-off. Awareness starts the clock.

Know the Clocks You Are Rehearsing

The precise anchors matter, because two of them are routinely misquoted:

• 24 hours from becoming aware — early warning (Articles 14(2)(a) and 14(4)(a)). For a vulnerability: indicate, where applicable, the Member States where the product has been made available. For an incident: also whether unlawful or malicious acts are suspected.
• 72 hours from becoming aware — the fuller notification (Articles 14(2)(b) and 14(4)(b)): general information about the product, the nature of the exploit or incident, corrective or mitigating measures taken, and measures users can take.
• Final report — for vulnerabilities, no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)); for incidents, within one month of the 72-hour incident notification (Article 14(4)(c)). Neither final-report clock runs from awareness.
• In parallel: inform impacted users — and where appropriate all users — with mitigation and corrective measures they can apply (Article 14(8)). If you fail to do this in a timely manner, the CSIRT can inform your users for you. No manufacturer wants to learn that provision exists the hard way.

The CSIRT coordinator can also request intermediate status reports between submissions (Article 14(6)) — your process should assume the conversation continues after the 72-hour mark.

Know Where Your Report Goes

Notifications are submitted through the single reporting platform established by ENISA (Article 16), using the electronic notification end-point of the CSIRT designated as coordinator of the Member State where you have your main establishment — the place where cybersecurity decisions about your products are predominantly taken (Article 14(7)). The submission is simultaneously accessible to ENISA. You do not file separately in every country where you sell.

Resolve this before the dry-run, because it is a pure research task with no excuse for doing it at 3 a.m. during a real event:

• Which Member State is your main establishment under Article 14(7)?
• No EU establishment? Article 14(7) gives the fallback order: the Member State of your authorised representative, then of your largest importer, then largest distributor, then the one where most of your users are.
• Locate the national CSIRT's end-point on the reporting platform and confirm your team can access it. Establish accounts or credentials in advance if the end-point supports it.

The Dry-Run: A Script

Block half a day. You need a facilitator (who knows the scenario), the people who would actually play each role, and a clock that is taken seriously. Compress the timeline — one hour of exercise time per twelve of real time works well — but never pause it.

1. Inject the signal where signals really arrive. Do not open the exercise in a compliance meeting. Have the "researcher email" land in the support inbox, or the threat-intel alert fire to the security channel, and say nothing else. The first thing you are testing is whether the organisation notices — and how long the signal takes to travel from first contact to someone empowered to act. That handoff time is dead time inside your 24 hours.

2. Force the classification decision. The scenario should be deliberately ambiguous: exploitation "reported by one customer, unconfirmed", or an incident whose severity under Article 14(5) is arguable. Watch who makes the call, on what criteria, and whether they know the definitions well enough to defend the decision. Write the decision and its justification down — in a real event that record is your evidence of when awareness crystallised.

3. Draft the early warning against the clock. Using your template (you have one, or this step will create the case for it): manufacturer identity, product and affected versions, nature of the event, Member States where the product is available, suspected malicious action for incidents. The content is deliberately minimal — the exercise tests whether you can assemble even minimal facts fast. Which versions are affected? If answering that means grepping build servers, you have found your first gap; this is exactly the question a current SBOM archive answers in minutes.

4. Draft the 72-hour notification. Now the harder questions: what do we know about the exploit, what mitigations exist right now, what can users do today? If the honest answer is "nothing yet", the notification still goes out — Article 14 requires the information "as available", not a finished story.

5. Run the user-notification drill. Draft the Article 14(8) message to impacted users: what happened, who is affected, what to do now. Then answer the operational question most teams cannot: do we actually have a channel that reaches the affected users of this specific product and version? An email list that covers 40% of the installed base is a finding.

6. Debrief the same day. For each checkpoint record: time consumed, information that was missing, decisions that stalled, single points of failure (one person, one laptop, one credential). Rank the gaps by what breaks the 24-hour deadline first.

What Dry-Runs Typically Expose

Having watched this exercise across many teams, the recurring findings are remarkably consistent:

• The awareness funnel is the bottleneck — signals sit in support queues for days because no triage rule says "escalate anything that smells like exploitation".
• Nobody can produce the affected-version list quickly for older products.
• The classification decision has no named owner outside business hours.
• Templates exist but reference the wrong recipients — reports drafted "to ENISA" with no idea which national end-point applies.
• User notification is aspirational — the channel reaches new customers, not the installed base.

Every one of these is fixable in a fortnight. None of them is fixable inside 24 hours.

The Remaining Weeks

A realistic plan from here: run the first dry-run within two weeks, spend three weeks closing the gaps it exposes, and run a second, harder scenario (out-of-hours injection, key person "on leave") in late August. Teams that do this twice before 11 September will treat their first real Article 14 event as a rehearsed procedure. Teams that do not will improvise one under a deadline measured in hours, in front of a regulator.

How Seentrix Fits In

Seentrix's incident workflow is built to be rehearsed. You can open a drill incident against a real product, watch the 24-hour, 72-hour, and final-report deadlines count down from the awareness timestamp, and draft each submission from templates pre-filled with the product, version, and vulnerability data already in the platform — then archive the drill with its timing record as evidence that the process was tested.

The dry-run itself, though, is an organisational exercise, and the clock finds organisational gaps no tool can close: who notices, who decides, who is reachable in August. Run it while the deadline is still nine weeks away instead of 24 hours.