GPS Spoofing, KA-SAT, and Art. 23: What Space Sector Operators Must Report Under NIS2

At 05:58 UTC on 24 February 2022, as Russian forces crossed into Ukraine, a wiper malware called AcidRain began systematically destroying SATCOM modems connected to Viasat’s KA-SAT satellite network. Within hours, approximately 5,800 Enercon wind turbines in Germany lost remote monitoring capability, tens of thousands of broadband subscribers across Poland, France, Italy, and Greece went dark, and ground station operators watched their customer modem fleet go permanently offline — bricked beyond recovery by mass firmware overwrites [3].

NIS2 was not yet in force. The Directive (EU) 2022/2555 had entered into force in January 2023, with a transposition deadline of October 17, 2024. Had those dates been earlier, Viasat’s ground station operators across Europe would have faced a precise legal obligation: file an early warning with their national CSIRT within 24 hours of becoming aware of the incident [1].

This article maps what that obligation would have looked like — and what the KA-SAT attack reveals about the Art. 21(2) gaps that made it possible. It also explains why GNSS spoofing, increasingly common over European airspace and sea lanes, triggers Art. 23(3)(b)’s cascading harm provision in a way that aviation and maritime operators may not yet have considered.

Who Must Report: Space Sector Entities Under NIS2 Annex I

NIS2 covers the space sector explicitly. Annex I of Directive (EU) 2022/2555 lists space as Sector 11 among the highly critical sectors, defining the in-scope entity type as: operators of ground-based infrastructure owned, managed and operated by Member States or by private parties, that support the provision of space-based services, excluding providers of public electronic communications networks or services [4].

Three points clarify who this captures:

• Ground-based infrastructure only. The satellite itself is not in scope — NIS2 cannot practically regulate an object in orbit. The obligation falls on the terrestrial infrastructure that supports the satellite service: teleports, mission control facilities, uplink stations, ground segment networks, and the management systems that connect them to end-user equipment.
• Excludes telecoms providers already regulated under the EECC. Operators whose primary activity is providing public electronic communications networks or services fall under separate sectoral legislation. A ground station operator whose principal function is satellite connectivity services — not a public telecoms network — sits squarely in Annex I Sector 11.
• Size thresholds apply. Under Article 3, essential entity status requires either: (a) 250+ employees or €50M+ turnover and €43M+ balance sheet; or (b) qualifying as critical regardless of size (e.g., sole provider of a critical service to a Member State). Important entities use the medium enterprise thresholds (50–249 employees, €10M–50M turnover).

If your organisation operates ground infrastructure that supports satellite-based positioning, earth observation, communications relay, or remote sensing — and meets the size threshold — you are likely an essential entity with Art. 23 obligations. For a detailed analysis of the Annex I ground segment scope, see our companion guide on NIS2 obligations for satellite ground station operators.

The Three-Stage Art. 23 Notification Cascade

Article 23 does not give ground station operators a single deadline. It establishes a three-stage cascade, each with its own timeline, recipient, and content requirement. Missing any stage — or filing the right information to the wrong body — is a reportable failure in its own right [1].

Stage	Deadline	Filed with	Required content
Early warning — Art. 23(4)(a)	24 hours from awareness	National CSIRT or competent authority	Flag the incident; indicate if suspected malicious/unlawful act; flag cross-border impact if applicable
Incident notification — Art. 23(4)(b)	72 hours from awareness	National CSIRT or competent authority	Initial assessment; severity and impact; indicators of compromise (IoCs) where available
Final report — Art. 23(4)(d)	1 month from incident notification	National CSIRT or competent authority	Detailed description; root cause / threat type; mitigation measures applied and ongoing; cross-border impact assessment

Two operational points matter enormously in a space sector context:

The clock starts at awareness, not at impact. If your network operations centre first detects anomalous modem behaviour at 14:00 and confirms a significant incident at 14:45, the 24-hour window opens at 14:45 — not at 14:00. Your incident detection and triage procedures must document the exact moment of awareness, because that timestamp is what an auditor will interrogate.

Multi-country incidents require parallel notifications. A ground station operator serving customers in France, Poland, and Italy who experiences a simultaneous modem outage may need to notify three separate national CSIRTs. Under Article 23(6), where a significant incident affects two or more Member States, the relevant CSIRT or competent authority is required to inform the others and notify ENISA [1]. Your incident response plan needs to map which national authority receives the initial 24-hour filing for each country where you have customers or infrastructure.

Trust service providers face a stricter timeline: by derogation from the standard 72-hour rule, they must submit the full incident notification within 24 hours. If your ground station supports a qualified trust service, that stricter deadline applies to you.

What Makes a Space Incident “Significant” Under Art. 23

