Software-Defined Satellites: Space Cybersecurity and the Inverted Security Model

Key Insight

Question. Hardware-defined satellites were secure because they could not be changed. Software-defined satellites must be secure despite being remotely reconfigurable. The question is whether the operators deploying them have absorbed what that inversion does to their threat model.

Thesis. They have not. The dominant risk for the software-defined fleet is not orbital attack but ground-segment intrusion through known, unpatched vulnerabilities. It scores Likelihood 5 × Impact 5 × Vulnerability 1.25 = 31.25 (see “Risk Framework” in the Glossary at the end of the article for the threat matrix definitions below) — the highest value in the inventory, and on a sharply rising trajectory. That intrusion path feeds a firmware update channel doing triple duty: it is what makes the platform valuable, how an attacker gets in, and the only tool available to fix it afterward. Five Critical-zone threats converge around ground access, supply chain insertion, and cryptographic weakness. A single proven attack chain already covers most of the path from remote intrusion to weapon-equivalent effect — the Viasat KA-SAT pattern of 2022, now extended by the 2025-2026 Eutelsat and SES hijacking incidents. The architectural inversion is real, the precedents exist, and the mitigative barriers are demonstrably weaker than the preventive ones.

State of the Art

Software-defined satellites are no longer experimental. Eutelsat Quantum has been operational since 2021. Airbus OneSat and Thales Alenia Space Inspire are entering service after well-documented 1-2 year delays. Starlink runs continuous firmware updates as a baseline operational mode. Their defining capability — reconfigurable beams, adjustable frequency plans, customer-direct payload access, in-orbit software upgrades — is what justifies the capital expenditure. That same capability is what redefines their threat surface. A hardware-defined satellite presents an adversary with a fixed-function target whose risk profile is locked at launch. A software-defined platform presents a continuously authenticated endpoint whose risk profile changes every time a configuration command is processed.

The institutional response is in motion but unfinished. ENISA classifies space as “high criticality” under NIS2 , with 125 cybersecurity controls mapped to lifecycle phases and a compliance horizon of 2027. ESA’s 4S programme funds satellite cybersecurity research, the Estonia Space Cyber Range, and post-quantum cryptographic work via the PQC ASTrAL project . The Aerospace Corporation’s Moonlighter CubeSat enables in-space hacking exercises. Space ISAC aggregates threat intelligence on a voluntary basis. None of these instruments are yet operational mandates; all are catching up to a deployment curve that has already begun.

Complication

ETH Zurich has documented 124 cyber operations against space systems during the Ukraine conflict alone. Space ISAC records more than 100 attempted attacks per week. The Viasat KA-SAT attack of February 2022 demonstrated, with full forensic detail, that the entry path runs through ground infrastructure. The effect is delivered through the firmware update channel. Between 2025 and early 2026, five Eutelsat satellites and one SES satellite were hijacked for unauthorized broadcast — proof that satellite reconfiguration without operator consent is no longer a theoretical concern. In parallel, VisionSpace researchers disclosed vulnerabilities in open-source satellite control software at Black Hat 2025 . They included remote code execution in NASA’s cFS framework and multiple flaws in CryptoLib — the cryptographic library underwriting secure command authentication for missions including JWST. The architectural inversion has met an active adversary on a clock the defenders are not winning.

The Argument

Ground segment intrusion, not orbital attack, is the dominant entry vector.

Every documented cyber-physical compromise of a satellite system in the past four years has begun on the ground. The Viasat KA-SAT attack exploited CVE-2018-13379 — a four-year-old, publicly documented vulnerability in a Fortinet VPN appliance. That vulnerability opened the management consoles that issued mass firmware-wipe commands to tens of thousands of modems. The Dozor-Teleport retaliatory operation disabled more than 3,000 ground stations. The POLSA breach hit institutional ground infrastructure. None of these adversaries needed an anti-satellite weapon, an orbital intercept, or any space-domain capability whatsoever. They needed an unpatched edge appliance and the patience to use it.

