On 11 September 2026, the reporting obligation of Regulation (EU) 2024/2847 enters into application. For anyone preparing for it, one question comes before all others: what exactly will be asked of you?
The answer fits in a form of 26 fields. Five carry information you already hold today, with no incident having occurred. Seven will have to be written during the incident, against the clock. Six more are due only in the final report. The last eight ask nothing of you, or are mandatory at no stage.
The form exists, the Regulation does not describe it
Using the platform is not a convenience offered to manufacturers: it is the channel the Regulation imposes.
A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA. The manufacturer shall notify that actively exploited vulnerability via the single reporting platform established pursuant to Article 16.
Two acronyms, once and for all. A CSIRT is a computer security incident response team; each Member State designates one as coordinator. ENISA is the European Union Agency for Cybersecurity. You do not write to them separately: you file one notification on a single platform, which distributes it.
What that filing must contain, however, the Regulation barely states. At twenty-four hours, it names a single piece of information.
an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it, indicating, where applicable, the Member States on the territory of which the manufacturer is aware that their product with digital elements has been made available;
One item named, and even then qualified: “where applicable”. The ENISA form, for its part, codes five mandatory fields at that same stage. The gap is not concealed — the Agency states it in the sentence introducing its table.
The table below explains the fields that will be obligatory (stemming directly from CRA or identified by logical consequence) or optional at each stage of reporting.
Part of what the form treats as mandatory therefore comes not from the legal text but from a deduction the Agency made to render the form usable.
The Regulation did provide for that format to be settled in law. It made it an option, not a duty.
The Commission may, by means of implementing acts, specify further the format and procedures of the notifications referred to in this Article as well as in Articles 15 and 16. […]
An implementing act is a text the Commission adopts on its own, without a new legislative procedure, to set out how a regulation applies in practice. Here the operative word is “may”: no deadline is attached to it, and no act of that kind had been adopted by mid-August 2026. One confusion is worth avoiding, since the two texts are often cited side by side: Delegated Regulation (EU) 2026/881 of 11 December 2025 does exist, but it is based on the preceding paragraph and does not govern the content of notifications. It sets out the cases in which the receiving CSIRT may delay their dissemination.
The 26 fields, by when the information exists
ENISA sorts the fields by stage: what is due at 24 hours, at 72 hours, then in the final report. That is the right ordering for filling the form on the day. It is the wrong one for preparing, because it does not say which of those fields you could complete right now. Here is the other cut.
Six fields out of twenty-six ask nothing of you at all: two are picked within the form, four are filled by the platform without even being shown to you. Two more are mandatory at no stage. Five carry information you already hold, but which has to have been gathered once. That leaves thirteen fields to produce: seven during the incident, six in the final report.
The five fields you can prepare today
These five depend on no incident. They describe who you are and what you make available.
- The name of the manufacturer, or of the open-source software steward. The form provides for both, because the Regulation creates that second status for legal persons providing sustained support to free and open-source software intended for commercial activities.
- The product concerned: the name under which you make it available.
- The product type — default, important or critical. The Regulation ranks products by criticality, and one very concrete thing follows from that ranking: will you have to have your conformity validated by an external body, or may you assess it yourself? Most products fall under the default regime. This is settled cold, never during an incident.
- The product category, if you are not in that default case. The lists are in Annexes III and IV to the Regulation: Annex III enumerates so-called important products — browsers, password managers, operating systems, routers, firewalls, among others — and Annex IV so-called critical products, such as smart meter gateways and smart cards.
- The Member States where the product is available. This is the only one of the five that the Regulation names explicitly at the 24-hour stage, and the table marks it “obligatory if such information available”.
Two further fields are simple choices within the form, with nothing to prepare: the notification type — vulnerability or incident — and the level, meaning the stage you are at. Four others are filled by the platform and are not even shown to you: the dates and times at which each of the three stages is recorded, and the identity of the person filing.
At 24 hours, one field to write
Of the five mandatory fields in the early warning notification, four are those just described, or the two choices to make within the form. The fifth is a title — the only one that calls for writing a sentence.
This first stage is not a report. It signals that something has happened; it does not require that you have analysed it. The severity of the vulnerability is expected only in the final report, and the form imposes no way of measuring it: nowhere does it ask for a score computed against a scale, of the kind the CVSS standard produces.
One detail of the table is worth flagging, because it often surprises. The CVE identifier — the public number assigned to a vulnerability in the international register — and its European counterpart, the EUVD identifier, are mandatory at none of the three stages, the final report included. You therefore never have to wait for a number to be assigned before notifying.
At 72 hours, five fields that demand a decision
This is where the load shifts. The Regulation describes the second stage as follows.
unless the relevant information has already been provided, a vulnerability notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability, which shall provide general information, as available, about the product with digital elements concerned, the general nature of the exploit and of the vulnerability concerned as well as any corrective or mitigating measures taken, and corrective or mitigating measures that users can take, and which shall also indicate, where applicable, how sensitive the manufacturer considers the notified information to be;
From this the form derives five distinct fields, all of which move from optional to mandatory: general information about the product concerned; the general nature of the vulnerability; the general nature of the exploit; the corrective or mitigating measures you have taken; those your users can take themselves. The number of mandatory fields thus goes from five to ten between the first stage and the second, the five from the early warning still being required, copied over or updated.
Two words of the Regulation are worth weighing, because they set the level of detail expected: this information is “general”, and it is requested “as available”. You describe what you know at that point — what kind of weakness it is, how it is being used, what you have already done. The full description belongs to the final report, not here.
A sixth field appears at this stage without being quite mandatory: how sensitive you consider the notified information to be. The table marks it “obligatory if such information available” — an intermediate category meaning that if you have formed a view on the sensitivity of what you are transmitting, you must declare it. That judgement is not without consequence. The Regulation provides that, in exceptional circumstances and “in particular, upon request by the manufacturer”, having regard to the sensitivity it has indicated, dissemination of the notification may be delayed “on justified cybersecurity-related grounds”. Delegated Regulation (EU) 2026/881 sets the conditions for that delay, and they go beyond sensitivity alone: the CSIRT must establish that the risks of dissemination outweigh its benefits.
Note the mechanism: the delay is not triggered by your ticking “sensitive”. It is requested.
None of these fields can be extracted from a tool. Each requires someone to decide, and to stand behind it. “The general nature of the exploit” is not a value to be queried: it is a sentence addressed to a public authority, seventy-two hours after discovering the problem, often before having fixed it.
What is due only in the final report
The last stage does not start at the same moment as the first two, and its content is the only one the Regulation enumerates precisely.
unless the relevant information has already been provided, a final report, no later than 14 days after a corrective or mitigating measure is available, including at least the following: (i) a description of the vulnerability, including its severity and impact; (ii) where available, information concerning any malicious actor that has exploited or that is exploiting the vulnerability; (iii) details about the security update or other corrective measures that have been made available to remedy the vulnerability.
Six fields become mandatory at this stage, and only at this stage: the full description of the vulnerability, its severity, its impact, details of the security update, and — where the information exists — the identity of the malicious actor that exploited it. The form offers them from the two earlier stages as optional entries: nothing stops you from filling them in sooner, if you already know them.
The sixth is the one to watch, because it drives a clock: the date on which the corrective or mitigating measure was made available. The fourteen days of the final report do not run from your discovery of the vulnerability, but from that date. The field does not merely record a fact: it sets the starting point of your last deadline.
What to have done before 11 September 2026
Three actions, none of which depends on a tool or on the platform going live.
- Fill in the five cold fields once, for every product you make available — and plan to keep them current. The longest of the five is the list of Member States where the product is available: go country by country, including those you reach through a reseller or a marketplace, which are the easiest to forget. That list is hard to reconstruct under pressure.
- Name the person who writes the five fields of the 72-hour stage. Not a team: one person, and a deputy. These fields commit the company before a public authority, and the moment to choose their author is not the moment the clock is running.
- Settle in advance what you will treat as sensitive information, who makes that call, and who will request a delay if you judge that immediate dissemination would increase the risk. It is the quietest field in the table, and the first lever left in your hands once the notification is filed.
These three actions bear on what you know about your products and on who decides within your organisation. None of the three is improvised in twenty-four hours, and none depends on a text still to come.