NIS2 space sector checklist for commercial satellite operators and ground station infrastructure providers

NIS2 Space Sector Checklist: 36 Controls for Commercial Satellite Operators and Ground Stations

In February 2022, the Viasat KA-SAT network attack took down tens of thousands of satellite modems across Europe within hours, disrupting wind farm remote controls in Germany and emergency communications in Ukraine. The attack did not originate from orbit: it exploited a misconfigured VPN device in the satellite’s ground network management infrastructure. Three years later, Directive (EU) 2022/2555 names space as one of eleven high-criticality sectors in Annex I, and ground operators across the EU have faced compliance obligations since October 2024.

Most NIS2 guidance for the space sector focuses on what the directive says. This checklist focuses on what you need to build: 36 documented controls mapped to all ten Article 21(2) measures, structured for the specific technical realities of ground segment operations — satellite command link authentication, space weather as a business continuity variable, and the supply chain complexity that comes with commercial off-the-shelf hardware in uplink systems. Satellites in orbit and spacecraft hardware sit outside NIS2’s Annex I scope; this checklist covers the operators of the infrastructure on the ground.

Is Your Ground Station in Scope?

NIS2 Annex I, Section 11 defines the space sector 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.” Three categories of terrestrial infrastructure fall within this definition: mission control centres holding telecommand authority over satellites; ground station networks hosting uplink and downlink equipment; and satellite data processing centres handling navigation, earth observation, or communications data for third-party services.

The size threshold determines your entity classification and penalty exposure.

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.

Entity type Size threshold Supervision model Maximum penalty
Essential entity 250+ employees OR €50M+ annual turnover Ex-ante (proactive) NCA supervision; on-site audits, security scans €10 million or 2% of global annual turnover, whichever is higher
Important entity 50–249 employees OR €10M–50M turnover Ex-post (reactive) supervision following incident or complaint €7 million or 1.4% of global annual turnover, whichever is higher
Outside NIS2 scope Below 50 employees AND below €10M turnover No NIS2 obligations unless member state designates as in-scope Not applicable

Member states retain discretion under Article 3(3)-(4) to designate additional ground operators as essential or important regardless of general size thresholds, where disruption of their services would have significant cross-sector impact.

Two scope questions generate wrong answers most often for space operators.

Satellites in orbit are not covered by NIS2. The directive covers ground-based infrastructure that supports space services, not the spacecraft itself, its onboard software, or its hardware components. Satellite manufacturers supplying products for orbital platforms fall primarily under the Cyber Resilience Act (EU Regulation 2024/2847), which imposes security-by-design requirements across the life cycle of digital products placed on the EU market. The CRA/NIS2 boundary runs at the edge of the terrestrial ground segment: if your product is deployed in orbit, CRA governs; if your infrastructure commands or processes from the ground, NIS2 applies. Many commercial operators span both sides of this line.

EU Space Programme assets are excluded. Infrastructure owned or operated on behalf of the Union — including the Galileo ground segment managed by EUSPA — is excluded from Annex I scope by the directive’s own text. Commercial operators whose services depend on Galileo signals but who operate independent ground infrastructure are in scope as separate entities if they meet size thresholds. Operators whose infrastructure forms part of the EUSPA-managed Galileo ground segment face the EUSPA Security Accreditation Board’s requirements, coordinated through the Galileo Security Monitoring Centre, rather than standard NIS2 supervision.

For an interactive scope determination tool covering all NIS2 sectors, see our NIS2 scope guide. The existing space sector compliance overview covers the three ground segment architecture types in detail.

What the 36 Controls Cover: Mapping Article 21 to Space Operations

Article 21(1) requires an “all-hazards approach” — not just cyber threats, but physical, environmental, and human risks to ground segment systems. For space operators this expands the threat model beyond standard IT infrastructure: radio-frequency interference and jamming, solar events affecting antenna hardware and satellite timing signals, supply chain compromises targeting COTS components in uplink chains, and multi-vector attacks combining credential theft with targeted firmware overwrites, as demonstrated by the KA-SAT incident.

The table below maps each Article 21(2) measure to its ground segment priority and the number of controls in the checklist below.