The notification obligation only triggers when an incident is “significant.” Article 23(3) defines this using two independent criteria — both are relevant for space sector operators, and the second is the one most practitioners overlook [1].

Art. 23(3)(a) — operational disruption or financial loss. An incident is significant if it “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned.” For a ground station operator, this threshold activates when:

• A cyberattack disables the satellite uplink, taking an earth observation or positioning service offline for hours or days
• Ransomware encrypts mission control systems, preventing command and telemetry transmission to active satellites
• A supply chain compromise of ground segment software causes systematic failures across multiple customer sites
• A physical intrusion at a teleport facility combined with a cyber component disables the uplink infrastructure

Art. 23(3)(b) — cascading harm to others. An incident is also significant if it “has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.” This is the provision that transforms a ground station incident from a bilateral matter between your organisation and your CSIRT into a multi-stakeholder event.

The two criteria are stated in the alternative: an incident that satisfies either one triggers the full notification cascade. An attack that causes minimal operational disruption for the ground station operator — perhaps because the attacker moved quietly and caused no immediate downtime — but which compromises the integrity of outgoing GNSS signals and affects downstream users across multiple sectors, satisfies Art. 23(3)(b) even if Art. 23(3)(a) is not clearly met.

For the space sector, that second criterion carries significant practical weight. It is the provision that governs GNSS spoofing.

GNSS Spoofing as an Art. 23(3)(b) Trigger — Cross-Sector Cascading Harm

GNSS spoofing — broadcasting false positioning signals that override legitimate GPS, Galileo, or GLONASS data — is no longer a theoretical threat. Systematic spoofing events have disrupted commercial aviation in the Baltic and Black Sea regions, redirected maritime vessels, and interfered with road transport logistics across Eastern Europe. What makes spoofing legally distinctive under NIS2 is the mechanism of harm: the attack may cause no operational disruption at the ground station level at all, yet it triggers Art. 23(3)(b) because the harm cascades entirely to external parties.

Consider the harm chain from a compromised ground infrastructure element that begins broadcasting spoofed positioning signals:

• Aviation. Aircraft within the spoofed coverage area receive false position data. Modern aircraft are designed to detect GNSS inconsistencies and fall back to inertial navigation, but the detection mechanism is not instantaneous, and aircraft in certain critical flight phases — final approach, steep terrain departure procedures — face genuine navigational hazard. EASA has published awareness materials on GNSS interference events affecting EU airspace. For analysis of NIS2 obligations for aviation operators, see our guide on aviation cybersecurity compliance under NIS2.
• Maritime. AIS (Automatic Identification System) transponders report vessel position based on received GNSS data. Spoofed GNSS can cause ships to report incorrect positions to vessel traffic services, creating phantom vessels in maritime monitoring systems and masking real vessel locations. Port approach procedures that rely on GNSS positioning are directly impaired. See our analysis of maritime NIS2 obligations for the parallel incident reporting requirements for vessel operators.
• Road transport. Logistics systems, fleet management platforms, and emergency vehicle routing that rely on GNSS-based telematics are disrupted. Emergency services responding to incidents in a spoofed zone may be misdirected. Timestamp-based logistics chains dependent on GNSS-derived UTC may experience synchronisation failures.

Each of these downstream effects constitutes “considerable material or non-material damage” to other natural or legal persons under Art. 23(3)(b) [1]. The spoofed signal emanating from compromised ground infrastructure causes that damage. The ground station operator who discovers that their infrastructure has been used to broadcast spoofed signals — or whose systems have been compromised in a way that could produce that outcome — must file the 24-hour early warning regardless of whether their own services are disrupted.

The practical implication: your significant incident definition in internal documentation must include “any compromise of outgoing signal integrity, including GNSS signal generation or relay infrastructure,” not only “events causing service outage.” An incident that leaves your uptime metrics unaffected but corrupts your signal output is a significant incident under Art. 23(3)(b).

The KA-SAT Retrospective: An Art. 21(2) Gap Analysis

The KA-SAT attack is the most consequential satellite infrastructure cyberattack in European history. Understanding what it reveals about NIS2 obligations is not merely academic: ENISA’s threat landscape and the CISA/FBI joint advisory issued in March 2022 make clear that satellite management networks are high-priority targets for state-sponsored actors [3]. The vulnerabilities the KA-SAT attack exploited are structural to how ground-to-modem management architectures work — they have not disappeared.

What happened. On 24 February 2022, attackers accessed Viasat’s network management infrastructure — the system used to manage the firmware and configuration of SATCOM modems connected to the KA-SAT satellite. Using a wiper payload (subsequently labelled AcidRain by researchers at SentinelLabs), attackers sent mass firmware overwrite commands to modems across multiple European countries simultaneously. The modems became permanently inoperable — a bricked modem requires physical replacement, not remote recovery. The attack vector was a misconfigured VPN appliance on the management network that allowed unauthorised access from the public internet. The U.S. government formally attributed the attack to Russian state-sponsored actors in May 2022 [3].

