Space and Satellite Cybersecurity Guide

A satellite you cannot reach physically is only as secure as the ground systems, radio links and credentials that command it. The Viasat KA-SAT incident of February 2022, a widely reported attack on a commercial satellite network, never touched the satellite: it entered through a misconfigured VPN appliance on the ground and used legitimate management commands. This guide covers the four segments of a space system, the main threats at a level suitable for defenders, what the KA-SAT incident teaches, how to secure the ground segment and its identities, how to protect telemetry, tracking and command (TT&C) links, and how SPARTA, NIST IR 8401 and Space Policy Directive-5 fit together. It is for satellite operators, ground station and mission operations teams, and security teams that depend on satellite communications or positioning, navigation and timing (PNT), and contains no attack procedures.

Key takeaways

• Defend the ground first. CISA's Space Systems Critical Infrastructure Working Group calls the ground segment "the most accessible and vulnerable part of the space infrastructure", and KA-SAT showed why.
• Command authentication is the crown jewel. SPD-5 asks operators to safeguard command, control and telemetry links "using effective and validated authentication or encryption measures" for the whole mission life.
• Encryption is not enough on its own. An attacker inside the mission operations centre can send correctly encrypted commands, so identity, least privilege and two-person control on the ground matter as much as the crypto on the link.
• Key management outlives the launch. TT&C keys must be generated, stored, rotated and zeroised for the whole mission, with no option to swap hardware after launch.
• Use the space-specific frameworks. SPARTA and ESA's SPACE-SHIELD describe space attack techniques; NIST IR 8401, 8441 and 8270 translate the Cybersecurity Framework into ground segment and hybrid network controls.

The four segments and what each exposes

Space systems are usually described in four segments. Ownership is often split: a mission may own the satellite, rent antenna time from a commercial ground station provider, host a third-party payload and sell capacity through distributors who manage terminals. NIST IR 8441 calls these hybrid satellite networks and notes that "the elements of an HSN may have varying levels of assurance".

NIST IR 8401 scopes its profile to the ground segment only, and notes that size, weight and power (SWaP) limits on the spacecraft can make some controls impractical in orbit, so the ground segment often has to compensate.

Threats at a high level

The Aerospace Corporation's SPARTA (Space Attack Research and Tactic Analysis) matrix exists to "provide unclassified information to space professionals" about how spacecraft can be compromised. It organises techniques under nine tactics from ST0001 Reconnaissance to ST0009 Impact, with IDs such as EX-0016 for jamming. The table groups the threats defenders most often plan for, with current SPARTA technique IDs.

Some SPARTA entries are identity problems in another vocabulary: REC-0003.04 and PER-0005 Valid Credentials, and PER-0004 Replace Cryptographic Keys. An attacker holding operator credentials or able to load their own keys needs no exploit.

ESA's parallel knowledge base, SPACE-SHIELD (Space Attacks and Countermeasures Engineering Shield), is "a custom instance of the ATT&CK Website". Its IDs (for example T2008 "Direct Attack to Space Communication Links") are ESA's own, not MITRE ATT&CK IDs.

Lessons from the Viasat KA-SAT attack

On 24 February 2022, about an hour before Russia's invasion of Ukraine according to the UK government, Viasat's KA-SAT consumer broadband service suffered a partial outage. Viasat's own overview, published on 30 March 2022, describes the sequence:

• Entry: a ground-based intrusion exploited "a misconfiguration in a VPN appliance" to reach the trusted management segment of a consumer partition operated by Skylogic, a Eutelsat subsidiary, then moved laterally to the segment used to operate the network.
• Action: legitimate-looking management commands sent to large numbers of residential modems at once, overwriting key data in their flash memory so they could not reconnect. Tens of thousands of modems dropped off; Viasat shipped nearly 30,000 replacements.
• What was not hit: Viasat found no evidence that the satellite or its supporting ground infrastructure was directly compromised, or of supply chain interference.
• Collateral impact: the UK government noted that "wind farms in central Europe and internet users were also affected".

On 10 May 2022 the EU, UK, US and other allies attributed the attack to Russia; the NCSC assessed it "almost certain Russia was responsible". SentinelLabs identified AcidRain, "an ELF MIPS malware designed to wipe modems and routers", and later noted that Viasat confirmed its use in the attack.

The lessons are ordinary enterprise lessons applied to a space network: remote access appliances are the front door, management planes need their own segmentation and strong authentication, and any system that can command thousands of terminals at once is privileged. The same entry point appears in enterprise incidents such as the Ivanti Connect Secure exploitation. See the VPN Security Guide.

Securing the ground segment

SPD-5 asks for "protection of ground systems, operational technology, and information processing systems" using practices aligned with the NIST Cybersecurity Framework: segregation, patching, physical security, limits on portable media, antivirus, training and protection "including from insider threats". In practice:

