Glowing network nodes linked by light trails crossing multiple territorial boundaries, representing a cross-border critical infrastructure cyberattack under NIS2

NIS2 Critical Infrastructure Attack: The 24-Hour Cross-Border Flag Is Your Only Lever on EU Escalation

The Article 23(4)(a) early warning gives you one field in which to say that an attack may have reached beyond your own Member State. Tick it, and your report is routed to people you cannot contact, assessed against a definition you were not asked to apply, and possibly escalated to a network that will never tell you it looked at your incident. Leave it blank when it should have been ticked, and you have made an under-reporting call on behalf of every other affected Member State.

That field is the whole of your influence at EU level. Everything above your national CSIRT is authority-to-authority machinery, governed by Directive (EU) 2022/2555 and, since June 2025, by an adopted Council Recommendation that finally writes the escalation path down. What follows maps that path, states what actually qualifies as “large-scale”, and settles the question most multi-country groups get wrong: whether one attack means one filing or several.

The cross-border field is a suspicion box, not a finding

In plain terms: at hour 24 you are not being asked whether an attack did cross a border. You are being asked whether it could have. That is a much lower bar, and it is deliberate.

Article 23(4)(a) requires the early warning within 24 hours of becoming aware, and says it “shall indicate whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact”. Recital 102 uses the same forward-looking language: whether the incident “is likely to have a cross-border impact”. Neither waits for evidence, and both sit in the same sentence as the malicious-act suspicion flag — two fields you fill in on suspicion, when your forensics are hours old.

Free Download

Get the NIS2 Article 21 Compliance Checklist

90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.

✓ Check your inbox — the PDF is on its way.

Article 23(1) adds a duty that is easy to read past: entities must report “any information enabling the CSIRT or, where applicable, the competent authority to determine any cross-border impact of the incident”. Note who determines. You supply the raw material; the authority reaches the conclusion — which is why a defensible “no” needs a documented basis just as much as a “yes”.

And here is the part no vendor page mentions: “cross-border impact” is never defined in the Directive. The exact phrase appears four times in the enacting terms — once in Article 2(2)(d), where cross-border systemic risk is one of the criteria that pulls an entity into scope regardless of its size, and three times in Article 23 — yet Article 6, which defines forty-one terms including “incident”, “near miss” and “large-scale cybersecurity incident”, never defines it. No user threshold, no revenue test, no percentage. The judgement is yours and it is unbounded.

Some national authorities ask for more than the Directive does. Germany’s BSI publishes the exact field list for its early warning, and it asks for the suspicion of cross-border effects and the geographic spread (“Verdacht, ob grenzüberschreitende Auswirkungen möglich sind und geographische Ausbreitung”). That second half has no counterpart in Article 23(4)(a): in Germany a bare yes/no will not fill the form.

Does this section apply to you?

Your situation Does the cross-border field engage? Where you file
Established in one Member State, all recipients of the service in that Member State Rarely — but check dependencies. Your suppliers’ or customers’ own service continuity may sit elsewhere. One CSIRT / competent authority
Established in one Member State, recipients of the service in several Yes. Impact follows the service, not the company registration. Still one CSIRT — your Member State of establishment (Art. 26(1))
Group with separately established in-scope entities in several Member States Yes, and each affected entity assesses it for itself. One filing per establishment (see below)
Cloud, data centre, CDN, MSP, MSSP, DNS, TLD, marketplace, search or social provider Yes. Cross-border is the normal case for these categories. Main establishment in the Union (Art. 26(1)(b), 26(2))
Provider of public electronic communications networks or services Yes Every Member State in which you provide the service (Art. 26(1)(a))
Public administration entity Yes The Member State that established you (Art. 26(1)(c))

The five rungs above your CSIRT — and you are on none of them

In plain terms: your report climbs a ladder with five rungs. You hand it to the first one and lose sight of it. Nothing in NIS2 gives you a right to be told how far it went.

The ladder is assembled from three instruments, which is why almost nobody sets it out in one place. The Directive supplies the bodies and their mandates; the June 2025 Council Recommendation on an EU blueprint for cyber crisis management supplies the sequence and the decision rights; the IPCR arrangements sit on top.

Rung Who Legal basis What it decides Can you see it?
1 Your national CSIRT (or competent authority) Art. 23(1), 23(5) Whether your report is complete; gives you initial feedback, where possible within 24 hours of the early warning Yes — this is the only rung that talks back to you
2 Single point of contact Art. 8(3)–(4), 23(1) third sub-para, 23(6), 23(8) Whether other affected Member States and ENISA are informed, and whether your notification is forwarded to their single points of contact No
3 CSIRTs network Art. 15 Technical coordination; advises EU-CyCLONe on whether the incident may be a large-scale one No
4 EU-CyCLONe Art. 16 Operational coordination and impact assessment for large-scale incidents and crises; briefs the Council No
5 Council / IPCR arrangements Council Implementing Decision (EU) 2018/1993 Whether a cyber crisis is politically activated Only if it becomes public