Article 21(2) measure Ground segment application Controls
(a) Risk analysis and IS security policies Threat model must cover RF interference, GNSS spoofing, and command link hijacking alongside IT threats 1–5
(b) Incident handling Telecommand isolation procedure and space-specific incident classification 6–10
(c) Business continuity Space weather events are an all-hazards BCP requirement; redundant uplink capability 11–14
(d) Supply chain security COTS hardware provenance, SBOM management, software-defined radio stack supplier oversight 15–19
(e) Security in acquisition and development Pre-deployment testing of firmware updates for mission-critical uplink systems 20–22
(f) Effectiveness assessment Annual Art.21 control review; penetration testing of ground segment networks and remote access 23–25
(g) Cybersecurity training Mission control operators require role-specific telecommand authentication training 26–27
(h) Cryptography Authenticated encryption on all telecommand uplinks; key management for ground-to-space sessions 28–30
(i) Human resources and access control Two-person integrity for telecommand authority; background checks for uplink access roles 31–33
(j) Multi-factor authentication Hardware tokens preferred for mission control system access; no single-factor path to commanding interfaces 34–36

Article 21 does not prescribe specific technical standards. ENISA’s Space Threat Landscape (published March 2025) recommends a 125-control framework across 18 categories for commercial satellite operators, with particular emphasis on ground segment lifecycle security from design through decommissioning. The controls below are calibrated to Article 21(2)’s structure and represent a proportionate compliance baseline for medium-to-large ground operators. Operators pursuing ISO 27001:2022 certification can use these controls as a structured bridge to Annex A mapping.

36 NIS2 Controls for Ground Segment Operators

Each control is written as a verifiable action. “Implemented” means you have a documented record a national competent authority can inspect.

Risk Analysis and Security Policies — Article 21(2)(a) (Controls 1–5)

  1. Maintain an information security policy that explicitly references the all-hazards approach under Article 21(1) and covers the specific threat landscape of your ground segment architecture — not a generic IT security policy adapted from another sector.
  2. Document a space-specific threat model covering radio-frequency interference, GNSS spoofing, satellite command link hijacking, insider threats, and supply chain compromise of COTS uplink components. Update this annually and after any significant incident.
  3. Classify ground segment assets into criticality tiers: telecommand terminals and mission control infrastructure as Tier 1; data processing and downlink systems as Tier 2; administrative and support systems as Tier 3. Document the classification criteria and review annually.
  4. Conduct a formal risk assessment against a recognised framework — ENISA’s Space Threat Landscape 2025 control clusters or ISO 27001:2022 Annex A — at least annually and after any material change to your ground segment architecture.
  5. Designate a named executive accountable for NIS2 compliance with written terms of reference. Under Article 20, management body members must approve cybersecurity risk-management measures; this control creates the documented trail that approval requires.

Incident Handling — Article 21(2)(b) (Controls 6–10)

  1. Draft an incident response plan (IRP) specific to space ground operations, covering telecommand interference, unauthorised command injection, ground station ransomware, and satellite timing signal disruption. A generic IT IRP does not meet the Article 21 proportionality standard for this sector.
  2. Define what constitutes a “significant incident” for your ground segment operations using ENISA’s NIS2 Technical Implementation Guidance thresholds. Criteria must include loss of uplink control, confirmed command injection, and any incident with potential cross-sector cascade — for example, disruption to GNSS services affecting aviation or maritime navigation.
  3. Map your 24-hour early warning to a named on-call contact with authority to notify your national CSIRT. The Article 23 early warning obligation starts from the moment your organisation becomes aware of a significant incident — not from the moment it is confirmed.
  4. Document a command isolation procedure: the ability to cease uplink sessions from compromised or potentially compromised systems within a defined time window. This is the ground segment equivalent of network isolation — it limits blast radius in a command hijacking scenario.
  5. Run at least one tabletop exercise per year simulating a satellite command link compromise or ground station breach. Record attendance, findings, and remediation actions. Auditors expect documented evidence that your IRP has been tested, not just written.