Against each of Art. 21(2)’s ten security domains, the attack reveals the following gaps:

Art. 21(2) domain	KA-SAT gap	Severity
(a) Risk analysis and information system security	The management network’s exposure to the public internet via a misconfigured VPN was not identified as a critical risk vector. A documented risk assessment covering the management plane attack surface would have flagged this.	Critical
(b) Incident handling	No documented plan existed for a simultaneous mass modem-bricking event across multiple EU countries requiring parallel notifications to multiple national authorities.	Critical
(c) Business continuity, backup, disaster recovery	Physical modem replacement at scale across Europe required weeks. No pre-positioned spare hardware buffer or rapid-swap logistics plan was in place.	High
(d) Supply chain security	The management protocol connecting ground infrastructure to customer modems was the attack surface. No documented security assessment of the ground-to-modem management relationship existed.	High
(e) Network and information systems security; vulnerability handling	The VPN misconfiguration — the direct entry point — was a documented vulnerability class. Network segmentation between the management plane and the public internet was insufficient.	Critical
(i) Access control and asset management	The management network access control model allowed unauthorised actors to authenticate and issue firmware commands. Least-privilege enforcement on modem management commands was absent.	Critical

Four of the six gaps above — (a), (b), (e), and (i) — are domains where Art. 21(2) imposes a direct and unambiguous obligation on essential entities. An NIS2-compliant ground station operator would have been required to have documented measures in each of these areas before the incident occurred. The absence of those measures would expose the operator’s management board to personal supervisory enforcement under Article 20, which requires management bodies to approve and oversee the Art. 21 measures.

For a broader review of NIS2 incident reporting across critical sectors, including energy sector case studies, see our analysis of energy sector incident response obligations.

Enforcement and Director Liability When Notifications Are Late

Ground station operators who miss the Art. 23 timelines face a two-track enforcement risk. The first track is the standard NIS2 supervisory regime. The second — and the one boards tend to overlook — is personal director liability.

Supervisory fines for essential entities. Under Article 32 of Directive (EU) 2022/2555, competent authorities may impose fines on essential entities of up to €10,000,000 or 2% of total worldwide annual turnover, whichever is higher. For a satellite operator with significant global revenue, 2% of worldwide turnover will exceed the flat-cap figure substantially. These fines apply to failures in the Art. 21 risk management measures — but the evidence of those failures comes directly from what is or is not documented in the Art. 23 final report. A final report that cannot demonstrate pre-existing BCP, incident response procedures, or access control policies is itself the evidence of Art. 21 non-compliance [4].

Director personal liability. Article 20(1) of NIS2 requires management bodies — not just the organisation — to approve and oversee the entity’s cybersecurity risk-management measures under Article 21, and states that management body members can be held liable for the entity’s infringements. Article 20(1) also requires member states to ensure management board members receive cybersecurity training. Several EU member states have transposed the personal liability dimension as a direct management ban: in Latvia, for example, repeated negligent breaches can result in a three-year prohibition on holding management positions. If your board has not formally approved a documented Art. 21(2) policy set, and an Art. 23 incident reveals that, the personal liability provision is live.

What “without undue delay” means in practice. The phrase “without undue delay and in any event within 24 hours” creates a dual obligation: the 24-hour hard cap, and a softer obligation not to delay even within that window once awareness is confirmed. If your NOC team identifies an anomaly at 06:00, spends four hours investigating without escalating to the legal/compliance function, and files the early warning at 17:00, you are within the 24-hour cap but may still face questions about whether you delayed without justification. Competent authorities reviewing Art. 23 compliance will examine the internal escalation timestamps, not just the notification timestamp. Your incident response procedures must define the internal escalation chain and attach a time expectation to each step.

Space Sector Art. 23 Implementation Checklist

The following checklist maps the Art. 23 obligations to the three roles most directly responsible for compliance in a space sector ground operations context. This is not a substitute for legal advice specific to your organisation and jurisdiction — see the disclaimer below.

Action item	CISO / IT Security	Compliance / Legal	Board / C-Suite
Confirm entity status: essential or important under NIS2 Annex I Sector 11		Own	Approve
Identify national CSIRT / competent authority for each country with ground infrastructure or customers	Support	Own
Define “significant incident” triggers (Art. 23(3)(a)+(b)) in internal incident classification policy	Own	Review	Approve
Include GNSS signal integrity compromise in significant incident definition	Own	Review
Build 24h early warning template with awareness timestamp, cross-border flag, malicious-act indicator	Own	Review
Build 72h incident notification template with severity, IoC fields, initial impact assessment	Own	Review
Map internal escalation chain: NOC → CISO → Legal → Board with time expectations	Own	Review	Aware
Document Art. 21(2) risk management measures for board formal approval (Art. 20 obligation)	Support	Own	Approve (legally required)
Conduct tabletop exercise simulating mass modem outage / GNSS integrity failure scenario	Own	Participate	Briefed
Verify customer service terms include NIS2 Art. 23(1) downstream notification obligations		Own