Threat T1 — VPN and management console exploitation via known CVEs — is rated Likelihood 5 (Almost Certain) × Impact 5 × Vulnerability 1.25 = 31.25, the highest score in the inventory. The Likelihood ceiling is not a modeling artifact. It reflects a four-year baseline of fully successful precedents against known, unpatched ground-segment vulnerabilities, set against a sector-wide backdrop of more than 100 attempted cyberattacks per week across all satellite systems. The Vulnerability multiplier captures something more specific to the software-defined fleet. Kratos and Airbus both acknowledge that SDS ground command-and-control systems are structurally more complex than legacy satellite operations centers, because they must support continuous reconfiguration rather than nominal station-keeping. More interfaces, more authenticated endpoints, more frequent privileged sessions: the attack surface is widest where defenders are weakest.

The Risk Matrix shows the consequence of this pattern. The threat landscape clusters in the high-impact column, with five threats in the Critical zone and none in the Low zone:

Of those five Critical threats, three — T1, T2, T13 — describe ground-segment or ground-segment-adjacent vectors. The other two, T8 and T5, describe software components that reach the satellite via the same upload pipeline. The matrix says one thing: if the ground segment falls, the satellite has already been reconfigured.

The reconstructed attack timeline — what security teams call a kill chain — sharpens the point. A ground-to-orbit attack on a software-defined platform takes weeks to months of reconnaissance and weaponization. Delivery and exploitation then execute in hours. Installation and command-and-control persist for weeks. The action-on-objective phase fires in minutes. The defender’s real window opens at the perimeter of the ground segment, days or weeks before the satellite ever receives an anomalous command — well before the moment of impact itself. The highest-leverage disruption point is Phase 3, delivery: zero-trust architecture, multi-factor authentication on all management consoles, and aggressive patch management on perimeter equipment. This is not a satellite cybersecurity problem in the orbital sense. It is an enterprise IT problem with orbital consequences. And the operators who continue to treat it as the former are losing the race.

Software supply chain and cryptographic libraries amplify every ground-segment breach.

If the ground segment is the entry vector, the software supply chain is what makes the entry catastrophic. Threat T2 — firmware update channel weaponization — scores 30.0 (L:4 × I:5 × V:1.5), and the Vulnerability multiplier of 1.5 is the maximum value in the inventory. It is set there because firmware updates on a software-defined platform are the architectural baseline — continuous, not occasional maintenance. The Viasat attack used this same mechanism. Legitimate firmware channels were the delivery vehicle for the wiper payload, because the channels were trusted and the cryptographic verification ran downstream of an already-compromised origin. On a software-defined satellite, that same dynamic is amplified structurally: one mechanism carries the platform’s defining capability, the attacker’s way in, and the defender’s only fix — all three roles held at once. There is no clean way to secure one of those roles without constraining the others.

Threat T8 — compromise of cryptographic libraries — scores 30.0 on the same multiplier and is no longer a hypothetical. VisionSpace’s Black Hat 2025 disclosure identified four flaws in the CryptoLib build NASA uses and seven in the broader open-source package — two of the latter rated critical — in the cryptographic library used to authenticate satellite commands across multiple missions. CryptoLib is open-source and at least visible to researchers. The proprietary cryptographic implementations inside Airbus OneSat, Thales Space Inspire, and the rest of the closed-source European fleet are not visible to researchers and cannot be independently audited. The prior probability that they contain comparable flaws is high. And the time-to-discovery favors whichever side has more analytical capacity. Threat T5 — malicious code insertion in satellite software components — scores 25.0 on a SolarWinds analogy the satellite ecosystem has not yet earned the right to dismiss. ESA explicitly acknowledges that COTS components extend the attack surface across the lifecycle .

These vectors converge on a single architectural finding: the cryptographic subsystem is a common-cause failure. All three primary attack paths — ground C2 compromise, supply chain implant, and direct RF injection from a proximity asset — converge on the same cryptographic verification step. A single library vulnerability defeats multiple independent defenses simultaneously. This is what Vulnerability V7 (single-vendor cryptographic dependency) means in practice: a defect discovered in one widely deployed implementation cascades across operators, missions, and orbital regimes that share no other infrastructure.