Business Continuity — Article 21(2)(c) (Controls 11–14)

  1. Develop a business continuity plan (BCP) that explicitly covers space weather events as natural hazards under the Article 21(1) all-hazards requirement. Geomagnetic storms and solar energetic particle events can damage ground antenna electronics, cause satellite link degradation, and disrupt GNSS timing signals that ground station timing systems depend on. These are documented, foreseeable risks for ground operators — not exotic edge cases.
  2. Define recovery time objectives (RTOs) and recovery point objectives (RPOs) for mission-critical uplink and downlink circuits. Separately define these for satellite command authority (typically requiring near-zero RPO) versus data downlink (where some delay may be operationally acceptable).
  3. Maintain a backup mission control capability with documented hot or warm switchover procedures. Test the switchover at least annually under conditions that simulate primary site unavailability — including failure scenarios that originate in the supply chain, not only in direct cyber attack.
  4. Document the recovery scenarios your backup systems are tested against. Regulators increasingly scrutinise the scope of BCP testing: a plan tested only against ransomware scenarios but not against space weather or RF interference events is incomplete under the all-hazards standard.

Supply Chain Security — Article 21(2)(d) (Controls 15–19)

  1. Maintain a supplier register covering every COTS hardware component in your uplink chain, satellite bus integration toolchain, and software-defined radio stacks. ENISA’s 2025 Space Threat Landscape identifies supply chain compromise of COTS components as one of the primary attack vectors for ground segment infrastructure.
  2. Require a Software Bill of Materials (SBOM) from every software vendor in your ground segment toolchain. Review SBOMs quarterly — not only when a new version is deployed. A quarterly review cadence enables faster response to newly disclosed vulnerabilities in components already in production.
  3. Include NIS2-aligned cybersecurity clauses in contracts with all direct suppliers, specifying vulnerability disclosure obligations, incident notification timelines, and the right to audit security measures. Article 21(2)(d) requires you to assess “the security practices of each direct supplier” — a contract without security requirements cannot satisfy this obligation.
  4. Classify suppliers by criticality tier. Tier 1 suppliers (direct access to mission control systems or uplink hardware) must provide annual self-assessment evidence. Tier 2 suppliers (indirect access or data processing roles) require assessment at contract renewal.
  5. Trigger a supply chain risk review whenever a new supplier is onboarded or an existing supplier undergoes a significant change — acquisition, change of ownership, or material scope change. Supply chain risk is dynamic; a static annual review is insufficient for high-tempo procurement environments.

Security in System Acquisition and Development — Article 21(2)(e) (Controls 20–22)

  1. Apply security-by-design principles to all ground segment upgrades and new uplink terminal deployments. ENISA’s Space Threat Landscape 2025 identifies the design and assembly phases as the two highest-risk points for introducing vulnerabilities into ground infrastructure — security requirements must be defined before procurement, not retrofitted after.
  2. Test all software and firmware updates in an isolated environment before deployment to mission-critical uplink systems. This includes vendor-supplied firmware for COTS antenna controllers and satellite modems — not only custom-developed software.
  3. Maintain a vulnerability disclosure policy covering your ground segment software components, including any open-source software in your stack. Article 21(2)(e) explicitly requires “vulnerability handling and disclosure” as part of acquisition and development security.

Effectiveness Assessment — Article 21(2)(f) (Controls 23–25)

  1. Perform an annual internal audit of your Article 21 control set against a recognised framework. ISO 27001:2022 Annex A is the most widely accepted evidence framework; NIST CSF 2.0 is increasingly recognised by NCAs as an equivalent alternative for organisations outside the ISO certification track.
  2. Commission a third-party penetration test of ground segment networks, uplink paths, and remote access systems at least every 24 months. The test scope must include the interface between the IT corporate network and the operational technology (OT) ground segment — this boundary is the most common lateral movement path in ground station attacks.
  3. Update risk treatment plans within 30 days of any significant incident or major audit finding. Article 21(2)(f) requires assessing the “effectiveness” of measures — a treatment plan that is written but not updated after evidence of failure is not an effective measure.