A correction worth carrying forward: EU-CyCLONe is Article 16, not Article 15. Article 15 is the CSIRTs network. The two are routinely swapped in briefing notes and AI-generated summaries, and it matters because they sit at different levels and take their own decisions. Recital 71 describes EU-CyCLONe as working “as an intermediary between the technical and political level” and building “on the CSIRTs network findings” — the operational rung, one above the technical one. Its mandate, membership, and the reason no severity threshold exists to trigger it are set out in our guide to how EU-CyCLONe works under Article 16.

The Council Recommendation is the first instrument to state the decision rights plainly. The CSIRTs network “should advise EU-CyCLONe on whether an observed cybersecurity incident may be deemed a potential or ongoing large-scale cybersecurity incident” — and then, in the same section: “The activation of the CSIRTs network and EU-CyCLONe can be independent from each other depending on the nature of the incident and the response required… The decision to activate rests solely and independently with each respective network.” There is no automatic promotion: your CSIRT escalating does not oblige EU-CyCLONe to convene, and EU-CyCLONe can look at something the CSIRTs network has not escalated.

None of that is binding law — a Council Recommendation is not. It is the Council’s own description of how the framework should operate, adopted on 6 June 2025, and the closest thing to a published escalation procedure that exists. The operating detail lives in the two networks’ Standard Operating Procedures, which the Recommendation refers to but which are not published; ENISA describes exercising them, in the CySOPex and BlueOLEx series, without publishing them.

Rung 4 has a designated national member, and it may not be the authority you know

Article 16(2) composes EU-CyCLONe of “representatives of Member States’ cyber crisis management authorities” — a distinct designation created by Article 9(1), separate from the Article 8 competent authority you register with and the Article 10 CSIRT you report to. Where a Member State names more than one, Article 9(2) requires it to say which acts as coordinator.

Three designations, and only two are easy to look up. The European Commission publishes country pages for the Directive listing the single point of contact, the competent authorities and the national CSIRT. Checked against Germany, Belgium and Luxembourg, all three stop there — none names the Article 9 cyber crisis management authority, the one body of the three that sits where escalation is decided. Sometimes the answer is “the same organisation again”: Germany routes those roles through the BSI, Belgium through the Centre for Cybersecurity Belgium. Sometimes it is not — Luxembourg already splits the single point of contact, the financial-sector authority and the CSIRT across three different bodies. Which of them carries the crisis mandate is a question for your national authority, not a Commission web page.

“Large-scale” is a different threshold from “significant” — and it is not yours to apply

In plain terms: you assess one threshold. The networks above you assess a second one you are never asked about. Confusing them is what makes teams over-escalate internally and misbrief their boards.

Article 6(7) defines a large-scale cybersecurity incident as “an incident which causes a level of disruption that exceeds a Member State’s capacity to respond to it or which has a significant impact on at least two Member States”. Two disjunctive limbs: a purely domestic incident that overwhelms a national response capability qualifies without touching a second country, and one that lands hard in two Member States qualifies without overwhelming anyone.

Threshold Source Test Who applies it
Incident Art. 6(6) An event compromising the availability, authenticity, integrity or confidentiality of data or services You
Significant incident Art. 23(3)(a)–(b) Severe operational disruption or financial loss for you; or considerable material or non-material damage to others. Either limb alone is enough. You — this is the reporting trigger
Large-scale cybersecurity incident Art. 6(7) Disruption exceeding a Member State’s capacity to respond; or significant impact on at least two Member States CSIRTs network advises, EU-CyCLONe decides
Cyber crisis Council Recommendation C/2025/3445, read with Council Implementing Decision (EU) 2018/1993 A large-scale incident affecting the internal market or posing serious public security and safety risks across several Member States The Council, via IPCR

Note what is absent from the whole ladder: numbers. The Council Recommendation concedes the gap itself. It tasks EU-CyCLONe, supported by ENISA and after consulting the CSIRTs network and the NIS Cooperation Group, to “within 24 months from adoption of this Recommendation, agree on a common aligned taxonomy of incident severity levels” — one comparing severity across Member States “by considering the impact on service delivery, the number of affected entities and their respective relevance, the impact on other services and infrastructure, as well as the monetary, reputational and political damage inflicted”. Adoption was 6 June 2025, so that work is due around June 2027.

