Adversaries watch for telltale signs that the spacecraft has entered a safed or survival configuration, typically sun-pointing or torque-limited attitude, reduced payload activity, conservative power/thermal setpoints, and low-rate engineering downlink. Indicators include specific mode bits or beacon fields, changes in modulation/coding and cadence, distinctive event packets (e.g., wheel unload aborts, brownout recovery), elevated heater duty, altered load-shed states, and operator behaviors such as emergency DSN requests, longer ground passes, or public anomaly notices. This reconnaissance helps time later actions to coincide with periods of reduced bandwidth, altered monitoring, or maintenance command availability. It may also reveal how safing affects authentication (e.g., whether rapid-response paths or recovery consoles differ from nominal).
| ID | Name | Tiering | Description | NIST Rev5 | ISO 27001 | Onboard SV | Ground | |
| CM0001 | Protect Sensitive Information | Space mission sensitive information spans a broad attack surface and must be inventoried, classified, and protected at a level commensurate with its sensitivity across every location where it resides, including ground systems, contractor networks, and remote access environments. Sensitive material typically includes functional and performance specifications, interface control documents (ICDs), command and telemetry (C&T) databases, uplink protection schemes including disable and bypass features, fault management logic, scripts, simulation and rehearsal results, failure and anomaly resolution records, and architecture and software documentation. Each information type must be assigned a protection level, such as unclassified, controlled, proprietary, or classified, and access must be restricted to personnel with defined roles and a verified need to know. Sensitive data shall be protected at rest and in transit using encryption or other mission-approved safeguards commensurate with its classification, sensitivity, threat exposure, and operational constraints. DLP capabilities shall be applied to systems and data flows where they are technically feasible and effective, with alternative access controls, monitoring, or information-flow protections used where conventional DLP technology is not suitable. Ongoing configuration management must track, control, and document all changes to command procedures and critical database content to prevent unauthorized modification and mission degradation. | AC-25 AC-3(11) AC-4(23) AC-4(25) AC-4(6) CA-3 CM-12 CM-12(1) PL-8 PL-8(1) PM-11 PM-17 SA-3 SA-3(1) SA-3(2) SA-4(12) SA-5 SA-8 SA-8(19) SA-9(7) SC-16 SC-16(1) SC-8(1) SC-8(3) SI-12 SI-21 SI-23 SR-12 SR-7 | A.8.4 A.8.11 A.8.10 A.5.14 A.8.21 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.27 A.8.28 A.5.33 A.8.10 A.5.22 | ||||
| CM0082 | Deception and Decoys | Deception and decoy techniques can reduce the accuracy or confidence of adversary assessments concerning spacecraft location, capability, operational status, mission type, or constellation robustness. Ground segment honeypots, such as HoneySat, extend deception into the cyber domain by simulating realistic satellite ground infrastructure and mission control systems to attract, deceive, and collect intelligence on adversaries attempting network-based compromise of satellite operations. Their effectiveness depends on whether the deception remains credible when evaluated across the observable signatures and intelligence sources available to the adversary. Strategic deception encompasses information operations approaches such as controlled public messaging and launch announcements that limit disclosure or actively introduce uncertainty about satellite capabilities, as well as operational practices that conceal spacecraft functions through careful management of observable behaviors and emissions. On-orbit capability deception, enabled by swappable payload modules and on-orbit servicing vehicles that periodically transfer payloads between satellites, creates persistent uncertainty in the adversary's intelligence picture about which capabilities are resident on which platform at any given time, directly complicating targeting calculus. Tactical decoys provide active point defense by creating false targets that confuse the sensors of anti-satellite (ASAT) weapons and space domain awareness (SDA) surveillance systems; physical decoys, such as deployable inflatable devices that replicate a satellite's size and radar cross-section, and electromagnetic decoys that mimic a spacecraft's radio frequency (RF) signature, can each divert adversary attention and degrade the reliability of tracking and targeting solutions. Multiple decoys stored onboard for sequential deployment extend the utility of the capability across engagement scenarios. Cyber-layer deception through satellite honeypots represents an emerging defensive capability that complements physical and electromagnetic deception techniques. Systems like HoneySat simulate complete satellite missions, including ground segment software, mission control interfaces, orbital pass timing, and realistic telemetry generation, to create high-fidelity decoys accessible over network protocols commonly used in satellite operations. By mimicking the communication patterns, telecommand structures, and subsystem behaviors of operational small satellites, these honeypots can successfully deceive adversaries conducting reconnaissance or attempting unauthorized access via Internet-exposed ground infrastructure. The intelligence collected from honeypot interactions provides visibility into adversary TTPs targeting space systems, enabling defenders to characterize threat actor capabilities, refine attribution assessments, and develop countermeasures based on observed attack patterns. Integration of honeypots into satellite mission architectures, whether as standalone decoy systems or as protective layers around operational ground segments, adds depth to cyber defense postures while imposing costs on adversaries who must expend resources distinguishing genuine targets from sophisticated simulations. | SC-26 SC-30 | None | ||||
| CM0073 | Traffic Flow Analysis Defense | Traffic flow analysis attacks enable adversaries to derive operationally significant intelligence from observable transmission characteristics, including message timing, volume, duration, periodicity, and routing information, without decrypting the content of communications. Even when link encryption is in place, unprotected traffic patterns can reveal spacecraft operational schedules, command activity, contact windows with specific ground stations, and anomalous events that provide adversaries with actionable mission intelligence. Traffic flow analysis defense encompasses a set of techniques applied to protect the confidentiality of transmission metadata on telemetry, tracking, and commanding (TT&C) and data links, as well as onboard communications where applicable. Applicable techniques include padding transmissions to normalize message lengths and volumes, introducing artificial traffic during idle periods to obscure true contact patterns and event timing, obfuscating routing information and endpoint identities, varying transmission periodicity to defeat statistical pattern recognition, and frustrating traffic volume and duration analysis through active obfuscation methods. These controls are a complement to, but distinct from, cryptographic content protection, and should be applied based on a threat-informed assessment of the value of traffic metadata to potential adversaries and their collection capabilities. | SC-8 SI-4(15) | A.5.10 A.5.14 A.8.20 A.8.26 | ||||
| CM0005 | Ground-based Countermeasures | Ground-based countermeasures protect the terrestrial capabilities that develop, launch, command, monitor, operate, secure, and sustain space missions. These capabilities may be distributed across mission-owned systems, contractor environments, external partners, and commercial service providers. Because ground segment architectures and responsibilities vary, cybersecurity protections should be selected through threat-informed analysis of the mission functions being performed rather than through indiscriminate application of a single control set. The SPARTA Ground Segment Cyber Defenses guidance provides an interactive functional decomposition that maps ground segment function groups to applicable Defense-in-Depth sub-layers and countermeasure targets. The supporting report, VTR-2026-00702 Rev A, Ground Segment Cyber Defenses and Risk-Based Tiering, provides the methodology, definitions, and risk-tier rationale. The accompanying Ground Segment Cyber Defenses Excel Workbook consolidates the function mappings and Baseline and Enhanced countermeasure guidance into a resource that can be tailored to a specific mission architecture. | SPARTA Ground Segment Cyber Defenses guidance | None | ||||
| CM0006 | Cloaking Safe-mode | Safe-mode entry represents a high-risk transition point at which a spacecraft enters a reduced-capability state to preserve vehicle safety and support anomaly recovery. This transition must not create a less secure command, telemetry, or onboard processing environment. To the extent permitted by mission safety and recovery requirements, the spacecraft should avoid unnecessary or uniquely identifying changes in transmission characteristics, beacon content, communication cadence, and externally observable behavior that would allow an adversary to reliably identify and exploit the safe-mode state. Safe-mode shall preserve the mission-defined minimum security posture for every communication path and command mechanism that remains active. This posture should include authentication, data integrity, anti-replay protection, command authorization, command validation, cryptographic key protection, security-relevant logging, and encryption where confidentiality is required. The spacecraft shall not enter a crypto-bypass or unauthenticated command state solely because safe-mode has been activated. The safe-mode software and configuration baseline shall explicitly define the security controls, command dictionaries, alternate receivers, contingency communication paths, rate and size limits, command counters, time tag requirements, interlocks, logging functions, and monitoring capabilities that remain active during safe-mode. These protections shall be designed and verified as part of the safe-mode baseline rather than treated as discretionary functions that may be removed without security impact analysis. | CP-12 CP-2 PL-8 PL-8(1) SC-13 SC-16 SC-24 SC-8 | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.8 A.5.10 A.5.14 A.8.20 A.8.26 A.8.24 A.8.26 A.5.31 | ||||