Cybersecurity Training — Article 21(2)(g) (Controls 26–27)

  1. Deliver basic cyber hygiene training to all personnel with access to ground segment systems, with annual completion and records retained. This includes mission control operators, facility security staff, and IT administrators — not only the information security team.
  2. Provide role-specific training for mission control operators covering telecommand authentication procedures, anomaly escalation protocols, and the incident response plan. Generic cybersecurity awareness training does not meet the proportionality standard for personnel with direct command authority over satellites.

Cryptography and Encryption — Article 21(2)(h) (Controls 28–30)

  1. Implement authenticated encryption on all telecommand uplinks. The CCSDS Space Data Link Security (SDLS) protocol — developed by the Consultative Committee for Space Data Systems and used by major space agencies — specifies AES-128-GCM as the baseline algorithm for space link authenticated encryption. Implement this standard or an equivalent for all command uplinks and verify implementation in your annual effectiveness assessment.
  2. Establish a Key Management Service (KMS) for ground-to-space cryptographic keys, with documented rotation schedules, access controls, and procedures for emergency key revocation. Loss of control over telecommand cryptographic keys is an existential risk for a ground operator; key management governance must be documented to a standard a competent authority can audit.
  3. Enforce TLS 1.2 or later (TLS 1.3 preferred) on all internal ground segment network communications and external API connections. Document any legacy systems running below this standard as risk-accepted exceptions with a named approver and a remediation timeline.

Human Resources and Access Control — Article 21(2)(i) (Controls 31–33)

  1. Apply role-based access control to all mission control systems. Limit telecommand authority to the minimum number of personnel operationally required, documented in your access control policy and reviewed at least quarterly.
  2. Enforce a two-person integrity rule for any change to satellite commanding authority, encryption key material, or mission control system configuration. This control directly addresses the insider threat vector that ENISA identifies as one of seven primary threat profiles for space operations.
  3. Conduct background checks for all personnel with access to critical uplink and telecommand systems, documented before access is granted. Define “critical access” in your access control policy by reference to your asset criticality tiers (Control 3), not by job title alone.

Multi-Factor Authentication — Article 21(2)(j) (Controls 34–36)

  1. Enforce multi-factor authentication on all mission control system logins and all remote access to ground segment networks. Hardware tokens are the preferred second factor for mission control operators with telecommand authority — SMS-based and email-based OTP are not recommended for high-risk authentication in this context.
  2. Eliminate all single-factor authentication paths to satellite commanding interfaces. Document any exceptions as risk-accepted with a named management approver; set a remediation deadline of no more than 90 days from this checklist’s review date.
  3. Implement continuous session monitoring for all telecommand sessions and configure automatic timeout after no more than 10 minutes of inactivity. Log all telecommand sessions with timestamps and operator identity for the minimum retention period your national NCA requires — most EU jurisdictions are aligning to a minimum of 12 months for incident investigation purposes.

Incident Reporting: The Three-Stage Timeline

Article 23 establishes a three-stage incident notification timeline that applies to all essential and important entities, including space sector ground operators. The clock starts from the moment your organisation becomes aware of a significant incident — not when it is confirmed, contained, or fully understood.

Stage Deadline Required content Ground sector specifics
Early warning Within 24 hours of awareness Indicate whether unlawful or malicious acts are suspected; flag potential cross-border impact For incidents affecting GNSS-dependent services (navigation, timing), cross-border impact is almost always present; flag immediately
Incident notification Within 72 hours of awareness Initial assessment of severity, impact, and compromise indicators Include satellite command status, whether telecommand authority has been suspended, and any cascading service disruptions
Final report Within one month Detailed incident description, threat type, root cause, mitigations applied, cross-border impact Document supply chain involvement if any COTS component was a contributing factor

Your national CSIRT is the primary notification recipient. If your ground infrastructure forms part of or interfaces with Galileo services, EUSPA receives incident reports under the EU Space Act proposal (Article 93) in addition to national CSIRT notification — though this remains a proposal pending final adoption. For guidance on which incidents cross the “significant incident” threshold and how to write a compliant notification, see our Article 23 incident notification guide and the space sector incident response guide.

The EU Space Act: What Ground Operators Should Do Now

