Lessons Learned from Cyber Testing Space Systems
Recurring technical findings and organizational friction in U.S. Space Force cyber test and evaluation
Abstract
Cyber attacks against space systems often exploit the exact same vulnerabilities that cyber testers repeatedly uncover. Ground segments with remote access paths, trusted management networks, and maintenance mechanisms that can be abused to generate mission effects are common attack vectors when it comes to making mission effects via cyber-attack. This paper explores lessons learned from Department of War (DoW) cyber test and evaluation events and open-source case studies, then connects them to recurring institutional challenges. The test community capable of identifying and demonstrating risk to space systems, but the acquisition and operational enterprises often lack the authority, time, funding, and/or technical ability to implement fix actions. These limitations are exacerbated when vulnerabilities are discovered late in the acquisition lifecycle, when payloads are already on orbit, or when changes trigger a recertification process. The U.S. Space Force can reduce these limitations by shifting cyber test and evaluation earlier in development through mission-based cyber risk assessment, contractable security requirements, earlier test access, and by formalizing risk acceptance when fixes are infeasible.
1. Introduction
Space systems are highly complicated cyber enabled systems-of-systems involving space vehicles (SVs), payloads, ground stations, mission data processing, network transport, operators, maintainers, network defenders, and the tactics and procedures that bind them all together. DoW cyber operational testing explicitly treats the system under test (SUT) as including these human and network elements, not just the hardware and software product.[6]
Thesis: DoW cyber testing reveals recurring, largely preventable vulnerabilities in the ground and management segments of space systems. However, organizational seams between program offices, contractors, and independent test organizations can often create predictable friction that can delay or prevent remediation. The most important lessons learned are therefore both technical (what fails) and institutional (why fixes stall).
2. Background: why we cyber test space systems
The last two decades have shown that adversaries do not need to compromise an SV or payload in space to create mission effects. They more often target the ground systems, management planes, and update pathways that tie system-of-system architectures together.
NASA Terra AM-1 satellites experienced multiple instances of interference in 2007-2008, and the U.S.-China Economic and Security Review Commission reported that the responsible party ‘achieved all steps required to command’ the Terra spacecraft during two events in 2008, though NASA stated that no commands were successfully sent and no data was captured. [7], [8] The intrusion vector was a commercial internet connection via the ground station in Norway, which the adversary leveraged to identify and exploit a vulnerability in the station's internet-facing systems, ultimately penetrating the internal network. By positioning themselves within the network, the attacker conducted a man-in-the-middle type attack, successfully intercepting and mimicking legitimate command signals to the satellite that were able to bypass the system’s authentication protocols. The lesson for cyber testing is not a specific exploit chain; it is that ground infrastructure and its external connectivity can create a pathway to mission systems.
Another example occurred on February 24th, 2022, when a cyber-attack disrupted Viasat’s KA-SAT satellite broadband service just a few hours before the Russian invasion of Ukraine. The attackers exploited a misconfiguration in the system’s Virtual Private Network (VPN) that allowed them to gain access to a trusted management segment of the system. The attackers then leveraged legitimate management commands to overwrite key data in the modem flash memory, rendering terminals unable to access the network, creating a denial of service effect. [10] A malware payload called ‘AcidRain’ was determined to be payload used to create the effect and the attack was publicly attributed to Russian state-sponsored actors. [11][12][13] This incident reinforced a core point for space survivability. Adversaries do not need to attack the SV or payload in orbit to create operational effects. Compromising management and update pathways in the ground systems and user segments can be sufficient and are usually far easier to access.
3. How cyber test and evaluation is structured for DoW and space systems
DoW policy requires integrated test planning and emphasizes that cybersecurity cannot be treated as a paperwork exercise alone. This means going beyond the Risk Management Framework (RMF) that is used to support authorizations to operate (ATOs). DoW cyber test and evaluation exists outside RMF compliance and is intended to validate survivability and resilience through observable evidence and mission relevant effects. [1], [3], [4]
A commonly used DoW cyber test and evaluation (T&E) model aligns cyber test events to system maturity and acquisition phases. It begins early with an analytical mission based cyber risk assessment (MBCRA), then uses that as a foundation to perform cooperative and adversarial test events in developmental test (DT) and operational test (OT). [4], [6], [14]
Table 1. Representative cyber T&E events and outputs (unclassified)
| Event | Primary purpose | Typical methods | Decision-quality outputs |
|---|---|---|---|
| MBCRA (early / iterative) | Identify mission-critical functions, attack paths, and risk priorities | Mission threads, criticality analysis, tabletop attack scenarios, artifact review | Prioritized risks and scenarios to drive test and engineering changes |
| Cooperative vulnerability identification (DT) | Find and validate vulnerabilities on accessible increments | Scanning, configuration review, limited hands-on testing | Verified findings and remediation recommendations for engineering |
| Adversarial cyber DT&E (DT) | Demonstrate exploitability and potential mission effects in controlled settings | Penetration testing, emulated adversary TTPs, limited effects demonstrations | Evidence of resilience gaps; mitigation verification before OT |
| CVPA (OT) | Overt, cooperative identification of significant vulnerabilities in operational context | Interviews, inspection, tool-assisted assessment, boundary mapping | CVPA report used to inform adversarial assessment and mitigation actions |
| Adversarial assessment (OT) | Assess ability to execute mission while under representative threat activity | Independent red-team campaign, PMRA (protect-mitigate-recover-adapt) evaluation | Operational survivability evidence informing fielding decisions |
Director Operational Test and Evaluation (DOT&E) directs Operational Test Agencies/Organizations (OTAs/OTOs to design OT&E to examine cyber survivability using four pillars: prevent, mitigate, recover, and adapt (PMRA). These pillars align with the Joint Staff Cyber Survivability Endorsement Implementation Guide (CSEIG) framing for the System Survivability Key Performance Parameters (KPPs), which treats cyber survivability as the ability to prevent, mitigate, recover from, and adapt to adverse cyber events throughout the system lifecycle. [6], [5]
4. Who cyber tests space systems
Within the U.S. Space Force, Space Training and Readiness Command (STARCOM) is responsible for all T&E activities. Space Delta 12 is the primary organization under STARCOM for executing T&E, leading four squadrons, each focusing on different mission sets. [15] The 4th Test and Evaluation Squadron (4 TES) was recently recognized as the Space Force Cyber Operations Team of the Year for 2023 [9].
5. Lessons learned from cyber testing space systems
5.1 Recurring technical lessons
Lesson 1 - The ground segment is the primary cyber battleground
The majority of exploitable vulnerabilities for space programs are usually within mission support systems. Gateway sites, mission data processing, remote admin services, contractor networks, and user terminals are the most common targets. This isn’t to say that SVs and payloads are not important to test. Flat-SAT tests are also critical in hardening the overall system to cyber threats, but these tend to be smaller in scope and more difficult to access. The KA-SAT incident demonstrated mission impacting effects through ground and terminal management without impairing the SV or payload. [10]-[13] Cyber test planning should therefore start with accurate boundary definition and include external dependencies such as enterprise services, partner sites, and supply chain. [6]
Lesson 2 - Trusted management networks are high leverage targets
Management enclaves are often over trusted, under monitored, and connected to many critical assets. Engineers tend to be attracted to powerful tools that enable them to accomplish many tasks from a single access point. While this is wonderful when it comes to network management, it can easily be used against the system when the capabilities fall into the wrong hands. The Viasat attackers leveraged a trusted management segment in order to issue management commands at scale. [10] Cyber testers repeatedly find analogous patterns such as overly broad administrator reach, flat management segments, shared accounts, and weak separation between mission and administrator planes.
Lesson 3 - Update and maintenance mechanisms can become an authorized attack path
Attackers often prefer to ride legitimate pipelines rather than fight cryptography. The KA-SAT disruption was caused by legitimate management commands that triggered destructive outcomes on modems. [10], [11] For space systems, software and configuration updates often cross organizational boundaries such as contractor to operator or depot to site. Cyber tests should stress the full update chain. Code signing, key management, secure boot, rollback protection, and operational procedures for emergency updates should all be targeted.
Lesson 4 - Mission effects matter more than common vulnerabilities and exposure (CVE) counts
DoD guidance emphasizes mission context when conducting assessments for cyber survivability[6], [4] A CVE that cannot plausibly produce a mission effect should never take priority over a benign looking misconfiguration if that misconfiguration enables an adversary to deny a critical data flow. MBCRAs and operationally realistic adversarial assessments help focus limited test time on the highest consequence attack paths and root out what vulnerabilities are actually capable of effecting the mission. [6], [14]
Lesson 5 - Instrumentation and defensive telemetry are part of the system
Cyber survivability includes the cyber defenders’ ability to detect, react, and restore the system. [6] If logging, alerting, and incident response workflows are not present and exercised during the testing window, an AA can only infer what these behaviors might be using white cards rather than observed responses. [6] Cyber test should therefore treat audit logging, time synchronization, sensor placement, and defender access as explicit test objectives rather than afterthoughts, and program offices must begin the process of installing cyber defenders into the system early so that they are ready to be relevant to the test process.
Lesson 6 - Cyber survivability is Prevent, Mitigate, Recover, Adapt (PMRA): recovery and adaptation must be tested
Cyber test must collect and analyze evidence across all four PMRA cyber survivability pillars. System developers often emphasize prevention and mitigation but under invest in recovery to a known good baseline and in the ability to adapt tactics and configurations as threats evolve. Every system carries some risks, and no one can prevent a zero day attack. Strong systems are the ones that can recover from such attacks quickly and adapt on the fly to prevent repeat attacks. Cyber testers should build AA objectives that force restoration actions and post-incident configuration changes under time pressure. [6], [5]
5.2 Recurring organizational lessons and pitfalls
Pitfall 1 - Security requirements that are not contractable become nice to have
When cyber survivability requirements are not translated into contract language, measurable outcomes, and/or delivery artifacts, then late stage cyber testing often becomes an exercise in calling the baby ugly without any meaningful corrective action. For this reason, DOT&E stresses early stakeholder involvement and integrated planning, but programs still struggle to obtain timely access to documentation, network diagrams, and representative environments needed for efficient testing. [1], [6], [5]
Pitfall 2 - Discovering vulnerabilities late drives risk acceptance rather than remediation
Space programs have many constraints such as launch windows, budget, and certification timelines. Once hardware is in orbit, direct test and remediation options become much more difficult and risky. In fact, risk will often be considered so high that test will be abandoned or else relegated to sims or other laboratory test beds that are not mission representative. [6] Without planned pre-production test venues, the enterprise frequently accepts risk because remediation would delay fielding and/or disrupt operations.
Pitfall 3 - Authority and incentives are split across the enterprise
Operational test organizations provide independent, timely, and relevant information to empower decision makers. Program offices balance budgets with contract commitments while operational units focus on mission execution and effectiveness. In practice, cyber findings become a negotiation point between stakeholders with different priorities and different tolerances for risk. The most common issue is not disagreement that a vulnerability exists. Instead it is disagreement on who pays, who implements, and what mission risk is acceptable.
Pitfall 4 - Classification and proprietary boundaries slow triage and root cause analysis
Space systems often span multiple classification domains, partner networks, and contractor-owned infrastructure. When key artifacts such as source code, configuration baselines, supply chain information, and network diagrams are inaccessible to the test team, then findings take longer to identify, validate, and correct. This issue is especially prevalent when subcontractors become involved. What is required is current inputs and documentation across the life cycle and for contractor-developed artifacts that enable efficient testing. [4], [1]
Pitfall 5 - Passed RMF is misinterpreted as survivable under attack
RMF supports authorization decisions but it does not replace cyber survivability testing. [4], [3] When stakeholders conflate compliance testing with cyber survivability testing, they underinvest in adversarial assessments, defensive exercises, mission effect validation, and overall cyber defense. The result is a program that can be compliant and still vulnerable to real world adversaries.
6. Recommendations for reducing repeat findings and remediation stalls:
Shift cyber survivability left and repeat it
Program offices should plan and execute MBCRAs early and iteratively to drive engineering decisions while changes are still affordable and available. They should use MBCRA outputs to select a focused set of attack paths linked to relevant mission consequences for repeated validation across the testing lifecycle. [6], [14], [4]
Make test access and artifacts deliverables
Include test environment creation, access plans, interface control documentation, configuration baselines, network diagrams, and log and telemetry requirements in solicitations and contracts. Contractor developed artifacts such as these are critical for enabling efficient T&E. [1] Also, design management planes for zero trust and high observability. Treat the management segment as a hostile environment by enforcing multi factor authentication, least privilege, segmentation, command authorization, and centralized logging with defender workflows. Finally, validate these controls through cooperative testing and adversarial assessments.
Pre-plan remediation decision paths and risk acceptance criteria
When fix actions are infeasible for reasons such as mission constraints, safety risks, or recertification costs, ensure the program has formal risk acceptance criteria with documented mission impacts, compensating controls, and retest triggers. Then, use test evidence from the CVPA and AA to support fielding decisions. [2], [6]
7. Conclusion
Space systems will continue to be attractive targets due to their value to war efforts and their reliance on the cyber domain. The most impactful real world incidents and the most common cyber test findings converge on the same reality. Ground system and management segments are where mission effects are usually created. The Space Force can reduce repeat findings by institutionalizing mission based cyber risk assessments and iterative cooperative and adversarial testing, but it must also address the organizational seams that stall remediation. The goal is not zero vulnerabilities. It is decision quality understanding of mission risk and a repeatable path to either fix, mitigate, or credibly accept that risk before fielding.
REFERENCES
[1] Department of Defense, DoD Instruction 5000.89, Test and Evaluation, Nov. 19, 2020. Available: https://www.dote.osd.mil/Portals/97/pub/policies/2020/DoDI%205000.89%20Test%20and%20Evaluation.pdf. Accessed: Jan. 31, 2026.
[2] Department of Defense, DoD Instruction 5000.98, Operational Test and Evaluation and Live Fire Test and Evaluation, Dec. 9, 2024. Available: https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/500098p.PDF. Accessed: Jan. 31, 2026
[3] Department of Defense Chief Information Officer, DoD Instruction 8510.01, Risk Management Framework (RMF) for DoD Systems, Jul. 19, 2022. Available: https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/851001p.pdf. Accessed: Jan. 31, 2026.
[4] Office of the Under Secretary of Defense for Research and Engineering, DoD Cyber Developmental Test and Evaluation Guidebook, Version 3.0, Jun. 27, 2025. Available: https://www.cto.mil/wp-content/uploads/2025/07/Cyber-DTE-Guidebook-V3-June2025.pdf. Accessed: Jan. 31, 2026.
[5] Joint Staff J6, Cyber Survivability Endorsement (CSE) Implementation Guide, Version 3.0, Jul. 2022. Available: https://govtribe.com/file/government-file/attachment-e-cyber-survivability-endorsement-cse-implementation-guide-v3-july-2022-dot-pdf. Accessed: Jan. 31, 2026.
[6] Office of the Director, Operational Test and Evaluation, Cyber Operational Test and Evaluation Guidebook, Version 1.0, 31 Jan. 2025 (cover memorandum dated 14 Feb. 2025). Available: https://www.dote.osd.mil/Portals/97/pub/guidebooks/2025/Cyber%20Operational%20Test%20and%20Evaluation%20Guidebook%2020250206%20w-cover%20memo%20%2829625%29.pdf. Accessed: Jan. 31, 2026.
[7] M. Martina, 'China key suspect in U.S. satellite hacks: commission,' Reuters, Oct. 28, 2011. Available: https://www.reuters.com/article/world/china-key-suspect-in-us-satellite-hacks-commission-idUSTRE79R5MP/. Accessed: Jan. 31, 2026.
[8] V. T. H. Uy, 'Hackers targeted U.S. government satellites,' Wired, Oct. 27, 2011. Available: https://www.wired.com/2011/10/hackers-attack-satellites/. Accessed: Jan. 31, 2026.
[9] Space Training and Readiness Command Public Affairs, '4th TES Cyber Team recognized as Space Force’s best for 2023,' May 21, 2024. Available: https://www.starcom.spaceforce.mil/News/Article-Display/Article/3783554/4th-tes-cyber-team-recognized-as-space-forces-best-for-2023/. Accessed: Jan. 31, 2026
[10] Viasat, 'KA-SAT Network cyber attack overview,' Mar. 30, 2022. Available: https://www.viasat.com/perspectives/corporate/2022/ka-sat-network-cyber-attack-overview/. Accessed: Jan. 31, 2026.
[11] J. A. Guerrero-Saade and M. van Amerongen, 'AcidRain: A Modem Wiper Rains Down on Europe,' SentinelLabs (SentinelOne), Mar. 31, 2022. Available: https://www.sentinelone.com/labs/acidrain-a-modem-wiper-rains-down-on-europe/. Accessed: Jan. 31, 2026.
[12] U.S. Department of State, 'Attribution of Russia’s Malicious Cyber Activity Against Ukraine,' May 10, 2022. Available: https://2021-2025.state.gov/attribution-of-russias-malicious-cyber-activity-against-ukraine/. Accessed: Jan. 31, 2026.
[13] Cybersecurity and Infrastructure Security Agency, 'U.S. Government Attributes Cyberattacks on SATCOM Networks to Russian State-Sponsored Malicious Cyber Actors,' May 10, 2022. Available: https://www.cisa.gov/news-events/alerts/2022/05/10/us-government-attributes-cyberattacks-satcom-networks-russian-state-sponsored-malicious-cyber-actors. Accessed: Jan. 31, 2026
[14] Cybersecurity and Spectrum Information Analysis Center (CSIAC), Joint Cyber T&E Policy and Guidance (briefing), Jun. 2023. Available: https://csiac.dtic.mil/wp-content/uploads/2023/06/Joint-cyber-T-E-CSIAC-June-2023_final.pdf. Accessed: Jan. 31, 2026.
[15] U.S. Space Force, Space Training and Readiness Command - Space Delta 12: Test & Evaluation (unit mission page). Available: https://www.starcom.spaceforce.mil/About-Us/Units/Space-Delta-12-Test-Evaluation/. Accessed: Jan. 31, 2026.
Disclaimer:
The views and opinions expressed in this paper are solely those of the author and do not reflect the official policy, position, or endorsement of the Department of War, the United States Space Force, or any other agency of the U.S. Government.