• Segment by function: separate corporate IT, the MOC, PCCs, terminal or network management, and antenna control. NIST IR 8401 (PR.AC-3) suggests isolating components that communicate with the space segment, using privileged access components, role-based access control or disconnection from external networks. See the Network Segmentation Guide.
• Harden remote access: no internet-exposed management interfaces; remote access only through a monitored, MFA-protected path; vendor access time-limited and recorded.
• Treat the ground station as OT: antenna controllers, modems and RF equipment have long lifecycles and narrow patch windows, so use industrial-style compensating controls. See the OT Security Guide.
• Detect at command level, not just network level: CISA's working group recommends an intrusion detection system that can flag unauthorised manoeuvres or malicious commands before the spacecraft reaches a downlink site.
• Protect remote maintenance: NIST IR 8401 (PR.MA-2) recommends end-to-end encryption for remote maintenance and says it is "not appropriate for the MOC/PCC to have read access at all levels".
• Physical security: SPD-5 includes intrusion detection across antennas, terminals, routers and power supplies.

Where identity fits: operators, commands and keys

Most ground segment controls come down to who, or what, can cause a command to be sent.

Ground station operator accounts

• Named, provisioned and revoked accounts: NIST IR 8401 PR.AC-1 asks for credentials to be issued, verified, revoked and audited. Shared console logins on operations workstations defeat attribution.
• Least privilege with an emergency profile: PR.AC-4 asks for access limited to satellite operations tasks, with separate definitions for normal and emergency situations. Build a break-glass process for anomaly response instead of granting everyone emergency rights. See the Break-Glass Account Guide.
• Context-aware authentication: PR.AC-6 suggests considering location and duty hours; PR.AC-7 states "preventing unauthenticated communication should be a high priority" and suggests MFA. Use phishing-resistant MFA for operators and administrators.
• Personnel assurance: PR.IP-11 suggests background checks for MOC and PCC staff, and PR.AT-2 specialised training for privileged users.
• Third-party ground stations: when using commercial ground station services, the provider's operators and your mission's API credentials for scheduling passes are part of your attack surface (SPARTA RD-0002.02 3rd Party Ground System). Contract for MFA, logging and incident notification. See the Third-Party Access Guide.

Command authentication and authorisation

• Authenticate every command frame: NIST IR 8401 notes that "command uplinks are typically encrypted and authenticated" and recommends a command count or nonce against replay.
• Two-person integrity: PR.DS-6 suggests "two-person integrity controls for high-risk, high-sensitivity commands", such as propulsion, key loads, software uploads and disabling fault protection.
• Machine identities in the chain: scheduling, flight dynamics and command generation services hold credentials that can queue commands; inventory, own and scope them. See the Service Account Security Guide.

Key management for TT&C links

• Generate and store in hardware: keep master and command keys in HSMs or equivalent validated modules; NIST IR 8401 PR.DS-8 points to TPMs and FIPS 140-3 anti-tamper controls.
• Plan the whole mission life: preload multiple keys, define over-the-air rekeying with authenticated key-load commands, and decide in advance what triggers a rekey (staff departure, suspected ground compromise, algorithm weakness).
• Zeroisation: PR.DS-3 says zeroisation of cryptographic variables needs "special consideration", including at end of life and when ground equipment is decommissioned.
• Guard key replacement: SPARTA PER-0004 Replace Cryptographic Keys describes attackers loading their own keys to lock out the owner. Key-load commands deserve the strictest two-person control and alerting.
• Crypto agility: missions launched now will fly through the post-quantum transition. See the Cryptographic Key Management Guide and the Post-Quantum Readiness Guide.

Protecting the links and PNT

• Link-layer security: the CCSDS Space Data Link Security (SDLS) protocol, CCSDS 355.0-B, provides authentication, encryption or authenticated encryption for telecommand and telemetry frames using security associations. ESA notes that "CCSDS SDLS protocol incorporates anti-replay protection through the use of sequence numbers." Authenticated encryption on the uplink is the baseline; encrypt downlinks that carry sensitive telemetry or mission data.
• Jamming resilience: SPD-5 lists signal strength monitoring, secured transmitters and receivers, and authentication or validated encryption. CISA's working group points to controlled reception pattern antennas (CRPA) for uplinks and downlinks, and to GPS receivers that null ground-based signals for the user segment.
• PNT resilience: NIST IR 8323 Rev. 1, the Foundational PNT Profile, applies the Cybersecurity Framework to systems that depend on positioning, navigation and timing, which can be disrupted or manipulated by natural, accidental or deliberate causes. Identify which systems depend on GNSS time or position, add independent cross-checks (terrestrial time sources, inertial sensors), and define holdover behaviour.

Space segment and supply chain

• Signed on-orbit updates: treat the upload path as the most powerful command (IA-0007.01). Sign images, verify on board before activation, keep a known-good image and a tested fallback.
• Secure boot and memory protection: guard against boot memory compromise (EX-0004) and rootkit or bootkit persistence. See the Firmware and Boot Security Guide.
• Bus segregation: CISA's working group recommends network segmentation for the space segment (SP 800-53 AC-4, AC-10, SC-7) and least functionality (CM-7), which limits what a compromised hosted payload can reach.
• Supply chain: SPD-5 calls for "requiring sourcing from trusted suppliers" and detecting counterfeit equipment; CISA's working group recommends software and hardware bills of materials, pre-deployment testing and contractual security terms (SR-2 to SR-4). See the SLSA and Build Provenance Guide.

Choosing frameworks and scaling to the mission

• Small missions and CubeSats: SPD-5 says measures should be proportionate to mission, vehicle size, duration and orbital regime. Proportionate still means authenticated telecommand; the cheapest wins are on the ground (MFA, segmentation, key custody) and in requiring the ground station provider to meet them.
• Large operators and constellations: add command-level intrusion detection, security monitoring joined to operations and automated fleet key management.
• Consumers of space services: focus on terminal management, incident notification terms, PNT dependency mapping and fallback connectivity.

Implementation roadmap

1. Inventory: list ground sites, MOC and PCC systems, terminal management platforms, every account and service credential that can queue or send commands, and every TT&C key and where it lives.
2. Close the front door: remove internet-exposed management interfaces, enforce MFA on remote access and operator accounts, and remove dormant VPN accounts; a single unused account opened the Colonial Pipeline attack.
3. Segment: separate IT, operations and terminal management; test rules in monitor mode before enforcing, with a documented rollback for each change during a pass.
4. Protect commands: confirm authentication and anti-replay are active on every uplink, in every spacecraft mode; add two-person control for hazardous commands, piloted first on a flatsat or simulator.
5. Fix key custody: move keys into HSMs, document rekey and zeroisation procedures, and rehearse a rekey against a simulator before any on-orbit use, with a preloaded fallback key.
6. Monitor: join command logs, ground system logs and RF interference alerts, with rules for out-of-plan commands.
7. Exercise: run tabletops for ground compromise and jamming, including how to regain positive control, which SPD-5 expects plans to cover.

Detection and measurement

Log operator authentication and privilege changes, every command with the identity behind it, rejected commands reported in telemetry, key loads, fault management changes, software uploads, remote access sessions and RF interference. Useful metrics:

• Authenticated uplink coverage: share of spacecraft and modes where command authentication and anti-replay are enforced (target 100%).
• Operator MFA coverage: share of ground operator and administrator accounts on phishing-resistant MFA.
• Unplanned commands: count of commands not traceable to an approved plan or procedure, and time to investigate each.
• Key hygiene: keys past their planned rotation date, and keys held outside HSMs.
• Interference response: time from interference detection to geolocation and mitigation.
• Exposure: internet-reachable ground management interfaces (target zero).

Common failure patterns

• Assuming the RF link is the attack surface: KA-SAT came through a VPN appliance and a management network, not the radio link.
• A flat management plane: one system that can reach every terminal turns one intrusion into a fleet-wide outage.
• Encryption without ground identity controls: CISA's working group notes that encryption alone does not stop hijacking when an attacker controls the system that holds the keys.
• Shared operator logins and no two-person rule: nobody can say who sent a command, and one compromised account can do anything.
• Keys on file shares: TT&C keys copied during integration and never cleaned up.
• Disabling authentication for testing: checks turned off during commissioning or in safe mode and left that way.

Framework mapping

NIST IR 8401 subcategories come from the report; AC-4, AC-10, SC-7, SR, CM-7, AU, CA and IR controls are those CISA's working group names, and the remaining SP 800-53 controls are our mapping.

Practitioner checklist

• Map all four segments, with the owner of each component and each interface between owners.
• Remove internet exposure from ground management interfaces and enforce MFA on all remote access.
• Give every operator a named account, phishing-resistant MFA and least privilege, with a separate emergency profile.
• Inventory service accounts and automation that can queue or send commands, and assign owners.
• Confirm command authentication and anti-replay on every spacecraft, in every mode, including safe mode.
• Require two-person control for key loads, software uploads, propulsion and fault management changes.
• Hold TT&C keys in HSMs, with documented and rehearsed rekey and zeroisation procedures.
• Log every command with the identity behind it and alert on commands outside the approved plan.
• Require SBOM, HBOM, security terms and incident notification from suppliers and ground station providers.
• Exercise recovery of positive control after a ground compromise and after sustained jamming.

Standards and references

• The White House (Federal Register): Space Policy Directive-5, Cybersecurity Principles for Space Systems
• NIST: IR 8401, Satellite Ground Segment: Applying the Cybersecurity Framework to Satellite Command and Control
• NIST: IR 8441, Cybersecurity Framework Profile for Hybrid Satellite Networks (HSN)
• NIST: IR 8270, Introduction to Cybersecurity for Commercial Satellite Operations
• CISA: Recommendations to Space System Operators for Improving Cybersecurity
• The Aerospace Corporation: Space Attack Research and Tactic Analysis (SPARTA)
• ESA: SPACE-SHIELD, Space Attacks and Countermeasures Engineering Shield
• Viasat: KA-SAT Network Cyber Attack Overview

Related NHI Mgmt Group resources: OT and ICS Identity and Access Guide · Device and IoT Identity Guide · Privileged Access Management Guide · Incident Response Guide