The bow-tie barrier assessment — preventive barriers on one side, mitigative barriers on the other — makes the asymmetry concrete. The preventive barriers — supply chain provenance (P1), zero-trust ground architecture (P2), end-to-end encryption (P3) — are rated Weak, Moderate, and Weak respectively. The mitigative barriers that should contain consequence after a compromise — satellite-side firmware integrity verification (M1), hardware-enforced reconfiguration boundaries (M2), autonomous rollback (M3) — are rated Moderate, Very Weak, and Weak. Defense in depth is structurally absent. The defender’s posture rests almost entirely on the preventive layer — the layer the Viasat precedent and the VisionSpace disclosures have shown to be permeable.

Hostile reconfiguration converts cyber compromise into weapon-equivalent effect without an ASAT.

This is the inversion that distinguishes the software-defined threat from every previous satellite cybersecurity assessment. A hardware-defined satellite that is cyber-compromised yields intelligence — telemetry leaks, command logs, perhaps a denial event. A software-defined satellite that is cyber-compromised yields a remotely controllable physical capability. Threat T9 (beam redirection for interception or denial), T10 (orbit alteration commands), T11 (frequency manipulation), and T12 (hijacking for propaganda broadcast) describe a category that did not previously exist in satellite cyber risk analysis. It did not exist because the underlying capability did not previously exist in the satellite.

The 2025-2026 hijackings of five Eutelsat satellites and one SES satellite for propaganda broadcast are the operational proof of concept. Those events used the lowest-consequence variant of the technique — unauthorized retransmission, scoring Impact 3. But they confirmed that an adversary can reach the payload reconfiguration interface and induce the satellite to perform an act its operator did not authorize. T11 (frequency manipulation) and T9 (beam redirection) score 20.0 and 18.75 respectively. Both are rated higher likelihood than T10 (orbit alteration), because they require only command-channel access — proven achievable — rather than specialized orbital mechanics expertise. The qualitative point matters more than the numerical one: the capability an adversary acquires by compromising a software-defined satellite is not data. It is the satellite itself, configured to act against its operator’s interests. The framework category for that capability is “weapon,” even though no anti-satellite weapon was used to obtain it.

The most consequential gap in the mitigative layer is the absence of hardware-enforced reconfiguration boundaries. There is no public evidence that current software-defined platforms implement physical-layer constraints preventing a compromised software stack from executing maximum-consequence reconfiguration — full beam steering, arbitrary frequency reassignment, or orbit-altering thruster commands — within the satellite’s design envelope. On a hardware-defined satellite, this constraint was implicit in the geometry. There was no software path from a compromised command to a beam pointing somewhere it had not been built to point. On a software-defined satellite, by contrast, the geometry is the software, and there is currently nothing in hardware that says no.

The trajectory is the most important variable. Four of five threat categories are trending upward. Only the cryptographic category is stable, and that stability reflects persistent unaddressed vulnerability rather than improving defense. Two trends are converging. The first is threat democratization: non-state actors can intercept satellite communications with USD 800 of equipment, as the UCSD/Maryland study demonstrated against 39 GEO satellites . The second is target-value escalation: software-defined platforms are being integrated into 5G non-terrestrial networks, and the Airbus SpaceRAN demonstrator already places base-station functions directly on a software-defined payload. Together, the two trends mean the adversary set is widening at the same time the consequence ceiling is rising. The deterrence logic that protected satellites from kinetic attack — high cost, attribution risk, debris consequences — does not transfer to cyber-enabled hostile reconfiguration. The cost is low, attribution is difficult, and the satellite remains physically intact and ostensibly under its operator’s control even after the effect has been delivered. A medium-likelihood, catastrophic-impact threat on a steep upward trend is the kind of risk that decides whether a security architecture survives the next operational year.

Implications

The single decision the operator must make first is the encryption audit. Within three months, every operator running a software-defined platform must verify — not assume — that end-to-end encryption is active on every reconfiguration command channel. The Kratos Space disclosure found that operators routinely assume encryption they do not have. Combined with the UCSD/Maryland intercept demonstration and Russia’s reported seventeen Luch proximity operations against European satellites since 2023 — tracked via commercial space-domain-awareness data but not independently verified — that gap makes this the cheapest and highest-leverage immediate action available. It addresses Threat T13 (score 30.0) and is the only mitigation that disrupts all three documented kill chains. In parallel, the patch management SLA on ground segment perimeter equipment must collapse to a 72-hour ceiling for critical CVEs — the exact gap the Viasat attackers exploited four years after disclosure.

