Executive Summary

Satellites are now embedded in the daily operation of communications, navigation, banking, aviation, agriculture, weather forecasting, emergency response and national defence. A single compromised spacecraft or, far more commonly, a single compromised ground system can ripple outward into terrestrial critical infrastructure that has nothing obvious to do with space. That coupling is what makes satellite cybersecurity a strategic problem rather than a niche engineering concern.

This threat model describes the satellite ecosystem as five interacting parts: the space segment, the link segment, the ground segment, the user segment and the supply chain, all governed by an eight-phase mission lifecycle that runs from design to decommissioning. It enumerates the threats that apply to each part, maps them with STRIDE, positions the relevant threat actors, traces a representative end-to-end attack path, and recommends a layered target-state architecture. The analysis is grounded in published guidance from both sides of the Atlantic, including ECSS-E-ST-80C (ECSS 2024), NIST IR 8270 (Scholl and Suloway 2023), NIST IR 8401 (Lightman et al. 2022), Space Policy Directive-5 (The White House 2020), the Aerospace Corporation SPARTA matrix (Aerospace Corporation 2022) and Canada’s ITSG-33 (CSE 2012).

Scope and Methodology

The model is deliberately broad. It treats the satellite as one node in a larger socio-technical system and assesses every place where a defender has something to protect or an attacker has something to reach. Scope follows the structure set out in ECSS-E-ST-80C and SPD-5, both of which define a space system as the combination of space, ground and link elements operated across a lifecycle (ECSS 2024; The White House 2020).

2.1 Scope

• Space segment: satellite bus, payloads and sensors, on-board computer and command-and-data handling, flight software and firmware, radios and transponders, attitude control and propulsion.
• Link segment: telemetry, tracking and command (TT&C) uplink and downlink, payload data downlink, inter-satellite crosslinks, and the authentication and encryption applied to them.
• Ground segment: mission operations centre, ground stations and antennas, operator workstations, network infrastructure, management and maintenance systems, and remote access paths.
• User segment: user terminals and VSATs, positioning, navigation and timing (PNT) receivers, and the downstream applications that consume satellite data.
• Supply chain: hardware and software suppliers, integrators, launch providers and third-party service vendors, including cloud.
• Mission lifecycle: design, development, testing, integration, launch, operations, maintenance and decommissioning.

2.2 Methodology

The model combines general-purpose threat modelling methods with frameworks built specifically for space. Each method answers a different question, and together they cover identification, classification, pathing and control.

System Overview

A satellite system is a distributed control system whose plant happens to be in orbit. Operators on the ground send commands up, receive telemetry and payload data down, and rely on continuous positive control of a vehicle they cannot physically reach. The architecture below shows the segments in scope and the cross-cutting supply chain and lifecycle that touch all of them.

Mission type and orbit shape the risk profile. Low Earth orbit constellations favour large numbers of lower-cost, software-defined satellites with frequent ground contact and many user terminals, which widens the attack surface. Geostationary assets are fewer, more valuable and longer-lived, which raises the impact of a single compromise and the cost of any cryptographic decision made at design time. Navigation and timing missions add a distinctive concern, because spoofing or denial of their signals affects users who never interact with the operator at all.

Security Objectives

Classic confidentiality, integrity and availability still apply, but space systems add objectives that enterprise IT rarely states explicitly. Chief among them is positive control: the operator must always be able to command the vehicle and, after any incident, recover that ability. SPD-5 makes the retention and recovery of positive control a first-order principle (The White House 2020).

Asset Inventory

Assets are grouped by segment. Sensitivity reflects the consequence of compromise rather than the dollar value of the component, which is why cryptographic keys and the command path rank above most hardware.

Trust Boundaries and Attack Surface

Trust boundaries are the points where data moves between zones that trust each other to different degrees. They are where authentication, encryption and validation must be enforced, and they are exactly where the Viasat attackers operated: across the boundary between an exposed remote-access service and the trusted management network behind it. The data flow diagram below shows the four primary boundaries and the flows that cross them.

6.1 Trust boundaries

• TB-1 Enterprise / IT boundary: separates general corporate IT, email and internet-facing services from anything that touches operations. The most common foothold for an external attacker.
• TB-2 Mission operations boundary: the trusted management network where commands originate. Crossing into it should require strong authentication, segmentation and privileged-access management.
• TB-3 RF / space link boundary: the radio frequency interface. It is physically open to anyone with the right antenna, so authentication and encryption of the link are the only real defence.
• TB-4 Spacecraft on-board boundary: the vehicle itself, which must reject any command that is not authenticated, regardless of where it appears to come from.

6.2 Attack surface by segment

Threat Actors

Space systems attract an unusually wide range of adversaries because the consequences span commercial, civil and military domains at once. The map positions the main actor classes by capability and hostile intent; bubble size reflects the potential mission impact if the actor succeeds.

