Satellite ground station security: Protecting command links, mission control and antenna sites

For most satellites the ground segment is the only path to the spacecraft, so whoever controls the mission operations centre, the TT&C chain or the keys behind them can command the satellite. Ground systems run on ordinary servers, networks and remote access tools, yet they sit next to RF equipment, leased antenna sites and specialist software with a narrow supply chain. This guide goes deeper than the overview in the Satellite IoT and Satellite Communications Security Guide: it covers the ground segment architecture, how to protect commanding, identity and remote access for operators and machines, segmentation, logging, ground station as a service, supply chain, detection and recovery. It is written for satellite operators, ground station providers, hosted payload customers and the security teams supporting them, and it follows NIST IR 8401, which applies the NIST Cybersecurity Framework to satellite command and control.

Key takeaways

• Treat the ground segment as the security boundary of the spacecraft. NIST IR 8401 assumes the ground segment is the only communication path to the space segment and may have to compensate for controls the satellite cannot carry.
• Isolate the systems that talk to the spacecraft. Components that send commands or receive telemetry should sit in their own zone, reached only through defined, logged conduits.
• Protect commanding, not only the network. Encrypted and authenticated uplinks with anti-replay counters, plus two-person control for high-risk commands, limit what a compromised workstation can do.
• Machine identities and keys are crown jewels. Command encryption keys, service accounts between mission software components and cloud API credentials for ground station services need the same controls as privileged human access.
• Plan for remote access abuse. The KA-SAT attack began with a misconfigured VPN appliance that led into the trusted management segment.

Ground segment architecture and where it fails

NIST IR 8401 describes the commercial ground segment in terms of a few functional parts. Mapping your own estate to these parts is the first step in scoping controls.

IR 8401 also records assumptions that shape the defence: legacy components may predate modern security practice, specialised equipment has a limited supply chain, and space vehicle size, weight and power limits may mean some controls must sit on the ground instead. Its scope is the operational phase; the space and user segments are out of scope, though their requirements affect the ground. For the wider sector view, see the Space and Satellite Cybersecurity Guide.

Protecting the command path

An attacker who reaches a commanding workstation should still be unable to send an arbitrary command that the spacecraft accepts.

• Link encryption and authentication: IR 8401 notes that command uplinks are typically encrypted and authenticated, and recommends a command counter or nonce to resist replay and spoofing. Use the authenticated encryption mode supported by your spacecraft's link security implementation and confirm that anti-replay checking is enabled on board, not only specified.
• End-to-end protection across trust boundaries: where commands pass through a third-party ground station or network, encrypt and authenticate them end to end so the intermediary cannot read or alter them.
• Two-person integrity for high-risk commands: IR 8401 suggests two-person controls for high-risk commands. Define the list: orbit manoeuvres, attitude changes, software or table uploads, key changes, payload safety overrides.
• Command validation: check commands against the command database and constraints (allowed parameter ranges, sequence rules) before uplink, and review changes to the command database through change control.
• RF resilience: IR 8401 points to spread spectrum and error detection and correction to help against jamming. Pair it with the physical layer guidance in the Physical Layer and Wireless Jamming Guide.

Identity, keys and remote access

Ground segments depend on a small number of people and a larger number of machine identities: services between flight software, front-end equipment and databases, automation scripts that schedule passes, and cloud credentials used to book antenna time or receive data.

Remote access is the most common way in. Remove VPN profiles that are not in use: the Colonial Pipeline Ransomware Attack started with a legacy VPN profile that had never been disabled and accepted a password without MFA. See the OT Remote Access Guide and the Service Account Security Guide.

Lessons from the KA-SAT attack

Viasat's own overview of the 24 February 2022 attack on its KA-SAT network shows how a ground-side compromise reaches users without touching the satellite. The attacker exploited a misconfigured VPN appliance to gain remote access to the trusted management segment, moved laterally to a segment used to manage and operate the network, and then used legitimate, targeted management commands on many residential modems at once. Those commands overwrote key data in the modems' flash memory. Tens of thousands of modems dropped off the network, and Viasat shipped nearly 30,000 replacement modems to distributors.

• Management planes are command paths: legitimate tools issuing bulk commands did the damage. Apply rate limits, staged rollout and approval to bulk operations.
• VPN configuration is a ground segment control: review appliance configuration against a hardened baseline and alert on new remote sessions into management zones.
• Recovery needs spares and gold images: over-the-air fixes were not enough for every device, so physical replacement was part of recovery.

Segmentation and data flows

1. Map every flow, including RF and optical links. IR 8401 maps this to maintaining data flow representations. Include links to leased sites, cloud services and payload customers.
2. Create zones by function: corporate IT, mission planning, MOC commanding, PCC, front-end and baseband equipment, antenna control, and customer portals. IR 8401 recommends segmenting by network, user, device and application to limit lateral movement, and isolating components that communicate directly with the space segment.
3. Define conduits: allow only named protocols between zones, through firewalls or data diodes where one-way telemetry flow is enough, and log denied traffic.
4. Separate payload customers: a hosted payload customer's network should reach only its PCC zone, never bus commanding.

The zone and conduit approach in IEC 62443 transfers well to ground segments. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Ground station as a service and shared antennas

Many operators no longer own every antenna. They book contacts on provider networks and receive data into their own cloud accounts. The ground segment then extends into the provider's systems and your cloud tenancy.

• Shared responsibility: agree in writing who protects the antenna site, the baseband processing, the delivery path and the customer account. Ask for independent assurance reports covering the antenna network.
• Account security: treat the cloud account that schedules contacts and receives data as part of the MOC. Restrict who can change mission profiles, satellite configurations and data delivery endpoints, and log every change.
• Data integrity: encrypt and authenticate commands end to end so the provider's network carries only protected traffic, and verify downlinked data integrity before it reaches mission systems.
• Exit plan: keep a second provider or owned antenna available for critical commanding if a provider account is suspended or compromised.

Supply chain and legacy systems

• Supplier assessment: IR 8401 recommends assessing supply chain risk processes and suppliers, considering multiple sources for hardware and software, screening software bills of materials and contracting for security across the satellite's lifespan.
• Counterfeit and access paths: assess suppliers for counterfeit risk and for the access they hold into your environment, including remote support tools.
• Legacy compensating controls: where mission software cannot be patched or supports only weak authentication, isolate it, restrict who can reach it and monitor it closely.
• Insiders: IR 8401 calls for periodic background checks, timely deprovisioning, least privilege, separation of duties and specialised training for privileged users.

Detection, logging and response

IR 8401 asks operators to log TT&C data, event chains required by regulation and data about repositioning or on-orbit anomalies, to use standard formats, keep logs for long periods for forensics and correlate events across sources. In practice:

• Command audit trail: every command uplinked, who authorised it, from which console, and the spacecraft's acknowledgement.
• Telemetry anomalies: unexpected mode changes, rejected commands and authentication failures reported by the spacecraft are security signals as well as engineering ones.
• Ground IT signals: new remote sessions into MOC zones, logons outside planned passes, changes to command databases and key stores, bulk operations on terminals.
• Response: pre-agree safe modes and the decision authority to stop commanding, switch to a backup MOC or ground station, and change keys. Coordinate with providers and payload customers when an incident is declared.

Metrics that show the controls are working:

• Percentage of high-risk commands executed under two-person control.
• Number of standing remote access accounts into MOC and antenna zones (target: none outside a broker).
• Mean time to detect an unplanned remote session into a commanding zone, measured through exercises.
• Share of mission components with unique, vaulted service credentials.
• Results of the last backup MOC or ground station failover test.

Implementation roadmap

1. Inventory and flows (first): list hardware, software, firmware, cloud resources, external systems and data flows, as IR 8401 recommends under Asset Management.
2. Close remote access gaps: remove unused VPN profiles and vendor accounts, enforce MFA and broker access to commanding zones.
3. Segment: isolate MOC commanding and antenna control first; test each new rule in monitor mode during non-critical passes and keep the previous rule set ready to restore.
4. Protect commanding: confirm link authentication and anti-replay status, introduce two-person control for the defined command list, move keys into HSMs.
5. Machine identities: replace shared and embedded credentials between mission components and in cloud ground station accounts.
6. Detect and exercise: deploy the logging above and run a tabletop and a live failover to the backup ground path at least yearly.

Decision guidance

• Own versus rent antennas: owned sites give full control but carry physical security and maintenance burden; ground station as a service shifts that to a provider but adds account and shared responsibility risk. Many operators keep owned or contracted backup paths for commanding and rent capacity for data downlink.
• Small operators and new space start-ups: concentrate on account security for cloud services, MFA on all remote access, a single isolated commanding zone and end-to-end command protection before investing in a large SOC capability.
• Large operators: add separate PCC zones per payload customer, a dedicated space security operations function and supplier assurance across many sites.

Common failure patterns

• VPN as the boundary: a single remote access appliance, once misconfigured or exploited, opens the management segment, as at KA-SAT.
• Shared console accounts: operators share a commanding login, so no one can tell who sent a command.
• Keys in files: command encryption keys or key material held on general-purpose servers rather than HSMs.
• Payload customers on the bus network: hosted payload access is not separated from satellite bus commanding.
• Cloud account outside security scope: the ground-station-as-a-service account is run by the mission team without the privileged access controls used on premises.

Framework mapping

IR 8401 maps to CSF version 1.1 subcategories. The table maps the same themes to CSF 2.0 and SP 800-53 Rev. 5, with relevant ATT&CK techniques.

Practitioner checklist

• Map MOC, PCC, TT&C, antenna sites and cloud services against the IR 8401 components and record every data flow.
• Isolate systems that talk to the spacecraft in their own zone with logged conduits.
• Confirm uplink authentication and anti-replay are enabled on board and tested.
• Define the high-risk command list and require two-person control for it.
• Move command keys into HSMs and run key changes as documented ceremonies.
• Remove unused VPN profiles and vendor accounts; broker all remote access to commanding zones.
• Give each mission component a unique, vaulted service credential.
• Bring ground-station-as-a-service accounts under privileged access controls and change alerting.
• Log commands, authorisations and spacecraft acknowledgements, and keep them for forensics.
• Test failover to a backup MOC or ground path at least once a year.

Standards and references

• NIST: IR 8401 Satellite Ground Segment: Applying the Cybersecurity Framework to Satellite Command and Control
• NIST: IR 8270 Introduction to Cybersecurity for Commercial Satellite Operations
• ENISA: Space Threat Landscape 2025
• Viasat: KA-SAT Network Cyber Attack Overview
• The Aerospace Corporation: SPARTA Space Attack Research and Tactic Analysis
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Satellite IoT and Satellite Communications Security Guide · Space and Satellite Cybersecurity Guide · OT Remote Access Guide · HSM Deployment and Operations Guide