규정 (EU) 2024/2847에 대한 독립 가이드 · 상태: 발효 중
이 페이지는 자동(AI) 번역이며 사람이 검토하지 않았습니다. 블로그 기사는 영어로만 제공됩니다.
← All news
CRA 인사이트2026년 9월 9일

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 단일 신고 플랫폼. 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 아직 가동되지 않았습니다 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 2026년 9월 11일. 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. 이에 상응하는 장치는 심각한 사고, 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 SRP 용어집 on 2026년 9월 5일, 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 제16조(2), whose three conditions are all written about a notified 취약점. 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 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시간 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, 즉 2025년 12월 11일. 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 신고 안내 sets out both.

A note on ENISA's dates

One practical warning for anyone maintaining an internal procedure. Between 72026년 9월 9일 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 모든 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 수동 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 2026년 9월 9일 · CRA Insights. Part of the CRA insights blog on cyberresilienceact.eu.