In the six-to-twelve month horizon, two actions follow. The first is zero-trust deployment across all SDS ground command-and-control infrastructure, with hardware-token MFA and network segmentation — addressing the cluster of T1, T3, and T4. The second is an independent security audit of every cryptographic implementation in the SDS reconfiguration chain, including the proprietary ones operators do not normally permit external review of. That audit should treat the CryptoLib disclosures as a baseline, not a ceiling. The prior probability that closed-source implementations contain comparable flaws is high enough that a clean audit would itself be informative.

The medium-term decisions are the ones that change the architecture rather than the operational posture. Hardware-rooted reconfiguration boundaries — physical constraints that prevent any software command, legitimate or malicious, from executing reconfiguration outside a defined operational envelope — are the missing mitigative barrier the bow-tie analysis identifies. Mandatory software bills of materials and supply chain provenance requirements, enforced through NIS2 implementing acts or ESA procurement conditions, disrupt the supply chain kill chain at the earliest feasible phase. Both are expensive; both are necessary; neither will be in place before 2027 absent regulatory pressure that does not currently exist.

The indicators worth monitoring are specific. Watch the rate of disclosed vulnerabilities in satellite control software and cryptographic libraries — VisionSpace’s 2025 disclosures are unlikely to be the last. Watch the documented operational tempo of Russian proximity satellites and any equivalent Chinese deployments. Watch for the next Viasat-class incident. The question is no longer whether one will happen — only which platform, and when. Watch the NIS2 implementing acts as they emerge in 2026-2027, particularly any provisions that move encryption verification from voluntary to auditable. Every other decision in this stack assumes the cryptographic foundation actually exists — which is why the encryption audit has to come first.

Limitations

Several specific data gaps constrain the assessment. The 60% figure for unencrypted command uplinks across the European GEO fleet derives from a single anonymously attributed source. It should be treated as directionally correct rather than precisely correct, even though the UCSD/Maryland intercept findings support its general direction. Specific platform security architectures — Airbus OneSat, Thales Space Inspire — are proprietary and cannot be independently verified. This means the Vulnerability multipliers for those platforms reflect fleet-average estimates that may overstate or understate exposure for any individual asset. The scoring framework itself rests on structured judgment. The distinction between Likelihood 4 and Likelihood 5 for ground segment threats reflects demonstrated precedent frequency, and reasonable analysts could score these differently. The cross-category compound scenarios (T8 enabling T2 enabling T9) are described qualitatively rather than probabilistically; full cascade modeling would require analytic methods beyond this assessment. Kinetic anti-satellite threats, natural space environment risks, and market or financial risks to operators are excluded as outside the cybersecurity perimeter. The Thesis would weaken if independent audits of proprietary cryptographic implementations found them substantially more robust than the open-source baseline. It would collapse only if the firmware update architecture were redesigned to remove the triple-role conflict — a step no operator has yet announced.

Glossary

Risk framework (article-specific)

• T1…T18 — Threat identifiers used in the risk matrix, organised in five categories:
  • Ground segment compromise
    • T1 — VPN/management console exploitation via known CVEs (31.25, Critical — highest-rated)
    • T2 — firmware update channel weaponization (30.0, Critical)
    • T3 — ground C2 system compromise via SDS operational complexity (20.0)
    • T4 — insider threat at ground station or operations center (12.0)
  • Software supply chain compromise
    • T5 — malicious code insertion in satellite software components (25.0, Critical)
    • T6 — compromise of COTS components extending attack surface (20.0)
    • T7 — dormant malware in satellite hardware from manufacturing (15.0)
    • T8 — compromise of cryptographic libraries, CryptoLib-type flaws (30.0, Critical)
  • Hostile reconfiguration / weapon conversion
    • T9 — beam redirection for communications interception or denial (18.75)
    • T10 — orbit alteration commands to create collision risk (10.0)
    • T11 — frequency manipulation for interference or jamming (20.0)
    • T12 — hijacking for propaganda broadcast (15.0)
  • Cryptographic and authentication failures
    • T13 — unencrypted command uplinks enabling replay/injection attacks (30.0, Critical)
    • T14 — quantum computing threat to current satellite encryption (10.0)
    • T15 — authentication bypass via unauthenticated telemetry interfaces (20.0)
  • Cascading infrastructure effects
    • T16 — compromise of space-based 5G NTN node disrupting terrestrial telecoms (18.75)
    • T17 — SDS compromise cascading to dependent critical infrastructure, PNT/SATCOM (15.0)
    • T18 — AI-SDS interaction compounding attack surface and autonomous misbehavior (15.0)
