On 11 September 2026, the reporting obligation of Regulation (EU) 2024/2847 enters into application. What follows sets out what it asks at each stage, and where the effort actually lies.
What starts the clock
The obligation arises from two events: an actively exploited vulnerability contained in a product with digital elements, or a severe incident having an impact on its security. The Commission FAQ lists the channels through which a manufacturer may become aware of one — a customer report, threat intelligence, internal monitoring, a security researcher — and states that these reporting obligations do not require a manufacturer to carry out such activities or monitor such channels.
What follows describes the vulnerability track. The severe-incident track keeps the same rhythm — 24 hours, 72 hours, final report — with its own fields, and its final report is due within one month of the notification rather than fourteen days after the fix.
A vulnerability discovered without reliable evidence of malicious exploitation falls outside Article 14. A report from a bug bounty programme, or a laboratory finding, belongs to the voluntary reporting of Article 15 for as long as no exploitation is established. The dividing line is evidence of exploitation, not severity.
Three stages, and one starting point that moves
Reporting happens in three steps: an early warning notification at 24 hours, a notification at 72 hours, and a final report. The first two deadlines run from the moment the manufacturer becomes aware of the reportable event.
The third does not start in the same place. The fourteen days of the final report are counted from the date a corrective or mitigating measure is made available, not from the date of detection. A manufacturer counting those fourteen days from discovery would be working to the wrong calendar, one way or the other.
At 24 hours, five fields
In question 16 of its frequently asked questions, ENISA — the European Union Agency for Cybersecurity — publishes the table of fields the platform expects, coded stage by stage. At the early warning stage, only five fields are marked mandatory: the notification type, its level, the manufacturer or open-source software steward, the product and a title. The Member States concerned appear there as a conditional field.
Neither a CVE identifier — the public number assigned to a vulnerability in the international register — nor a severity score of the kind the Common Vulnerability Scoring System produces is required. The duty at this first stage is to notify, not to complete the analysis. Of those five fields, only one calls for writing: the title. The other four are data already held, or filled in by the platform itself.
The real burden lands at 72 hours
Five fields that were optional at the first stage become mandatory at the second: general information about the product concerned, the general nature of the vulnerability, the general nature of the exploit, the corrective or mitigating measures taken, and those users can take. A sixth — how sensitive the manufacturer considers the notified information to be — is marked mandatory as soon as the manufacturer has formed a view on it. None of them can be filled by automatic extraction. Every one calls for a human decision.
The consequence is direct: these are precisely the items to settle before the clock starts. Discovering them during the 72 hours, with an incident under way, is the expensive scenario — and it is what happens in an organisation that has prepared itself to detect without preparing itself to decide.
Three cases that are easily missed
- Older products are covered. The obligation applies from 11 September 2026, including to products placed on the market before the other obligations enter into application on 11 December 2027, by way of the derogation in Article 69. The Commission adds that a manufacturer may be materially unable to investigate an older product — tooling gone, team dispersed — without that exempting it from notifying.
- A vulnerability inherited from a third-party component is reported twice. The manufacturer of the final product notifies, and the manufacturer of the component notifies as well, where that component is itself placed on the market separately.
- The recipient may delay dissemination. Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 specifies the terms and conditions for applying the grounds on which a receiving CSIRT — a computer security incident response team — may delay or withhold the dissemination of a notification: sensitivity of the information, compromise of the platform, insufficient capacity at the CSIRT.
What is not yet in place
That has a practical consequence: the reporting tool opens on the very day the obligation begins. Nobody will have used it under real conditions before the deadline.
What remains to be prepared
Three things, in this order. Know which components go into each product shipped, without which the question “are we affected by this vulnerability” has no quick answer. Name the person who writes the five judgement fields of the 72-hour stage, and decide it now rather than during the incident. And separate, among the reports received, those that carry evidence of exploitation from those that do not: that split is what divides a 24-hour obligation from a voluntary notification.