That paragraph disposes of a claim now circulating widely: that the Cyber Blueprint runs a five-level severity scale from 0 to 4, with levels 3 and 4 triggering EU-CyCLONe and the IPCR. The word “severity” appears exactly twice in the adopted text, both times inside the paragraph commissioning the future taxonomy. There is no numbered scale in the instrument — a body cannot be tasked with agreeing one by 2027 and be operating it already. If a consultant shows your board a 0–4 escalation matrix attributed to the EU Cyber Blueprint, ask which paragraph it comes from.

The consequence is calibration, not paperwork. The Recommendation’s proportionality principle states that “most cybersecurity incidents affecting Member States fall below what could be considered a national or Union large-scale cybersecurity incident or cyber crisis”. ENISA’s Threat Landscape 2025 puts numbers around that: essential entities account for 53.7% of recorded incidents in the EU, yet the hacktivist DDoS activity dominating raw volume produced service disruption in only 2% of cases. Volume is not escalation. Your significant-incident assessment is a filing decision, not a prediction that Brussels will convene.

Three countries, three filings: NIS2 has no one-stop shop

In plain terms: if your group has separately established in-scope entities in three Member States and one attack hits all three, you file three times, in three languages, on three portals, inside the same 24 hours. There is no lead authority to absorb that for you.

Article 26(1) is the rule: entities “shall be considered to fall under the jurisdiction of the Member State in which they are established”. The carve-outs are narrow. Providers of public electronic communications networks or services fall under each Member State in which they provide the service. The named digital categories — DNS, TLD registries, domain registration, cloud, data centres, CDN, MSP, MSSP, online marketplaces, search engines and social platforms — get a genuine single-jurisdiction rule under Article 26(1)(b), pinned to their “main establishment”, which Article 26(2) locates where cybersecurity risk-management decisions are predominantly taken, failing that where cybersecurity operations run, failing that where the largest Union workforce sits. Public administration entities answer to the Member State that established them.

Everyone else — energy, transport, water, health, manufacturing, food, chemicals, waste, postal, research — is governed by establishment. That is the structural difference from the GDPR that catches teams assuming the two regimes behave alike: there is no NIS2 lead supervisory authority for a group spread across the Union. The Directive solves the coordination problem on the authorities’ side, through the single point of contact’s liaison function under Article 8(4) and mutual assistance under Article 37 — not by reducing your filing count.

Worked example. A manufacturer runs plants in Germany, Poland and the Czech Republic, each a separately established in-scope company. Ransomware reaches the shared ERP and halts production at all three. The German entity files with the BSI, the Polish entity with its national CSIRT, the Czech entity with its own — each within 24 hours of that entity becoming aware, each ticking the cross-border field, each on its own national form. Article 23(6) then provides that “where appropriate, and in particular where the significant incident concerns two or more Member States”, the CSIRT, competent authority or single point of contact shall inform the other affected Member States and ENISA without undue delay. That is the authorities reconciling three reports into one picture — after your three filings, not instead of them. Article 23(8) makes the onward forwarding conditional on the CSIRT or competent authority requesting it.

Two asymmetries follow. Each 24-hour clock starts on that entity’s own awareness, so a group SOC that detects centrally starts three clocks at once while a federated one starts them hours apart. And Article 23(6) obliges the receiving authority to preserve “the entity’s security and commercial interests as well as the confidentiality of the information provided” when passing information on — worth knowing before counsel objects to the cross-border flag on confidentiality grounds. Where personal data is also involved, the GDPR and NIS2 duties run on separate tracks.

What to do about it: a cross-border reporting runbook

In plain terms: almost all of this work has to be done before the incident. At hour 3 of a live attack you will not be researching which Luxembourgish body holds the crisis mandate.

Who owns what

Role Owns The decision they must be able to make in 24 hours
Incident commander / CISO The cross-border call and the evidence behind it “Could this have affected recipients, systems or entities in another Member State?” — answered from a pre-built service dependency map, not from memory
Compliance officer Filing coverage across establishments Which legal entities are in scope, in which Member States, and whether each one’s clock has started
Legal counsel Confidentiality and law-enforcement interface Whether the malicious-act suspicion flag is being set — under Art. 23(5), where an incident is suspected to be of criminal nature the CSIRT or competent authority must also give guidance on reporting it to law enforcement
Group SOC lead Awareness timestamps When each affected establishment became aware — recorded per entity, because that is what each 24-hour clock runs from
Board / management body Escalation posture Whether to activate crisis governance internally, understanding that no EU-level signal will arrive to prompt it

What cross-border information belongs in each report

Stage Deadline Cross-border content required
Early warning Within 24 hours of awareness (Art. 23(4)(a)) Whether the incident could have a cross-border impact, and whether it is suspected of being caused by unlawful or malicious acts. Germany also asks for geographic spread.
Incident notification Within 72 hours (Art. 23(4)(b)) Updates the early warning; initial assessment of severity and impact, plus indicators of compromise where available. Your first realistic chance to correct a cross-border call made on thin evidence.
Intermediate report On request (Art. 23(4)(c)) Status updates as the authority asks for them
Final report Within one month of the 72-hour notification (Art. 23(4)(d)) Explicitly includes, where applicable, the cross-border impact of the incident — Art. 23(4)(d)(iv)
Progress + later final report Where the incident is still running at final-report time (Art. 23(4)(e)) Progress report then, final report within one month of completing incident handling

The four things to fix before the next incident

1. Map service dependencies by Member State, not by data centre. The Article 23(3)(b) limb asks about damage to other natural or legal persons. If a service you run in one country is a dependency for a customer’s regulated service in another, that is the cross-border route most teams miss — because their asset inventory is organised by infrastructure rather than by recipient.

2. Hold tested contact details for every establishment’s CSIRT and competent authority. The Commission publishes the single points of contact under Article 8(6), and our guide to where to report a NIS2 incident in 24 hours lists national portals and their login requirements. Portals need accounts, and accounts need to exist before the incident.

3. Write the cross-border decision into the playbook as a named step with a named owner. It is a judgement call under time pressure with no defined threshold — exactly the kind of decision that gets skipped and then badly reconstructed afterwards. Our incident response playbook structure places it at the Article 23 trigger point; the same call needs a route into crisis governance when several establishments are hit at once.

4. Brief the board on what silence means. No feedback from EU level is not evidence that your incident was judged minor — it is the expected outcome. The only response you are entitled to comes from your own CSIRT or competent authority under Article 23(5): initial feedback, where possible within 24 hours of the early warning, plus guidance or operational advice on mitigation if you ask. Ask.

Frequently asked questions

Does ticking the cross-border box escalate my incident to EU-CyCLONe?

No. It routes information: Article 23(1) requires single points of contact to be given relevant information in due time for a cross-border or cross-sectoral significant incident, and Article 23(6) requires other affected Member States and ENISA to be informed where appropriate. Whether the CSIRTs network or EU-CyCLONe then activates is a decision that, in the Council’s words, “rests solely and independently with each respective network”.

Will anyone tell me if my incident was treated as large-scale?

Nothing in Article 23 or Article 16 creates a duty to inform the notifying entity that its incident was escalated. The one route by which it can become visible is Article 23(7), which lets a CSIRT or competent authority inform the public about a significant incident, or require you to do so, after consulting you — where public awareness is necessary or disclosure is otherwise in the public interest.

If we are unsure whether the impact crossed a border, should we tick the box?

The field asks whether the incident “could have” cross-border impact, so genuine uncertainty about a plausible route generally falls inside it rather than outside. Two things temper that. Article 23(1) states that “the mere act of notification shall not subject the notifying entity to increased liability”. And Recital 102 asks Member States to ensure reporting obligations do not divert resources from incident handling — so this is a documented judgement recorded in minutes, not an investigation that pulls responders off containment. Whichever way you call it, write down why.

Is there a euro figure or user count that makes an incident cross-border?

No. The Directive defines “cross-border impact” nowhere. Commission Implementing Regulation (EU) 2024/2690, which does set quantified criteria, binds only eleven categories of digital and trust service provider and addresses significance rather than cross-border reach. Any threshold you apply is your own documented method — write it down as such.

The short version

You control one field and your filings. Above your CSIRT the chain is real, legally grounded and closed to you: single point of contact, CSIRTs network, EU-CyCLONe under Article 16, Council under the IPCR arrangements — each network deciding its own activation, none of them obliged to tell you it happened. The threshold those bodies apply is Article 6(7), not your Article 23(3) test, and until the common severity taxonomy lands around June 2027 there is no agreed EU scale behind it at all. What you can do is make the cross-border judgement deliberately, record the reasoning, and make sure every establishment that must file can reach its authority inside 24 hours.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

  1. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex. Articles 6(6), 6(7), 8, 9, 15, 16, 23, 26, 37 and Recitals 69, 71, 102.
  2. Council Recommendation of 6 June 2025 on an EU blueprint for cyber crisis management (C/2025/3445) — Official Journal of the European Union, C series, 20 June 2025.
  3. EU CyCLONe — European Union Agency for Cybersecurity (ENISA).
  4. ENISA Threat Landscape 2025 (Booklet) — ENISA, October 2025.
  5. NIS2 Directive — Germany — European Commission, Shaping Europe’s digital future. Belgium and Luxembourg country pages checked for the same role listings.
  6. “NIS-2-Meldepflicht”, Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de) — national early-warning and final-report field lists.
  7. NIS 2 Directive, Article 16: European cyber crisis liaison organisation network (EU-CyCLONe) — article-level view of the Official Journal text.
Free Download

Get the NIS2 Article 21 Compliance Checklist

90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.

✓ Check your inbox — the PDF is on its way.

Don't miss: