11 September 2026: the three things nobody has ready

The day after, not the day itself

The Regulation's calendar is staggered and we have laid it out on the dates page; here only one thing matters. The reporting duty produces nothing on 11 September. It produces from the 12th, when the first real report arrives and your process either exists or does not.

And it is a different kind of deadline from the ones product conformity trains you for. There is no document to hand in by a date, no inspector coming round. There is an event that arrives when it arrives, and finds you as you are.

The counterintuitive part

The practical consequence catches many off guard. You can be very far from product conformity — no CE marking, no complete technical file, no finished secure-development process — and still be sanctionable, today, for a report you did not file. The two things are decoupled. Compliance of the object and compliance of the reporting duty run on separate clocks, and the reporting clock starts first.

And a product placed on the market years ago is not exempt. If it is still supported and a vulnerability in it is being actively exploited, the reporting obligation applies to it exactly as it would to a product shipped tomorrow. The date the product left the factory does not enter the calculation; the moment the company becomes aware of the exploitation does. See the definition of an actively exploited vulnerability in the glossary.

The clock starts on an event you do not control

From 12 September 2026 — the day after the obligation takes effect — a manufacturer who becomes aware of an actively exploited vulnerability in its own product has twenty-four hours to file the early warning with the designated CSIRT and with ENISA. Not twenty-four working hours. Not twenty-four hours from when someone reads the email. Twenty-four hours from when the company, as an entity, becomes aware of the fact.

That distinction is the whole game. "The company became aware" is judged from the outside, on the timestamp of the message that arrived, not on the internal history of who forwarded it to whom. This is why the problem is organisational before it is technical: the deadline is triggered by an event you do not control and starts running while, quite possibly, no one is looking.

23:40 on a Saturday

Make it concrete. A security researcher emails your public address at 23:40 on a Saturday: your firmware carries a flaw and there is a proof that it is being exploited in the field. Your twenty-four hours end at 23:40 on Sunday. Nobody is in the office. The engineer who understands that firmware is at a wedding. The inbox is monitored, in practice, on Monday at nine.

By Monday at nine you are already thirty-three hours in and nine hours late, and the lateness has nothing technical about it. You did not lack the competence to write the early warning — it takes minutes. You lacked someone assigned to see the message, a written rule to decide whether it qualifies, and a way to reach the person who could confirm the exploitation. Every company we have seen in trouble had a competence they could rely on and an availability they could not.

Three things almost no one has ready today

Reduce the Saturday-night scenario to the three things that would have made it a non-event. A staffed intake channel: a single public address for reports, one that someone is responsible for watching outside office hours, not a mailbox that fills up until Monday. A written qualification rule: who decides whether an inbound report describes an actively exploited vulnerability, on what criteria, and how the reasoned "no" is recorded — because an implicit "no" is not a defence. An on-call chain: named people, hourly thresholds and substitutes, so that at 23:40 there is always someone reachable who can confirm and file.

These three are the minimum, not the whole obligation set. The full text of Art. 14 adds the 72-hour notification, the final report, the notice to users and the upstream reporting to component maintainers — each with its own deadline. But without the intake channel, the qualification rule and the on-call chain, none of the rest gets a chance to work, because the first real report will already have gone unanswered.

Add two administrative prerequisites that run on timelines not your own: the EU Login credentials to reach the reporting platform and the designation of the contact point to the national CSIRT. Requesting them on the night of the emergency means arriving late for a reason that, again, is not technical.

What happens after the first filing

The early warning closes nothing: it opens. The 72-hour notification and the final report remain, each with its own content, and meanwhile the event keeps evolving. This is where improvised processes break the second time: almost everyone manages the first filing; the second falls due while the company has already gone back to its business.

And the final deadline is not one deadline. For an exploited vulnerability it is anchored to the corrective measure plus fourteen days; for a severe incident, to the incident notification plus one month. Applying the first to a case of the second kind misses the deadline by weeks, and the error only shows at the end.

So the thing to prepare is not the early warning, which is short. It is the calendar that starts with it, and the person who carries it to the end.