Guide indépendant du règlement (UE) 2024/2847 · Statut : en vigueur
Cette page est une traduction automatique (IA) qui n'a pas été révisée par un humain. Les articles du blog ne sont disponibles qu'en anglais.
← All news
Analyses CRA9 septembre 2026

ENISA's New Guidance Confirms the Disclosure Delay Is for Vulnerabilities Only, and That the CSIRT Decides

ENISA's New Guidance Confirms the Disclosure Delay Is for Vulnerabilities Only, and That the CSIRT Decides

Two days before reporting starts, ENISA published a fifth guidance page for the Cyber Resilience Act's plateforme de notification unique. It covers Particularly Exceptional Circumstances, the mechanism most often described as the manufacturer's ability to hold back a vulnerability report, and it is the first document to show the screen and state the limits. Two of those limits change how the mechanism should be described.

Status at publication, 9 September 2026

The Single Reporting Platform is pas encore en service and its public URL has still not been published, two days before the obligation starts. ENISA says the URL will appear on its SRP hub before go-live and that the platform is scheduled to be operational from 11 septembre 2026. Voluntary reporting under Article 15 will not be available at launch, and there is no reporting API in the initial release.

It applies to vulnerabilities, and not to incidents

ENISA states it without qualification: PEC is only applicable when a manufacturer or open-source software steward submits a 72-hour notification of an actively exploited vulnerability. Il n'existe pas d'équivalent pour un incident sévère, and no PEC control appears on an incident notification.

The clue was already in the field table. When ENISA published version 1.1 of its Glossaire SRP on 5 septembre 2026, the PEC fields sat under the actively exploited vulnerability heading and had no counterpart in the severe incident block. What was implicit in a table is now explicit in a sentence, and it matters because the two duties are frequently described together. If your incident runbook assumes you can restrict what ENISA sees about a severe incident the way you can for a vulnerability, that assumption is wrong.

The logic holds on reading l'article 16(2), whose three conditions are all written about a notified vulnérabilité. The platform is following the text.

Invoking PEC is a request, not a switch

Mechanically it is simple. In the 72-hour template you scroll to the foot of the form and toggle the PEC indicator, which reveals the three delay reasons as checkboxes and an optional free-text field. The record then moves to the state 72h Submitted under PEC.

The free-text field is where the guidance is more interesting than it first appears. ENISA describes it as information that can help the CSIRT désigné comme coordinateur decide whether to accept the submission under PEC. So the toggle does not apply a restriction; it asks for one. The coordinator remains responsible for deciding whether dissemination is necessary and possible, and for passing the full notification to ENISA and to other concerned CSIRTs manually.

That reframes the drafting task. An optional box a busy reporter might leave empty at three in the morning is the argument on which the request turns. Write it for someone weighing it against the case for warning other Member States quickly, and name the specific harm.

What it does not do

It does not touch your deadlines. The 24-hour, 72 heures and final-report windows run from awareness and nothing pauses them, PEC included. What PEC affects is how much of the content reaches ENISA, and when: where it is invoked, ENISA receives only the limited information Article 16(2) allows until the coordinator releases the full notification.

It is also distinct from the delay the receiving CSIRT may apply on its own initiative under Commission Delegated Regulation (EU) 2026/881, adopté le 11 décembre 2025. That is the coordinator's decision about onward dissemination to other Member States. PEC is your flag on the content of one notification. The two are often merged in summaries, and they are different things with different decision-makers. Our guide de notification sets out both.

A note on ENISA's dates

One practical warning for anyone maintaining an internal procedure. Between 7 et 9 septembre 2026 ENISA also rewrote the AR Notification submission and update guidance while leaving its stamp reading 3/08/2026. The changes are not cosmetic: the terminology moves to CDaC throughout, references to a national endpoint data layer disappear, submission confirmations now go to chaque assigned representative of the manufacturer rather than only the person who filed, and the early warning is now expressly said to reach other concerned CSIRTs only after manuelle dissemination.

We have previously suggested recording the "last updated" stamp beside anything you copy into a runbook. That advice now needs a caveat: the stamp is not a reliable version marker. Keep your own dated copy of the text instead.

What to do with this

  • Decide, before you need it, who is authorised to invoke PEC and on what basis. It is a legal judgement about one of three narrow conditions, not an incident-response reflex.
  • Draft the justification wording now, in the same document as your 24-hour skeleton, since the platform's own field is optional and easy to skip.
  • Remove any assumption that PEC is available for severe incidents. It is not.
  • Keep filing on time regardless. Nothing here moves a deadline, and our state of play page tracks what is still outstanding.
Published 9 septembre 2026 · CRA Insights. Part of the CRA insights blog on cyberresilienceact.eu.