The European Commission published its EU Space Act proposal in June 2025, introducing a sector-specific resilience framework for all space operators. The Commission’s proposal positions the Space Act as lex specialis, meaning its cybersecurity requirements would replace NIS2 Article 21 obligations for operators that qualify as essential or important entities under both frameworks. The Council of the EU’s December 2025 compromise text takes a more cautious approach: it frames the two instruments as “without prejudice” to each other, requiring authorities to cooperate to ensure requirements are aligned rather than having one instrument displace the other.

Parliament’s ITRE Committee has proposed a third approach: amending NIS2 directly to extend its scope to all space activities, making a separate Space Act cybersecurity chapter unnecessary.

The practical consequence for ground operators in 2025 and 2026 is straightforward: NIS2 is the current law; the EU Space Act is a proposal. Build your compliance programme against NIS2 Article 21 now. When the Space Act enters force — likely no earlier than 2027 given trilogue timelines — the gap analysis between the two frameworks will be modest for operators who have already implemented a proportionate Article 21 baseline. One Space Act requirement to anticipate: the proposal includes threat-led penetration testing (TLPT) before the first satellite launch or constellation batch, and every three years thereafter — a more structured testing obligation than Article 21(2)(f)’s effectiveness assessment currently requires.

Multi-Jurisdiction Ground Station Operators

A commercial operator running ground stations in Germany, Spain, and France does not face three identical NIS2 compliance programmes — it faces three different NCAs, each with their own transposition nuances, registration procedures, and supervision timescales. Germany’s NIS2 implementing law entered into force in December 2025 with BSI as the primary cybersecurity authority. France’s ANSSI operates a self-registration portal (si-reg.anssi.fr) for entities that identify themselves as in-scope. Italy’s ACN is the designated authority with registration obligations that began in October 2024.

Article 26 of the directive provides a jurisdiction rule for entities operating in multiple member states: your main establishment (the place where you make cybersecurity risk-management decisions, typically your registered head office or principal place of business) determines your lead NCA. That NCA coordinates with host-state authorities. In practice, ground operators with facilities in multiple member states should register with their lead NCA promptly and notify host-state authorities of their cross-border presence. Failure to register is itself an infringement under most national transpositions. For a full guide to the supply chain security obligations that apply across your supplier base, see our space sector supply chain security guide.

Frequently Asked Questions

Does NIS2 apply to satellites themselves?

No. NIS2 Annex I, Section 11 covers operators of ground-based infrastructure. Satellites in orbit, their onboard software, and spacecraft hardware are outside NIS2’s scope. Satellite manufacturers placing digital products on the EU market face the Cyber Resilience Act (EU Regulation 2024/2847) rather than NIS2. Ground operators who also manufacture satellite components may have obligations under both frameworks, but these apply to different parts of the business.

How does the Cyber Resilience Act interact with NIS2 for space operators?

The CRA applies to “products with digital elements” placed on the EU market — hardware and software products including satellite components. NIS2 applies to the operator of the ground-based infrastructure as a service provider. A company that both manufactures satellite hardware and operates ground stations faces CRA product security obligations for its manufactured components and NIS2 operational security obligations for its ground segment. The two frameworks address different activities and do not overlap; there is no lex specialis displacement between them.

Do I need to register with EUSPA under NIS2?

No. NIS2 entity registration is with your national NCA — not with EUSPA. EUSPA’s Security Accreditation Board governs operators of EU Space Programme infrastructure (Galileo, EGNOS, GOVSATCOM). Commercial ground operators independent of the EU Space Programme register with their member state NCA under Article 3 of the directive.

When does the EU Space Act change my NIS2 obligations?

Only when it enters into force, which requires completing the EU legislative process (trilogue between Commission, Council, and Parliament) and a transition period — not expected before 2027 at the earliest. Until then, NIS2 applies fully. Monitor the European Space Act website and your national NCA’s publications for updates as trilogue progresses.

What if I operate a very small ground station with fewer than 50 employees?

Micro and small enterprises (below 50 employees and below €10 million annual turnover) are generally outside NIS2’s scope. However, member states may designate specific small entities as in-scope where their disruption would have significant societal or economic impact. A small operator providing critical GNSS correction signals to aviation or maritime navigation may be designated regardless of size. Verify with your national NCA if you provide services where disruption would cascade to other critical sectors.

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

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: