Skip to content
CRA Reporting Desk

CRA Article 14 vs CER incident notification: do you file twice?

If your organisation is a designated critical entity under the CER Directive, a 24-hour competent-authority notification can look like enough for any security incident — including one that sits in a product you manufacture. It isn't. CRA Article 14 and CER Article 15 are separate parallel reporting regimes — product SRP versus critical-entity resilience — with no provision that lets a filing under one satisfy the other.

The short version

  • No substitution: Nothing in CRA Article 14 treats a CER Article 15 notification as meeting a product SRP duty, or the reverse.
  • Different clocks: CER uses 24h initial notification + where relevant a detailed report within one month (Art 15(1)) — no 72-hour middle step. CRA uses 24h / 72h / final (14 days after a corrective measure for an AEV, or one month after the 72h notification for a severe incident).
  • Different recipients: CRA → coordinating CSIRT + ENISA via the Single Reporting Platform; CER → Member State competent authority under the CER Directive.
  • Different scope: CRA is product-centric and sector-agnostic; CER is entity-centric — Member State–identified critical entities providing essential services. In scope for one does not put you in scope for the other.
  • Cyber often means NIS2, not CER: CER Recital 9 excludes matters covered by NIS2 from CER (with a digital-infrastructure nuance). That still leaves CRA on its own path — see CRA vs NIS2.
  • In scope for both? Run both clocks, file to both recipients, and do not assume one closes out the other without confirming with counsel.

What CER Article 15 actually requires

Directive (EU) 2022/2557 (Critical Entities Resilience Directive, CER) Article 15 obliges Member States to ensure that critical entities notify the competent authority, without undue delay, of incidents that significantly disrupt or have the potential to significantly disrupt the provision of essential services. Unless operationally unable, the critical entity submits an initial notification no later than 24 hours after becoming aware of the incident, followed where relevant by a detailed report no later than one month thereafter.

Article 15(1) lists significance parameters that Member States must take into account in particular: (a) the number and proportion of users affected; (b) the duration of the disruption; (c) the geographical area affected, including whether it is geographically isolated. Where an incident has or might have a significant impact on continuity of essential services to or in six or more Member States, the competent authorities of the Member States affected notify the Commission. Article 15(2)–(4) cover content (nature, cause, possible consequences, cross-border impact), cross-Member-State single-point-of-contact sharing, and competent-authority follow-up — none of which routes a product case into ENISA's CRA Single Reporting Platform.

Application calendar: Member States had to transpose CER by 17 October 2024, with the rules applying from 18 October 2024. That entity-resilience clock is already live; it does not wait on, or replace, CRA Article 14 from 11 September 2026.

Article 14 stays on the product / SRP track

CRA Article 14 obliges manufacturers to notify actively exploited vulnerabilities and severe incidents having an impact on the security of the product — early warning within 24 hours of becoming aware, fuller notification within 72 hours, then the final report on its own trigger (14 days after a corrective or mitigating measure is available for an AEV, or within one month of the 72-hour notification for a severe incident) — through ENISA's Single Reporting Platform to the coordinating CSIRT. That duty has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)).

Clock detail for the CRA side lives in the reporting deadlines and becoming-aware guides. CSIRT routing: which CSIRT applies.

There's no CRA provision that lets a CER filing stand in

Article 14's substantive paragraphs (1 through 8) do not reference CER or treat any other Union reporting regime as an alternative route for product AEVs and severe product-security incidents. Institutional cooperation between resilience and cybersecurity authorities under CER and NIS2 does not rewrite the manufacturer's SRP duty. Treat CER and CRA as separate until you have specific guidance saying otherwise.

The trap: “we already notified the critical-entity competent authority”

Two failure modes show up in triage. First: a designated critical entity that also ships a connected product files CER Article 15 (or NIS2 Article 23 for the cyber slice) and skips the SRP because “we already ran the 24-hour clock.” Second: a manufacturer assumes that because a customer is a critical entity — or because the manufacturer supplies equipment into an essential-service environment — the customer's CER filing covers the product AEV. Entity resilience notification and product SRP reporting are different jobs.

Neighbouring traps: NIS2 Article 23 (the cyber-entity cascade most critical entities actually run for cyber incidents — still not CRA); DORA Article 19 for financial entities; GDPR personal-data breach clocks; AI Act Article 73 market-surveillance serious-incident filings; and civil Product Liability Directive compensation claims (FAQ 2.3.1 — not an SRP substitute).

Who's actually in scope for each

CRA Article 14 catches manufacturers of products with digital elements placed on the EU market — broad, sector-agnostic coverage built around the product. CER scope runs the other way: Member States identify critical entities that provide one or more essential services and operate critical infrastructure on their territory, using the sectors and subsectors in the CER Annex plus the Directive's identification criteria — not "any manufacturer of a connected product." A software company with no critical-entity designation can still have a full Article 14 duty for its products. A CER-designated utility or transport operator has no CRA duty unless it is also manufacturing a qualifying product with digital elements.

If you're in scope for both

Run both clocks from the moment you become aware, measured against each regime's own trigger test, and file to each regime's own recipient. Do not let a CER Article 15 submission stand in for your Article 14 report, or the reverse, without specific confirmation that is allowed. What you can share across both processes is your internal timeline: what you knew, when you knew it, and what you did next. The evidence log is built to capture exactly that. If the cyber slice of the same event also trips NIS2 Article 23, add that as a third track — still separate from the SRP. If personal data was also breached, add GDPR Article 33 as another track.

Questions people ask

Does filing a CER Article 15 incident notification also satisfy CRA Article 14?
No. Article 14’s substantive paragraphs do not name Directive (EU) 2022/2557 (CER) as an alternative route, and nothing in the CRA treats a CER notification as meeting an Article 14 duty. They are separate obligations to separate recipients, even when the same underlying event triggers both. Do not assume one filing closes out the other without checking with counsel.
Are the clocks the same — both have a 24-hour step?
They share a 24-hour first step, not a calendar. CER Article 15(1): notify the competent authority without undue delay of incidents that significantly disrupt or could significantly disrupt essential services; unless operationally unable, submit an initial notification no later than 24 hours after becoming aware, followed where relevant by a detailed report no later than one month thereafter. There is no CER 72-hour middle step. CRA Article 14: 24-hour early warning and 72-hour fuller notification from awareness of an actively exploited vulnerability (AEV) or severe product-security incident, then a final report 14 days after a corrective or mitigating measure is available for an AEV, or within one month of the 72-hour notification for a severe incident. Matching “24 hours” does not merge the calendars — track each against its own trigger.
Who actually receives each report?
CRA Article 14 reports go to your coordinating CSIRT and ENISA through the CRA Single Reporting Platform. CER Article 15 notifications go to the Member State competent authority designated under the CER Directive — a different channel from the ENISA SRP, and usually different from the NIS2 CSIRT portal as well. Filing on one platform does not put your report in front of the other regime’s recipient.
What actually triggers each one?
CRA Article 14 is product-centric: an actively exploited vulnerability in a product with digital elements you manufacture, or a severe incident with impact on that product’s security. CER Article 15 is entity-centric: an incident that significantly disrupts or has the potential to significantly disrupt the provision of essential services by a designated critical entity (Art 15(1) significance parameters include users affected, duration, and geographical area). The same root cause can trip both, only one, or neither.
If we already file NIS2 for cyber incidents, does CER still apply — and does either cover CRA?
Often cyber matters sit with NIS2 rather than CER. CER Recital 9 states that matters covered by Directive (EU) 2022/2555 (NIS2) are excluded from CER scope, without prejudice to a particular regime for entities in the digital infrastructure sector — so many cyber incidents at critical entities run through NIS2 Article 23, not CER Article 15. That NIS2/CER allocation stays inside the entity-resilience family. Neither a CER Article 15 filing nor a NIS2 Article 23 filing rewrites CRA Article 14 or routes a product AEV into ENISA’s Single Reporting Platform. See the CRA vs NIS2 guide for the entity CSIRT track.
Does CER apply automatically if we manufacture software or connected products?
Not automatically. CER scope runs by Member State identification of critical entities that provide essential services in the sectors and subsectors listed in the CER Annex (energy, transport, banking, drinking water, health, digital infrastructure, and more) — not “manufacturers of products with digital elements” as a class. CRA Article 14 is much broader for manufacturers placing connected products on the Union market. Being a supplier to a critical entity also does not, by itself, make you a CER critical entity or cancel your manufacturer Article 14 duty.

Track the CRA clock — CER is separate

CER Article 15 filings do not replace the Article 14 chain. Use the free desk or deadline calculator for the 24-hour, 72-hour and final-report dates on a product case. No sign-up; data stays in your browser. Official CRA filing still goes through ENISA; CER still goes to your Member State competent authority.

Workflow support, not legal advice. Whether a given incident triggers a CRA Article 14 duty, a CER Article 15 duty, both, or neither — and whether any filing under one regime could ever be read as satisfying the other in your specific case — is a legal and factual determination for qualified counsel. Claims above track Regulation (EU) 2024/2847 Articles 14, 69(3) and 71(2) (via the same StreamLex / Springlex / Commission CRA reporting mirrors used on neighbouring guides) and Directive (EU) 2022/2557 Article 15(1)–(4) and Recital 9 (EUR-Lex OJ text, verified 21 Oct 2026). Confirm against the Official Journal texts (CRA on EUR-Lex; CER on EUR-Lex) before relying on this for a live case.