Frequently Asked Questions

Does NIS2 apply to satellite constellations operated by commercial operators, not government agencies?
Yes. Annex I Sector 11 covers operators of ground-based infrastructure managed by private parties, not only Member States. The size thresholds still apply: essential entity status requires 250+ employees or €50M+ turnover and €43M+ balance sheet unless the entity is designated as critical regardless of size. A commercial ground station operator meeting those thresholds is an essential entity.

What if the satellite uplink failure is caused by a solar storm or natural electromagnetic interference rather than a cyberattack?
The “significant incident” definition in Art. 23(3) does not require malicious causation — it only requires severe operational disruption (3)(a) or considerable harm to others (3)(b). A solar event causing a multi-country outage of the scale of the KA-SAT incident would likely meet the significance threshold under (3)(a). However, Art. 23(4)(a) specifically asks whether the incident is “suspected of being caused by unlawful or malicious acts” — implying that natural causes are also in scope but should be flagged differently in the early warning. For general incident reporting obligations including near-miss and natural event classification, see our guide on NIS2 incident reporting requirements.

Our ground station is in the EU but our customers are outside the EU. Does Art. 23 still apply?
NIS2 is jurisdictional: it applies to entities established in the EU. The location of your customers does not affect your obligation to notify your national CSIRT when a significant incident occurs. However, Art. 23(3)(b)’s cascading harm provision does not limit itself to EU persons: “other natural or legal persons” includes recipients worldwide. If your satellite infrastructure is used to deliver GNSS-derived services consumed globally and a signal compromise affects non-EU aviation or maritime operators, that cross-border dimension strengthens the significance assessment even though the notification recipient is your EU national CSIRT.

At what point do we notify downstream customers rather than the CSIRT?
Under Art. 23(1), the entity must also notify, without undue delay, the recipients of its services of significant incidents that are likely to adversely affect provision of those services. Under Art. 23(2), where a significant cyber threat (pre-incident) is identified, entities must communicate to recipients any measures or remedies those recipients can take. These are parallel obligations to the CSIRT notification, not substitutes for it. Your incident communications plan should have separate channels and templates for regulatory notification and for customer notification [1].

What happens to our NIS2 obligations if we fall under the planned EU Space Act?
The proposed EU Space Act (under development as of mid-2026) is expected to establish sector-specific cybersecurity and resilience requirements for the space sector that go beyond NIS2 Annex I scope. The relationship between sector-specific legislation and NIS2 is governed by Art. 4(2) of the Directive, which provides that sector-specific rules take precedence where they achieve an equivalent level of security and include equivalent incident reporting obligations. Until the EU Space Act is in force and confirmed as a lex specialis equivalent, NIS2 Art. 23 obligations remain fully applicable. Monitor the legislative timeline — the relationship between both frameworks will need to be assessed once implementing regulations are published.

Key Takeaways

• Ground station operators meeting NIS2 size thresholds are essential entities under Annex I Sector 11 and face Art. 23 notification obligations. The satellite itself is excluded; the ground infrastructure is not.
• Art. 23 operates as a three-stage cascade: 24-hour early warning, 72-hour incident notification, 1-month final report — each with distinct content requirements. The clock starts at awareness, not at impact.
• Art. 23(3)(b) is the provision that captures GNSS spoofing and signal integrity attacks: an incident that causes no downtime for the ground station but generates cascading harm to aviation, maritime, or road transport operators still meets the significance threshold.
• The KA-SAT attack exposes six Art. 21(2) gaps: risk analysis (a), incident handling (b), business continuity (c), supply chain (d), network security (e), and access control (i). These are the same gaps a competent authority will audit in a post-incident review.
• Director personal liability under Art. 20(2) is live if the management board has not formally approved the Art. 21(2) measure set. The final Art. 23 report is the document that makes that failure visible.

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. NIS2 Directive (EU) 2022/2555, Article 23 — Reporting obligations — nis-2-directive.com
2. NIS2 Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures — nis-2-directive.com
3. Strengthening Cybersecurity of SATCOM Network Providers and Customers (AA22-076A) — CISA/FBI Joint Advisory, updated May 2022
4. NIS2 Directive (EU) 2022/2555 — EUR-Lex CELEX 32022L2555