• L × I × V — Risk score formula: Likelihood × Impact × Vulnerability.
  • L1–L5 — likelihood scale on one axis of the matrix (5 = highest)
  • Impact 1–5 — impact scale on the other axis (5 = highest)

Primary Sources & Research

ENISA (2025). ENISA Space Threat Landscape. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications/enisa-space-threat-landscape-2025

ESA (2024). 4S — Space Systems for Safety and Security. European Space Agency. https://connectivity.esa.int/artes-4-0-programme-overview/safety-security

ESA (2024). PQC ASTrAL — Post-Quantum Cryptography Algorithms for Satellite Telecommunication Applications. European Space Agency. https://connectivity.esa.int/archives/news/esa-partners-polish-technology-company-develop-satcom-security-solution-using-postquantum-algorithms

ESA (2021). Eutelsat Quantum. European Space Agency — Telecommunications & Integrated Applications. https://www.esa.int/Applications/Telecommunications_Integrated_Applications/Quantum

Aerospace Corporation (2023). Moonlighter — The First Hacking Sandbox in Space. The Aerospace Corporation. https://www.aerospace.org/article/moonlighter-first-hacking-sandbox-space

NIST (2019). CVE-2018-13379 — Fortinet FortiOS Path Traversal. National Vulnerability Database. https://nvd.nist.gov/vuln/detail/CVE-2018-13379

European Union (2022). Directive (EU) 2022/2555 (NIS2). EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555

Space ISAC (2024). Space Information Sharing and Analysis Center. Space ISAC. https://spaceisac.org/

Viasat (2022). KA-SAT Network Cyber Attack Overview. Viasat. https://www.viasat.com/perspectives/corporate/2022/ka-sat-network-cyber-attack-overview/

Deloitte Insights (2024). Orbital Observations: Enhancing Space Resilience with Real-Time Cybersecurity. Deloitte. https://www.deloitte.com/us/en/insights/industry/government-public-sector-services/critical-need-for-cybersecurity-in-space-systems.html

Chatham House (2025). Securing the Space-Based Assets of NATO Members from Cyberattacks. The Royal Institute of International Affairs. https://www.chathamhouse.org/2025/05/securing-space-based-assets-nato-members-cyberattacks

Observer Research Foundation (2024). Enhancing Cybersecurity in Outer Space. ORF. https://www.orfonline.org/research/enhancing-cybersecurity-in-outer-space

Aerospace Corporation (2024). Space Safety Compendium — Cybersecurity Requirements for Next-Generation Platforms. The Aerospace Corporation. https://aerospace.org/paper/space-safety-compendium

Reuters (2025). Polish Space Agency Suffers Cyberattack. Reuters. https://www.reuters.com/technology/cybersecurity/polish-space-agency-suffers-cyberattack-2025-03-13/

Euromaidan Press (2025). Eight European Nations File UN Complaint Against Russia for Satellite Communication Interference. Euromaidan Press. https://euromaidanpress.com/2025/03/18/eight-european-nations-file-un-complaint-against-russia-for-satellite-communication-interference/

ETH Zurich / CSS (2024). Hacking the Cosmos: Cyber Operations Against the Space Sector — A Case Study from the War in Ukraine. Center for Security Studies. https://css.ethz.ch/en/center/CSS-news/2024/10/hacking-the-cosmos-cyber-operations-against-the-space-sector-a-case-study-from-the-war-in-ukraine.html

NASA (2024). Cybersecurity Policies. National Aeronautics and Space Administration. https://www.nasa.gov/cybersecurity-policies/