Threat Enumeration and STRIDE Mapping

The matrix below shows where each STRIDE class materially applies across the main asset groups. It is a targeting aid: dark cells are where defenders should expect the most pressure.

The enumeration table covers the full set of threats requested for assessment, each tied to a STRIDE class, the segment it targets and an illustrative technique drawn from ATT&CK, ATT&CK for ICS or SPARTA.

STRIDE key: S spoofing, T tampering, R repudiation, I information disclosure, D denial of service, E elevation of privilege.

Attack Paths and Kill Chain

Individual threats become dangerous when they chain. The clearest public example is the Viasat KA-SAT attack of 24 February 2022, which is worth studying precisely because it is fully documented and because it shows the ground segment, not the spacecraft, as the decisive target. The stages below align to MITRE ATT&CK and the Aerospace SPARTA tactics.

In the real incident, attackers exploited a misconfigured VPN appliance to reach the trusted management segment of the KA-SAT network operated on Viasat’s behalf, moved laterally, and then issued legitimate, targeted management commands that pushed the AcidRain wiper to a large number of residential modems (Guerrero-Saade and van Amerongen 2022). The wiper overwrote modem memory and forced reboots, leaving tens of thousands of terminals inoperable across Europe and incidentally cutting remote monitoring to roughly 5,800 wind turbines in Germany. The decisive move was not exotic: it was the abuse of a trusted, authorized management path after a routine perimeter failure. In May 2022 the European Union and Five Eyes partners, including Canada, attributed the operation to the Russian state (Council of the EU 2022).

Threat, Abuse and Misuse Cases

10.1 Threat scenarios

10.2 Abuse cases

Abuse cases describe what an attacker wants to achieve. The principal abuse cases are: take or deny control of the vehicle; forge or replay commands; steal payload data or keys; deny service to users; and establish durable, hidden access for later use. Each is the inverse of a security objective in Section 4.

10.3 Misuse cases

Misuse cases involve legitimate features used in unintended ways. Examples include the firmware update mechanism used to deliver malicious code, the management command path used to disable rather than operate devices (as in the Viasat case), debug and test interfaces left enabled in flight, and over-broad operator roles used to act outside an individual’s remit. Misuse cases are dangerous because the activity looks authorized, which is why authentication alone does not catch them and why logging, segmentation and anomaly detection matter.

Security Controls

Mature operators apply controls in depth, from governance down to the spacecraft. The model below shows the layering: each ring must hold even if the one outside it fails, with positive control of the vehicle as the innermost objective.

The table summarizes the control domains assessed across ESA, NASA, CSA and commercial operators, with the standards that define them. These are the controls a credible programme is expected to demonstrate.

Residual Risks

Even with strong controls, some risk remains. The heat map plots the principal residual risks after the recommended controls are applied. Several stay elevated not because controls are weak but because the underlying conditions, long asset lifetimes, an open RF medium and a deep supply chain, cannot be fully engineered away.

Recommended Security Architecture

The target-state architecture applies controls at every segment and binds them with cross-cutting capabilities. The design principle is straightforward: assume the perimeter will be breached, and ensure that no single failure hands an attacker positive control of the vehicle.

Three choices do most of the work. First, the spacecraft should reject any command that is not cryptographically authenticated, no matter how legitimate its origin appears, and should carry autonomous safe-mode and watchdog behaviour so a compromised ground cannot drive it into an unsafe state. Second, the mission network should be treated as zero-trust and held apart from enterprise IT, with privileged-access management, phishing-resistant multi-factor authentication and an out-of-band path to recover commanding. Third, the supply chain should be made legible through software bills of materials, code signing and pre-launch integrity verification, so that what flies is what was intended.

Future Considerations

Four developments will reshape this threat model over the next decade.

Quantum computing

A capable quantum computer would break the public-key cryptography that protects many command and key-exchange schemes. The near-term risk is harvest-now-decrypt-later, in which an adversary records encrypted traffic today to decrypt once the capability exists. Operators with long-lived assets should plan migration to post-quantum algorithms while crypto-agility is still possible.

AI-enabled attacks

Machine learning lowers the cost of reconnaissance, phishing, vulnerability discovery and signal manipulation, and raises the plausibility of automated, adaptive intrusions against ground networks. The same tools aid defenders, but the offence-defence balance is not settled.

Mega-constellations and proliferated LEO

Thousands of software-defined satellites with frequent updates, many ground gateways and vast numbers of user terminals multiply the attack surface and make uniform patching both more important and harder. Automation that helps operators also helps attackers scale.

On-orbit servicing and software-defined payloads

Rendezvous, proximity operations and in-orbit reconfiguration create new command paths and new trust relationships between vehicles. Each is a fresh boundary that must be authenticated and monitored.

