Particularly exceptional circumstances (PEC) under Article 16(2) of the Cyber Resilience Act (CRA) are a narrow way to flag a 72-hour notification of an actively exploited vulnerability for exceptional dissemination handling. They do not exempt the manufacturer from reporting, extend the deadline, or let the reporter decide unilaterally to suppress the notification. The computer security incident response team (CSIRT) designated as coordinator retains the dissemination decision.
ENISA's PEC guidance, updated on 12 October 2026, explains the operational control in the Single Reporting Platform (SRP). This article separates the legal grounds from the platform workflow and proposes a practical decision record. The record is an engineering recommendation, not a CRA-mandated template.
What the exception changes — and what it does not
Manufacturers have had CRA Article 14 reporting obligations since 11 September 2026. For a reportable actively exploited vulnerability, Article 14(2) requires an early warning without undue delay and within 24 hours of awareness, followed by a vulnerability notification without undue delay and within 72 hours. A final report is due no later than 14 days after a corrective or mitigating measure becomes available.
Normally, a notification reaches the coordinating CSIRT and ENISA, and the CSIRT disseminates it to other concerned national CSIRTs. Article 16(2) recognises that distributing sensitive exploit information immediately can itself create cybersecurity risk. The PEC mechanism changes how the full content is initially shared, not whether the reporting obligation exists.
| Question | PEC treatment | |---|---| | Can the reporter invoke PEC in the 24-hour early warning? | No. ENISA locates the PEC control in the 72-hour actively exploited vulnerability form. | | Does the PEC flag apply to a severe-incident notification? | No. ENISA expressly limits it to actively exploited vulnerabilities. | | Does it stop the 72-hour clock? | No. The notification still has to be submitted on time. | | Does ENISA receive nothing? | No. Article 16(2) provides for limited information to be made available simultaneously. | | Does the manufacturer decide when the full report is shared? | No. The coordinating CSIRT remains responsible for the dissemination decision. | | Is a PEC flag a general confidentiality classification? | No. It is tied to specific statutory conditions and one notification stage. |
The rules also describe open-source software stewards as possible reporters. Their corresponding CRA reporting obligations under Article 24(3) apply from 11 December 2027, not from the manufacturers' September 2026 start date.
The three Article 16(2) grounds
The third subparagraph of Article 16(2) sets out three alternative grounds. A reporter must identify at least one that is supported by the information available. A preference to avoid publicity, reputational damage or administrative work is not itself a PEC ground.
1. Exploitation confined to the coordinator's Member State
The reporter indicates that a malicious actor has actively exploited the notified vulnerability and, according to the available information, that exploitation has occurred in no Member State other than the Member State of the coordinating CSIRT.
This is an evidence-sensitive statement about known exploitation geography, not simply where the product was sold. Product availability across the EU and confirmed exploitation in a particular country are different facts. The case record should identify the incident reports, telemetry or other reliable evidence supporting the geographical assessment, as well as any uncertainty.
A lack of monitoring outside one country is not affirmative proof that exploitation is confined there. If new evidence indicates exploitation elsewhere, the team should reassess the basis of the flag and update the responsible CSIRT as appropriate.
2. Disclosure contrary to essential interests of that Member State
The reporter indicates that immediate further dissemination would likely provide information whose disclosure would be contrary to the essential interests of the coordinating CSIRT's Member State.
This is a narrow legal criterion, not a synonym for confidential commercial information. A manufacturer should identify the specific information at issue and the plausible harm from its disclosure, without assuming that an internal sensitivity label satisfies the statutory test.
The coordinating CSIRT, rather than the manufacturer, is responsible for deciding how the notification is disseminated. Where national interests may be implicated, involve the organisation's designated legal and security decision-makers promptly.
3. Imminent high cybersecurity risk from further dissemination
The reporter indicates that further dissemination of the notified vulnerability itself would create an imminent high cybersecurity risk.
An example to investigate is whether distributing precise exploitation details before containment could materially increase immediate risk. This is an illustrative assessment question, not an automatic qualification. Document the causal link between dissemination and the expected risk, the affected systems, the current mitigations, and what would change the assessment.
The presence of an unpatched vulnerability alone does not prove that this particular ground applies. The concern must be the imminent high cybersecurity risk arising from further dissemination.
How the PEC flag works in the SRP
ENISA describes a specific workflow for an assigned representative (AR) who has an active SRP account and the necessary manufacturer association.
- Complete the normal reporting stages. Submit the 24-hour early warning and open the existing case for the 72-hour vulnerability notification.
- Assess the three legal grounds. During the initial 72-hour window, decide whether any ground is supported by the available evidence. Do not wait for a complete forensic investigation if the ordinary notification deadline is approaching.
- Use the PEC indicator where justified. In the 72-hour actively exploited vulnerability template, toggle the PEC indicator and select the applicable PEC Delay Reason.
- Explain the facts. ENISA provides an optional justification field. Although optional in the interface, a concise, evidence-based explanation can help the coordinating CSIRT assess the request.
- Submit and retain the confirmation. ENISA states that the dissemination status becomes 72h Submitted under PEC. Keep the submission record, timing and selected reason.
- Follow the CSIRT's handling. The CSIRT designated as coordinator decides whether and when dissemination is necessary and possible, and handles sharing with concerned CSIRTs and the full notification with ENISA.
The flag is not a guarantee that the requested restriction will persist. Article 16(2) also provides for ENISA to recommend full dissemination where the limited information indicates systemic risk affecting security in the internal market. Reporters should therefore prepare to explain and revisit their justification as the facts evolve.
What ENISA initially receives
Where the Article 16(2) PEC conditions are invoked in the 72-hour vulnerability notification, the regulation limits the information made available simultaneously to ENISA to four categories:
- confirmation that a manufacturer submitted a notification;
- general information about the product with digital elements;
- information on the general nature of the exploit;
- confirmation that cybersecurity-related grounds have been raised.
The full notification is not simultaneously available to ENISA in this scenario. The coordinating CSIRT is responsible for subsequent dissemination of the complete information to the concerned CSIRTs and ENISA. This distinction matters when designing an internal reporting audit trail: a successful SRP submission and the eventual distribution of its full contents are separate events.
Do not describe PEC as an instruction to omit required facts from the manufacturer's submission. The mechanism concerns onward handling of information through the platform. Continue to provide the legally required notification data to the designated endpoint.
Do not confuse PEC with the delegated dissemination-delay mechanism
Commission Delegated Regulation (EU) 2026/881, adopted on 11 December 2025 and published on 20 April 2026, specifies the conditions for a coordinating CSIRT to delay onward dissemination to other concerned CSIRTs on justified cybersecurity-related grounds. That mechanism can concern notifications of actively exploited vulnerabilities or severe product-security incidents.
The PEC restriction on ENISA's simultaneous access is different. Under Article 16(2), it is triggered by the reporter identifying one of the three particularly exceptional grounds in the 72-hour actively exploited vulnerability notification. The delegated regulation explicitly distinguishes the CSIRT's delay to other national CSIRTs from the narrow restriction on ENISA's initial access.
| Dimension | PEC under Article 16(2) | Delegated Regulation 2026/881 | |---|---|---| | Main issue | Limited initial availability of full vulnerability notification to ENISA | Delaying onward dissemination to concerned national CSIRTs | | Relevant notification | 72-hour actively exploited vulnerability | Actively exploited vulnerability or severe incident | | Who exercises the key judgment? | Reporter flags a ground; coordinating CSIRT decides dissemination | Coordinating CSIRT decides whether a justified delay is necessary | | Deadline effect | No extension of Article 14 reporting deadlines | No extension of Article 14 reporting deadlines |
A manufacturer should not treat these as two interchangeable checkboxes. Record which mechanism is being considered, the relevant statutory basis, and who has authority to decide.
A practical PEC decision record
A short internal decision record helps teams demonstrate what they knew at the time and prevents a sensitive reporting choice from becoming an undocumented email exchange. The following fields are recommendations, not mandatory SRP fields.
| Record field | Example of useful evidence | |---|---| | Reporting case | SRP case identifier, manufacturer entity, coordinating CSIRT | | Awareness and deadlines | Timestamp and source of awareness; 24-hour and 72-hour due times | | Product scope | Product, variants, affected versions, available mitigations | | Ground selected | Article 16(2)(a), (b) or (c), with a factual explanation | | Evidence and uncertainty | Incident findings, known geography, risk scenario, missing facts | | Disclosure risk | What specific harm could follow immediate further dissemination | | Decision ownership | Security assessor, legal reviewer, authorised SRP submitter | | Submission evidence | Submitted data version, PEC selection, confirmation and timestamp | | Follow-up | CSIRT response, dissemination updates, reassessment triggers |
For example, an Austrian manufacturer may have reliable evidence of exploitation in Austria and no evidence of exploitation in another Member State. That is a candidate assessment under ground (a), not an automatic approval. The team must distinguish known facts from missing visibility, submit on time, and leave the dissemination decision to its designated coordinating CSIRT.
Common mistakes to avoid
Treating the exception as a deadline extension. The 24-hour and 72-hour obligations still run from awareness. Record the deadline independently of any PEC discussion.
Using PEC for every sensitive incident. ENISA's platform guidance restricts this indicator to the 72-hour actively exploited vulnerability notification. Severe incidents have their own reporting obligations and may involve the separate CSIRT-led dissemination-delay mechanism.
Assuming a toggle is an approval. The SRP records the PEC submission state; it does not transfer the CSIRT's dissemination authority to the reporter.
Claiming a geographical ground from incomplete data. Unknown exploitation outside one Member State is not the same as evidence that exploitation has been confined to it.
Forgetting affected users. Article 14(8) separately requires manufacturers to inform impacted users, and where appropriate all users, of an actively exploited vulnerability or severe product-security incident and relevant mitigation measures. A PEC flag is not a blanket waiver of that obligation.
Losing the later decision history. Retain both the initial rationale and subsequent changes in exploitation evidence, mitigations, risk and dissemination status.
Turn the exception into a controlled response decision
A reporting team needs two linked but distinct records: the technical vulnerability assessment and the legal-operational decision about dissemination. The first establishes what happened to which product and release; the second explains whether a narrow Article 16(2) ground was raised, what was submitted, and how the coordinating CSIRT handled it.
AA-sec is being built to connect product and release context, vulnerability decisions and supporting security evidence across the lifecycle. Its roadmap includes CRA Article 14 reporting workflows, which are relevant to retaining the context behind a PEC assessment, but regulatory submissions and dissemination decisions remain with the authorised reporter and competent authorities. The AA-sec platform is not a substitute for those decisions.
Final checklist
Before submitting a 72-hour vulnerability notification, verify the Article 14 deadline, identify whether any of the three PEC grounds is genuinely supported, record the facts and uncertainties, and select the SRP PEC indicator only if justified. Preserve the submission and any subsequent CSIRT communication. Reassess the ground as evidence changes, while continuing remediation, user communication and final reporting on their own tracks.
Source distinction: Article 16(2) and Article 14 set the legal obligations; ENISA's October 2026 SRP guidance describes the current interface; the tables and evidence-record suggestions above are editorial implementation guidance, not additional legal requirements.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act, Articles 14 and 16 — EUR-Lex
- CRA SRP Guidance — Particularly Exceptional Circumstances (PEC), updated 12 October 2026 — ENISA
- Commission Delegated Regulation (EU) 2026/881 on delayed dissemination of notifications — EUR-Lex
- Cyber Resilience Act — Reporting obligations — European Commission
- CRA Single Reporting Platform — Frequently Asked Questions, updated 15 October 2026 — ENISA
- CRA SRP Guidance — Assigned Representative notification submission and update — ENISA