Are Current Satellite Security Practices Sufficient?

The honest answer is partly. The frameworks now exist and are good. Whether they are sufficient depends on whether they are implemented consistently across an industry with very uneven maturity, and on whether they keep pace with how attackers actually operate.

Strengths

• A coherent body of guidance now spans both continents: SPD-5, the NIST satellite profiles, SPARTA and ECSS-E-ST-80C give operators a clear, current baseline that did not exist five years ago.
• The principle of designing security in across the full lifecycle, rather than bolting it on, is now explicit in both the European standard and US policy.
• Space-specific tooling such as SPARTA closes the gap that generic IT frameworks left around the spacecraft and link.

Weaknesses and gaps

• Most published guidance is voluntary. SPD-5 sets principles but contains no enforcement mechanism (Harrison et al. 2022), and adoption across commercial operators is inconsistent.
• The ground segment, repeatedly the decisive target, is still often secured to ordinary enterprise standards rather than to the standard its consequences demand.
• Long asset lifetimes lock in cryptographic and architectural decisions that age badly, and many fielded assets cannot be patched at all.
• Supply-chain assurance remains immature relative to the depth and internationalism of the space supply chain.

Emerging concerns and projection

The combination of proliferated constellations, AI-scaled offence and an approaching quantum transition will stress current practices faster than they are being adopted. The Viasat incident demonstrated that a state-level actor can produce continent-scale disruption through the ground segment alone, and the conditions that enabled it, exposed remote access and abuse of trusted command paths, are common. The most likely future is not an exotic in-orbit hack but more of what already works: ground intrusions, supply-chain compromise and denial of service, executed at greater scale.

Conclusions

Satellite security is a systems problem, not a spacecraft problem. The assets most worth protecting are the command path, the keys and the people and networks that operate the fleet, and the place attackers most often succeed is the ground. The defensive priorities follow directly: authenticate every command at the vehicle, treat the mission network as zero-trust and keep it apart from enterprise IT, make the supply chain legible, and preserve an independent path to recover positive control. The frameworks to do all of this exist. The work now is consistent implementation across a fast-growing and uneven industry, against adversaries who are scaling faster than the average operator is maturing.

Professional Services

Cyber Electra Inc. supports satellite operators, aerospace vendors and government programmes with the following services. This section is informational. It describes the kinds of engagement that apply the methods used in this document.

References

1. Aerospace Corporation. (2022). Space Attack Research and Tactic Analysis (SPARTA) matrix. The Aerospace Corporation. sparta.aerospace.org
2. Council of the European Union. (2022, 10 May). Russian cyber operations against Ukraine: declaration by the High Representative. Attribution of the KA-SAT / Viasat attack.
3. Communications Security Establishment (CSE). (2012, 1 November; control catalogue 2014, 30 December). IT security risk management: a lifecycle approach (ITSG-33). Canadian Centre for Cyber Security.
4. European Cooperation for Space Standardization (ECSS). (2024, 1 July). ECSS-E-ST-80C: Space engineering, security in space systems lifecycles.
5. Guerrero-Saade, J. A., and van Amerongen, M. (2022, 31 March). AcidRain: a modem wiper rains down on Europe. SentinelLabs; and Viasat (2022, 30 March), KA-SAT network cyber attack overview.
6. Harrison, T., et al. (2022). Analysis of Space Policy Directive-5. Center for Strategic and International Studies, Aerospace Security Project.
7. Lightman, S., Suloway, T., and Brule, J. (2022, December). NIST IR 8401: Satellite ground segment, applying the Cybersecurity Framework to satellite command and control. National Institute of Standards and Technology.
8. MITRE. (current). MITRE ATT&CK and ATT&CK for ICS knowledge bases. The MITRE Corporation.
9. National Institute of Standards and Technology. (2024, 26 February). The NIST Cybersecurity Framework (CSF) 2.0.
10. National Institute of Standards and Technology. (2012–2020). SP 800-30 Rev. 1, SP 800-37 Rev. 2, SP 800-53 Rev. 5. Risk assessment, risk management framework, and security and privacy controls.
11. Scholl, M., and Suloway, T. (2023, July). NIST IR 8270: Introduction to cybersecurity for commercial satellite operations. National Institute of Standards and Technology and The MITRE Corporation.
12. The White House. (2020, 4 September). Space Policy Directive-5: cybersecurity principles for space systems. Lead agencies: DHS and CISA.
13. Consultative Committee for Space Data Systems (CCSDS). (current). Space Data Link Security (SDLS) Protocol.

Prepared by Tansu Tek, Cyber Electra Inc. Version 1.0, 8 June 2026. Released for public reference under an open, attribution-friendly basis. The companion Threat Risk Assessment for Satellite Systems Security is published separately.