Attempting access to an access-controlled system resulting in unauthorized access
| SPARTA ID | Requirement | Rationale/Additional Guidance/Notes |
|---|---|---|
| SPR-1 | The [spacecraft] shall implement a reference monitor mechanism that mediates access between subjects and objects based on a defined set of rules, that is designed and configured to resist tampering or unauthorized alteration, providing a reliable and secure foundation for access control within the information system.{SV-AC-1,SV-AC-4,SV-SP-7}{AC-25} | A reference monitor provides the foundational enforcement point for all access control decisions within the spacecraft. Without a tamper-resistant mediation layer, compromised flight software or malicious code could directly access critical memory, processes, or hardware interfaces. The mechanism must be isolated from modifiable flight software to preserve integrity under adversarial conditions. |
| SPR-6 | The [spacecraft] shall utilize automated mechanisms to protect sensitive information and detect and alert when sensitive information is accessed without satisfying defined criteria.{SV-DCO-1,SV-AC-1}{CM-12(1)} | Manual monitoring is insufficient in time-sensitive, communication-limited spacecraft environments. Automated detection of unauthorized access enables rapid identification of insider misuse, malicious code execution, or policy violations. This supports onboard intrusion detection and timely ground awareness. The mechanism should differentiate anomaly from normal operational variance. |
| SPR-10 | The [spacecraft] shall protect authenticator content from unauthorized disclosure and modification.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),IA-5,IA-5(6),RA-5(4),SA-8(18),SA-8(19),SC-28(3)} | Authenticators (keys, tokens, counters, certificates) are primary targets for persistent access attacks. Disclosure or modification enables command spoofing, replay, and privilege escalation. Protecting authenticator content preserves command integrity and prevents adversaries from maintaining covert control. Integrity protections must apply both at rest and in use. |
| SPR-11 | The [spacecraft] encryption key handling shall be handled outside of the onboard software and protected using cryptography.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(1),SC-28(3)} | Key management separated from modifiable flight software reduces exposure to software compromise. If keys are accessible to onboard applications, malicious code could extract or misuse them. Hardware-anchored or externally managed key handling reduces persistence risk. This supports trust-chain assurance and mitigates firmware-level compromise. |
| SPR-12 | The [spacecraft] encryption keys shall be restricted so that the onboard software is not able to access the information for key readout.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(3)} | Even privileged software must not be able to retrieve plaintext keys. Preventing readout mitigates malware harvesting and insider misuse. Key usage should be mediated through cryptographic modules rather than direct exposure. This enforces least privilege at the cryptographic boundary. |
| SPR-13 | The [spacecraft] encryption keys shall be restricted so that they cannot be read via any telecommands.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(3)} | Telecommand paths are high-value targets for adversarial exploitation. Allowing keys to be retrieved via command interfaces creates a catastrophic failure mode. This constraint prevents exfiltration even under partial compromise of command processing logic. It ensures encryption protections cannot be remotely dismantled. |
| SPR-14 | The [spacecraft] shall authenticate the ground station (and all commands) and other spacecraft before establishing remote connections using bidirectional authentication that is cryptographically based.{SV-AC-1,SV-AC-2}{AC-3,AC-17,AC-17(2),AC-17(10),AC-18(1),AC-20,IA-3(1),IA-4,IA-4(9),IA-7,IA-9,SA-8(18),SA-8(19),SA-9(2),SC-7(11),SC-16(1),SC-16(2),SC-16(3),SC-23(3),SI-3(9)} | Authorization can include embedding opcodes in command strings, using trusted authentication protocols, identifying proper link characteristics such as emitter location, expected range of receive power, expected modulation, data rates, communication protocols, beamwidth, etc.; and tracking command counter increments against expected values. |
| SPR-20 | The [spacecraft] shall prevent use of a mode of operations where cryptography on the TT&C link can be disabled; encryption and authentication shall remain enabled even when automated access control mechanisms are overridden.{SV-AC-1,SV-CF-1,SV-CF-2}{AC-3(10),SA-8(18),SA-8(19),SC-16(2),SC-16(3),SC-40,SC-40(4)} | Emergency or override modes often become attack vectors if protections are weakened. Cryptography must remain enforced even during safe-mode or degraded operations. Removing encryption capability creates a single-point catastrophic exposure. Persistent protection ensures no operational shortcut undermines mission assurance. |
| SPR-31 | The [spacecraft] shall fail securely to a secondary device in the event of an operational failure of a primary boundary protection device (i.e., crypto solution).{SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2}{CP-13,SA-8(19),SA-8(24),SC-7(18),SI-13,SI-13(4)} | If a primary boundary protection device fails, the spacecraft must not revert to insecure operation. Secure failover ensures continuity of confidentiality and integrity protections. This prevents adversaries from inducing failure states to bypass encryption. Redundancy strengthens mission resilience. |
| SPR-47 | The [spacecraft] shall implement relay and replay-resistant authentication mechanisms for establishing a remote connection.{SV-AC-1,SV-AC-2}{AC-3,IA-2(8),IA-2(9),SA-8(18),SC-8(1),SC-16(1),SC-16(2),SC-23(3),SC-40(4)} | Replay attacks can reuse valid command packets to manipulate spacecraft behavior. Freshness checks, nonces, and sequence enforcement prevent reuse of captured transmissions. Relay resistance mitigates man-in-the-middle exploitation. This protects command integrity over RF links. |
| SPR-68 | The [spacecraft] shall have on-board intrusion detection/prevention system that monitors the mission critical components or systems.{SV-AC-1,SV-AC-2,SV-MA-4}{RA-10,SC-7,SI-3,SI-3(8),SI-4,SI-4(1),SI-4(7),SI-4(13),SI-4(24),SI-4(25),SI-10(6)} | The mission critical components or systems could be GNC/Attitude Control, C&DH, TT&C, Fault Management. |
| SPR-95 | The [spacecraft] shall enforce an attribute-based access control policy over subjects and objects as defined in AC-3(3).{SV-AC-1,SV-AC-4}{AC-3(13)} | Attribute-based access control (ABAC) enables dynamic, context-aware enforcement beyond static role assignments. This reduces privilege abuse and insider misuse by incorporating mission state, location, and environmental factors into decisions. ABAC supports least privilege while enabling operational flexibility. Proper enforcement limits lateral movement and unauthorized data access. |
| SPR-96 | The [spacecraft] shall uniquely identify and authenticate the ground station and other spacecraft before establishing a remote connection.{SV-AC-1,SV-AC-2}{AC-3,AC-17,AC-17(10),AC-20,IA-3,IA-4,SA-8(18),SI-3(9)} | |
| SPR-100 | The [spacecraft] shall monitor [Program defined telemetry points] for malicious commanding attempts.{SV-AC-1,SV-AC-2}{SC-7,AU-3(1),AC-17(1)} | Source from AEROSPACE REPORT NO. TOR-2019-02178 Vehicle Command Counter (VCC) - Counts received valid commands Rejected Command Counter - Counts received invalid commands Command Receiver On/Off Mode - Indicates times command receiver is accepting commands Command Receivers Received Signal Strength - Analog measure of the amount of received RF energy at the receive frequency Command Receiver Lock Modes - Indicates when command receiver has achieved lock on command signal Telemetry Downlink Modes - Indicates when the satellite’s telemetry was transmitting Cryptographic Modes - Indicates the operating modes of the various encrypted links Received Commands - Log of all commands received and executed by the satellite System Clock - Master onboard clock GPS Ephemeris - Indicates satellite location derived from GPS Signals |
| SPR-117 | The [spacecraft] shall provide the capability to restrict command lock based on geographic location of ground stations.{SV-AC-1}{AC-2(11),IA-10,SI-4(13),SI-4(25)} | This could be performed using command lockout based upon when the spacecraft is over selected regions. This should be configurable so that when conflicts arise, the Program can update. The goal is so the spacecraft won't accept a command when the spacecraft determines it is in a certain region. |
| SPR-119 | The [spacecraft] shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards: [NSA- certified or approved cryptography for protection of classified information, FIPS-validated cryptography for the provision of hashing].{SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2,SV-AC-3}{IA-7,SC-13} | Use of NSA-certified or FIPS-validated cryptography ensures compliance with federal mandates and high-assurance algorithms. Standardized implementations reduce algorithmic weaknesses. Alignment with policy ensures interoperability and trustworthiness. Proper certification mitigates cryptographic implementation flaws. |
| SPR-120 | The [spacecraft] shall terminate the connection associated with a communications session at the end of the session or after 3 minutes of inactivity.{SV-AC-1}{AC-12,SA-8(18),SC-10,SC-23(1),SC-23(3),SI-14,SI-14(3)} | Persistent sessions increase exposure to hijacking and replay attacks. Automatic termination limits session lifetime and reduces unauthorized reuse. Idle timeout reduces attack surface in unattended conditions. Explicit closure supports session state integrity. |
| SPR-122 | The [spacecraft] shall produce, control, and distribute symmetric cryptographic keys using NSA Certified or Approved key management technology and processes per CNSSP 12. Private cryptographic keys shall be generated, stored, and rotated under [organization] control only and shall not be exposed to external service providers.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-9(6),SC-12,SC-12(1),SC-12(2),SC-12(3)} | Centralized and approved key management prevents unauthorized key generation or rotation. Protecting private keys from external service providers reduces supply chain risk. Controlled lifecycle management supports confidentiality and integrity. Strong governance reduces key compromise likelihood. |
| SPR-123 | The [organization] shall use NIST Approved for symmetric key management for Unclassified systems; NSA Approved or stronger symmetric key management technology for Classified systems.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(2)} | FIPS-complaint technology used by the Program shall include (but is not limited to) cryptographic key generation algorithms or key distribution techniques that are either a) specified in a FIPS, or b) adopted in a FIPS and specified either in an appendix to the FIPS or in a document referenced by the FIPS. NSA-approved technology used for symmetric key management by the Program shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. |
| SPR-124 | The [organization] shall use NSA approved key management technology and processes.NSA-approved technology used for asymmetric key management by The [organization] shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(3)} | Asymmetric keys underpin authentication and trust chains. Approved algorithms and processes ensure robustness against cryptanalytic attack. Formal evaluation criteria provide confidence in implementation strength. This protects digital signatures and secure exchange mechanisms. |
| SPR-125 | The [spacecraft] shall produce, control, and distribute asymmetric cryptographic keys. Private cryptographic keys shall be generated, stored, and rotated under [organization] control only and shall not be exposed to external service providers.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(3)} | In most cased the Program will leverage NSA-approved key management technology and processes. |
| SPR-127 | The [spacecraft] shall be configured to deny communications by default and only permit authorized communications based on approved exceptions, establishing a default‑deny baseline with permitted flows whitelisted.{SV-AC-1,SV-IT-1}{SC-7(5),AC-4(2)} | Deny-by-default limits attack surface by permitting only explicitly authorized flows. Whitelisting prevents unexpected communications and covert channels. This reduces exploitation opportunities. Deterministic communication baselines simplify monitoring and anomaly detection. |
| SPR-129 | The [spacecraft] shall restrict the use of information inputs to spacecraft and designated ground stations as defined in the applicable ICDs.{SV-AC-1,SV-AC-2}{AC-20,SC-23,SI-10,SI-10(5),SI-10(6)} | Limiting inputs to approved spacecraft and ground stations reduces spoofing and injection risk. ICD-defined boundaries prevent rogue sources from influencing control systems. This constrains trust relationships. Controlled input surfaces reduce attack vectors. |
| SPR-343 | The [organization] shall develop and document program-specific access control policies for controlling information flow and leakage on-board the spacecraft.{SV-AC-1,SV-CF-1,SV-CF-3}{AC-1,AC-3,AC-3(3),AC-3(4),AC-3(13)} | Access control policies must reflect mission architecture and threat environment. Formal documentation ensures consistent enforcement. Leakage prevention requires clear governance. Policy clarity supports compliance and auditing. |
| SPR-348 | The [organization] shall establish policy and procedures to prevent unauthorized personnel from masquerading as personnel with valid access to areas where commanding of the spacecraft is possible.{SV-AC-4,SV-AC-1}{PM-12} | Unauthorized impersonation risks mission compromise. Physical and logical controls prevent access misuse. Clear policy deters credential abuse. Identity assurance is essential for command authority. |
| SPR-353 | The [organization] shall, upon termination of individual employment, terminates/revokes any authenticators/credentials associated with the individual.{SV-AC-4,SV-AC-1}{PS-4} | Immediate revocation prevents credential reuse. Deprovisioning reduces exposure window. Controlled offboarding supports lifecycle security. Identity lifecycle management is critical. |
| SPR-387 | The [organization] shall define policy and procedures to ensure that the developed or delivered systems do not embed unencrypted static authenticators in applications, access scripts, configuration files, nor store unencrypted static authenticators on function keys.{SV-AC-1,SV-AC-3}{IA-5(7)} | Hard-coded or static authenticators create high-value targets for reverse engineering and credential reuse. Preventing embedded unencrypted credentials reduces insider and supply chain exploitation risk. Credential hygiene is critical in long-lived space missions. Eliminating static secrets strengthens identity assurance. |
| SPR-410 | The [organization] shall define, document, and approve access restrictions associated with changes to the spacecraft.{SV-AC-1,SV-AC-4}{CM-5} | Changes to spacecraft configuration must be controlled. Clear restrictions prevent unauthorized modification. Structured access governance reduces insider risk. Accountability supports traceability. |
| SPR-411 | The [organization] shall define and enforce restrictions on activities and transactions permissible when interacting with external systems.These access controls shall be regularly reviewed and updated to align with organizational security policies and requirements.{SV-AC-1,SV-MA-7}{AC-20,AC-20(1),AC-20(3)} | External systems may introduce compromise pathways. Defined boundaries limit exposure. Regular review ensures alignment with evolving policy. Controlled interfaces strengthen resilience. |
| SPR-418 | The [organization] shall define a process to limit privileges to change system components and system-related information within a production or operational environment.{SV-AC-4,SV-AC-1}{CM-5(5)} | Operational environments require strict change control. Limiting privileges reduces insider exploitation risk. Controlled modification protects mission stability. Governance supports reliability. |
| SPR-449 | The [spacecraft] shall enforce mandatory access control over subjects and objects.{SV-AC-1,SV-AC-4}{AC-3,AC-3(3)} | MAC ensures centrally enforced policy cannot be overridden by subjects. Strong policy binding reduces discretionary abuse. Deterministic enforcement enhances mission protection. Strict separation strengthens confidentiality and integrity. |
| SPR-450 | The [spacecraft] shall prevent flight software and payload applications from modifying access control labels or rules and shall validate label integrity at startup and during policy updates.{SV-AC-1,SV-IT-2}{AC-3(3),AC-3(11).AC-16,SI-7} | Label integrity ensures policy decisions remain trustworthy. Preventing modification protects data classification enforcement. Validation at startup prevents persistent compromise. Policy integrity underpins MAC assurance. |
| SPR-455 | The [spacecraft] shall restrict access to flight software executables, cryptographic material, command dictionaries, and [organization]-defined sensitive payload data to the privileged execution domain and shall deny all other access by default.{SV-AC-1,SV-AC-3,SV-IT-3}{AC-3(11),AC-6} | Flight executables and cryptographic materials are high-value targets. Restricting access reduces exploitation pathways. Default deny enforces least privilege. Segmentation enhances resilience. |
| SPR-456 | The [spacecraft] shall implement OS or hardware enforcement for these restrictions and shall log any attempted access violations.{SV-AC-1,SV-DCO-1}{AC-3,AC-3(11)} | Hardware-enforced policy is harder to bypass than software-only controls. Logging violations supports detection and response. Layered enforcement strengthens assurance. Technical barriers reinforce governance intent. |
| SPR-459 | The [spacecraft] shall validate security labels or tags on received data and shall drop or quarantine content with missing, invalid, or downgraded labels.{SV-IT-2,SV-AC-1}{AC-16} | Label validation ensures data classification and access control integrity. Dropping or quarantining downgraded or malformed labels prevents policy bypass. Enforced label integrity supports mandatory access control. |
| SPR-462 | The [spacecraft] shall support delegation of temporary data storage to [organization]-authorized alternate nodes or spacecraft and shall preserve confidentiality, integrity, and access controls for the delegated data.{SV-CF-1,SV-CF-2,SV-AC-1}{CP-2(6),SC-28,AC-3} | Delegated storage or processing expands trust boundaries. Maintaining CIA protections during delegation prevents exposure. Secure federation supports constellation-based architectures. Controlled delegation strengthens distributed resilience. |
| SPR-513 | The [organization] shall develop and maintain a phase‑ and mode‑aware access control policy for the mission that maps operator/station identities to command families and pass windows, defines on‑orbit key lifecycle (generation, activation, rotation, retirement), session establishment/renewal/teardown behaviors, and time‑synchronization assumptions across space and ground; the policy shall be validated in simulators/flatsats.{SV-AC-4,SV-AC-1}{AC-1,PL-2} | Access requirements vary by mission phase and spacecraft mode. Explicit mapping prevents inappropriate command authority. Simulator validation ensures policy feasibility. Context-aware governance supports Zero Trust principles. |
| SPR-515 | The [spacecraft] shall enforce discretionary access on [organization]-defined payload data stores using short‑lived, purpose‑specific grants bound to execution windows or end‑of‑pass, with automatic expiration, audited changes/uses, and integrity checks on permission metadata that survive resets/SEUs.{SV-AC-4,SV-AC-1}{AC-3(4)} | Ephemeral grants reduce persistence risk. Execution-window binding prevents privilege creep. Surviving SEUs ensures metadata integrity. Time-bounded access supports least privilege. |
| SPR-517 | The [organization] shall correlate station/operator session activity with pass schedules and spacecraft mode, alert on off‑schedule access and command families invalid for the current mode, and retain results as audit evidence.{SV-AC-4,SV-AC-1,SV-AV-4}{AC-17,AC-17(1),SI-4,AU-6} | Off-schedule or mode-inconsistent commands signal compromise. Correlation across dimensions strengthens anomaly detection. Audit retention supports post-event review. Context validation strengthens mission assurance. |
| SPR-533 | The [spacecraft] and [organization] shall adapt identification and authorization based on mission context (e.g., anomaly response, unscheduled contact, safe mode) by tightening factors/keys, narrowing station whitelists, and enforcing geo/time and mode constraints, with telemetry cues and reversion to baseline.{SV-AC-4,SV-AC-1}{IA-1,IA-5,IA-10} | Threat posture varies by mission state. Adaptive controls tighten during anomalies. Telemetry cues ensure transparency. Contextual enforcement supports Zero Trust maturity. |
| SPR-541 | The [spacecraft] shall provide a trusted path for sensitive actions (e.g., key management, image activation) with strengthened authentication/integrity checks, narrow interfaces, and explicit telemetry cues (trusted‑path active, preconditions satisfied); operations shall confirm trusted‑path use before proceeding.{SV-AC-1,SV-SP-9}{SA-8(13),SC-11,SC-12} | Narrow interfaces reduce attack vectors. Explicit trusted-path indicators prevent misuse. Strengthened authentication protects critical operations. Procedural confirmation ensures compliance. |
| SPR-545 | The [spacecraft] shall bind session authenticity to station identity, operator role, spacecraft mode, and time/sequence and shall expose session parameters (IDs, counters, active role/mode) in telemetry; acceptance checks shall enforce geo/time/mode and station‑whitelist constraints with clear behavior on variance.{SV-AC-4,SV-AC-1}{SC-23,SC-23(1),SC-23(3)} | Station, role, mode, and time binding prevents misuse. Telemetry exposure ensures traceability. Constraint enforcement reduces impersonation risk. Context binding strengthens Zero Trust alignment. |
| ID | Name | Description | |
|---|---|---|---|
| RD-0002 | Compromise Infrastructure | Rather than purchasing or renting assets, adversaries compromise existing infrastructure, mission-owned, third-party, or shared, to obtain ready-made reach into space, ground, or cloud environments with the benefit of plausible attribution. Targets range from physical RF chains and timing sources to mission control servers, automation/scheduling systems, SLE/CSP gateways, identity providers, and cloud data paths. Initial access often comes via stolen credentials, spear-phishing of operators and vendors, exposed remote-support paths, misconfigured multi-tenant platforms, or lateral movement from enterprise IT into operations enclaves. Once resident, actors can pre-position tools, modify configurations, suppress logging, and impersonate legitimate stations or operators to support later Execution, Exfiltration, or Denial. | |
| RD-0002.01 | Mission-Operated Ground System | Compromising a mission’s own ground system grants the adversary preconfigured access to TT&C and automation. High-value targets include operator workstations, mission control servers, procedure libraries, scheduler/orchestration services, key-loading tools and HSMs, antenna control systems, timing/distribution, and RF modems/baseband units. Typical paths: phishing an operator or contractor, abusing remote-support channels, pivoting from enterprise IT to ops, exploiting unpatched services on enclave gateways, or harvesting credentials from poorly segmented test environments. Once inside, an actor can stage malicious procedures, alter rate/size limits, manipulate pass schedules, downgrade authentication in maintenance modes, or quietly siphon telemetry and ephemerides to refine later attacks. | |
| RD-0002.02 | 3rd Party Ground System | Third-party networks (commercial ground stations, hosted modems, cloud-integrated ground-station services) present attractive stepping-stones: they already have vetted RF chains, globally distributed apertures, and trusted IP space. Adversaries may acquire customer credentials via phishing or purchase, exploit weak vetting to create front-company accounts, or compromise provider portals/APIs to submit schedules, alter front-end settings, or exfiltrate collected data. Because traffic originates from “expected” stations and ASN ranges, misuse blends into normal operations. Multi-tenant risks include configuration bleed-over and shared management planes. | |
| RD-0002.03 | 3rd-Party Spacecraft | By compromising another operator’s spacecraft, or a hosted payload, an adversary can gain proximity, sensing, and relay capabilities that are costly to build from scratch and difficult to attribute. With control of an on-orbit asset, the actor may conduct local spectrum measurement and traffic analysis, attempt selective interference or spoofing at short range, or probe crosslinks and gateways where payload networks bridge to buses. In rideshare or hosted-payload contexts, weak segmentation and shared ground paths can provide insight into neighboring missions. More aggressive scenarios include remote proximity operations (RPO) to achieve advantageous geometry; however, physical grappling, docking, or exposure of debug/test interfaces is highly specialized and rare, with significant safety, legal, and tracking implications. Realistic attacker goals emphasize adjacency for RF leverage, covert relay, or data theft rather than mechanical capture. | |
| IA-0003 | Crosslink via Compromised Neighbor | Where spacecraft exchange data over inter-satellite links (RF or optical), a compromise on one vehicle can become a bridgehead to others. Threat actors exploit crosslink trust: shared routing, time distribution, service discovery, or gateway functions that forward commands and data between vehicles and ground. With knowledge of crosslink framing, addressing, and authentication semantics, an adversary can craft traffic that appears to originate from a trusted neighbor, injecting control messages, malformed service advertisements, or payload tasking that propagates across the mesh. In tightly coupled constellations, crosslinks may terminate on gateways that also touch the C&DH or payload buses, providing additional pivot opportunities. Because crosslink traffic is expected and often high volume, attacker activity can be timed to blend with synchronization intervals, ranging exchanges, or scheduled data relays. | |
| IA-0007 | Compromise Ground System | Compromising the ground segment gives an adversary the most direct path to first execution against a spacecraft. Ground systems encompass operator workstations and mission control mission control software, scheduling/orchestration services, front-end processors and modems, antenna control, key-loading tools and HSMs, data gateways (SLE/CSP), identity providers, and cloud-hosted mission services. Once inside, a threat actor can prepare on-orbit updates, craft and queue valid telecommands, replay captured traffic within acceptance windows, or manipulate authentication material and counters to pass checks. The same foothold enables deep reconnaissance: enumerating mission networks and enclaves, discovering which satellites are operated from a site, mapping logical topology between MOC and stations, identifying in-band “birds” reachable from a given aperture, and learning pass plans, dictionaries, and automation hooks. From there, initial access to the spacecraft is a matter of timing and presentation, injecting commands, procedures, or update packages that align with expected operations so the first execution event appears indistinguishable from normal activity. | |
| IA-0007.01 | Compromise On-Orbit Update | Adversaries may target the pipeline that produces and transmits updates to an on-orbit vehicle. Manipulation points include source repositories and configuration tables, build and packaging steps that generate images or differential patches, staging areas on ground servers, update metadata (versions, counters, manifests), and the transmission process itself. Spacecraft updates span flight software patches, FPGA bitstreams, bootloader or device firmware loads, and operational data products such as command tables, ephemerides, and calibration files, each with distinct formats, framing, and acceptance rules. An attacker positioned in the ground system can substitute or modify an artifact, alter its timing and timetags to match pass windows, and queue it through the same procedures operators use for nominal maintenance. Activation can be immediate or deferred: implants may lie dormant until a specific mode, safing entry, or table index is referenced. | |
| IA-0007.02 | Malicious Commanding via Valid GS | Adversaries may use a compromised, mission-owned ground system to transmit legitimate-looking commands to the target spacecraft. Because the ground equipment is already configured for the mission, correct waveforms, framing, dictionaries, and scheduling, the attacker’s traffic blends with routine operations. Initial access unfolds by inserting commands or procedures into existing timelines, modifying rate/size limits or command queues, or invoking maintenance dictionaries and rapid-response workflows that accept broader command sets. Pre-positioned scripts can chain actions across multiple passes and stations, while telemetry routing provides immediate feedback to refine follow-on steps. Exfiltration can be embedded in standard downlink channels or forwarded through gateways as ordinary mission data. The distinguishing feature is that command origin appears valid, transmitted from approved apertures using expected parameters, so the first execution event is not a protocol anomaly but a misuse of legitimate command authority obtained through the compromised ground system. | |
| IA-0008 | Rogue External Entity | Adversaries obtain a foothold by interacting with the spacecraft from platforms outside the authorized ground architecture. A “rogue external entity” is any actor-controlled transmitter, platform, or node, ground, maritime, airborne, or space-based. Most interact by radiating or exchanging traffic using mission-compatible waveforms, framing, or crosslink protocols. Others carry no mission-compatible capability at all, and instead apply interference, directed energy, or physical proximity to shape the conditions under which access becomes possible. The technique exploits the fact that many vehicles must remain commandable and discoverable over wide areas and across multiple modalities. Using public ephemerides, pass predictions, and knowledge of acquisition procedures, the actor times transmissions to line-of-sight windows, handovers, or maintenance periods. Initial access stems from presenting traffic that the spacecraft will parse or prioritize, such as syntactically valid telecommands, crafted ranging/acquisition exchanges, crosslink service advertisements, or payload/user-channel messages that bridge into the command/data path, or, for entities operating by effect rather than by protocol, from the contingency behavior those effects induce. | |
| IA-0008.01 | Rogue Ground Station | Adversaries may field their own ground system, transportable or fixed, to transmit and receive mission-compatible signals. A typical setup couples steerable apertures and GPS-disciplined timing with SDR/modems configured for the target’s bands, modulation/coding, framing, and beacon structure. Using pass schedules and Doppler/polarization predictions, the actor crafts over-the-air traffic that appears valid at the RF and protocol layers. | |
| EX-0001 | Replay | Replay is the re-transmission of previously captured traffic, over RF links, crosslinks, or internal buses, to elicit the same processing and effects a second time. Adversaries first observe and record authentic exchanges (telecommands, ranging/acquisition frames, housekeeping telemetry acknowledgments, bus messages), then resend them within acceptance conditions that the system recognizes, matching link geometry, timetags, counters, or mode states. The aim can be functional (re-triggering an action such as a mode change), observational (fingerprinting how the vehicle reacts at different states), or disruptive (saturating queues and bandwidth to crowd out legitimate traffic). Because replays preserve valid syntax and often valid context, they can blend with normal operations, especially during periods with reduced monitoring or when counters and windows reset (e.g., handovers, safing entries). On encrypted links, metadata replays (acquisition beacons, schedule requests) may still yield informative responses. | |
| EX-0001.01 | Command Packets | Threat actors may resend authentic-looking telecommands that were previously accepted by the spacecraft. Captures may include whole command PDUs with framing, CRC/MAC, counters, and timetags intact, or they may be reconstructed from operator tooling and procedure logs. When timing, counters, and mode preconditions align, the replayed packet can cause the same effect: toggling relays, initiating safing or recovery scripts, adjusting tables, commanding momentum dumps, or scheduling delta-v events. Even when outright execution fails, repeated “near-miss” injections can map acceptance windows, rate/size limits, and interlocks by observing the spacecraft’s acknowledgments and state changes. At scale, streams of valid-but-stale commands can congest command queues, delay legitimate activity, or trigger nuisance FDIR responses. | |
| PER-0004 | Replace Cryptographic Keys | The adversary cements control by changing the cryptographic material the spacecraft uses to authenticate or protect links and updates. Targets include uplink authentication keys and counters, link-encryption/session keys and key-encryption keys (KEKs), key identifiers/selectors, and algorithm profiles. Using authorized rekey commands or key-loading procedures, often designed for over-the-air use, the attacker installs new values in non-volatile storage and updates selectors so subsequent traffic must use the attacker’s keys to be accepted. Variants desynchronize anti-replay by advancing counters or switching epochs, or strand operators by flipping profiles to a mode for which only the adversary holds parameters. Once replaced, the new material persists across resets and mode changes, turning the spacecraft into a node that recognizes the adversary’s channel while rejecting former controllers. | |
| LM-0003 | Constellation Hopping via Crosslink | In networks where vehicles exchange data over inter-satellite links, a compromise on one spacecraft becomes a springboard to others. The attacker crafts crosslink traffic, routing updates, service advertisements, time/ephemeris distribution, file or tasking messages, that appears to originate from a trusted neighbor and targets gateway functions that bridge crosslink traffic into command/data paths. Once accepted, those messages can queue procedures, deliver configuration/table edits, or open file transfer sessions on adjacent vehicles. In mesh or hub-and-spoke constellations, this enables “hop-by-hop” spread: a single foothold uses shared trust and protocol uniformity to reach additional satellites without contacting the ground segment. | |
| LM-0004 | Visiting Vehicle Interface(s) | Docking, berthing, or short-duration attach events create high-trust, high-bandwidth connections between vehicles. During these operations, automatic sequences verify latches, exchange status, synchronize time, and enable umbilicals that carry data and power; maintenance tools may also push firmware or tables across the interface. An attacker positioned on the visiting vehicle can exploit these handshakes and service channels to inject commands, transfer files, or access bus gateways on the host. Because many actions are expected “just after dock,” malicious traffic can ride the same procedures that commission the interface, allowing lateral movement from the visiting craft into the target spacecraft’s C&DH, payload, or support subsystems. | |
| LM-0006 | Launch Vehicle Interface | During integration and ascent, payloads and the launch vehicle exchange power, discrete lines, and data via umbilicals, separation avionics, and shared EGSE networks. Protections can be reduced or heterogeneous because timelines are tight and responsibilities cross organizations. An attacker positioned on either side (vehicle or payload) can use these commissioning links, health/status queries, time distribution, inhibit lines, separation commands, or telemetry gateways, to inject messages, transfer files, or alter configuration that propagates across the interface. Before fairing close and prior to separation, this brief but high-trust coupling provides a route to move from one platform to the other and to seed artifacts that persist after deployment. | |
| LM-0006.01 | Rideshare Payload | In shared launches, multiple independent payloads cohabit common infrastructure until separation. If isolation is incomplete (e.g., shared data buses, mispartitioned deployer controllers, common logging/telemetry collectors, or cross-connected laptops and recorders), a compromise in one payload’s domain can be leveraged to observe or influence another’s traffic before release. Threat actors exploit these transient but real connections to read configuration, pivot through deployer control paths, or stage data/commands that execute as neighboring payloads power and check out, enabling cross-payload access or tampering prior to independent flight. | |
| EXF-0004 | Out-of-Band Communications Link | Some missions field secondary links, separate frequencies and hardware, for limited, purpose-built functions (e.g., rekeying, emergency commanding, beacons, custodial crosslinks). Adversaries co-opt these channels as covert data paths: embedding content in maintenance messages, beacon fields, or low-rate housekeeping; initiating vendor/service modes that carry file fragments; or switching to contingency profiles that bypass normal routing and monitoring. Because these paths are distinct from the main TT&C and may be sparsely supervised, they provide discreet avenues to move data off the spacecraft or to external relays without altering the primary link’s traffic patterns. | |
| IMP-0001 | [DEPRECATED] Deception (or Misdirection) | Measures designed to mislead an adversary by manipulation, distortion, or falsification of evidence or information into a system to induce the adversary to react in a manner prejudicial to their interests. Threat actors may seek to deceive mission stakeholders (or even military decision makers) for a multitude of reasons. Telemetry values could be modified, attacks could be designed to intentionally mimic another threat actor's TTPs, and even allied ground infrastructure could be compromised and used as the source of communications to the spacecraft. | |
| IMP-0006 | [DEPRECATED] Theft | Threat actors may attempt to steal the data that is being gathered, processed, and sent from the victim spacecraft. Many spacecraft have a particular purpose associated with them and the data they gather is deemed mission critical. By attempting to steal this data, the mission, or purpose, of the spacecraft could be lost entirely. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| CM0052 | Insider Threat Protection | Insider threats represent a distinct and particularly difficult risk category for space mission security, as individuals with authorized access to mission systems, facilities, and commanding infrastructure can cause significant damage without needing to overcome the external access controls that defend against outside adversaries. An insider threat program establishes the organizational, procedural, and technical controls necessary to deter, detect, and respond to malicious or negligent actions by personnel with legitimate access, including attempts by insiders to masquerade as other authorized individuals to access commanding functions or sensitive mission infrastructure under a false identity. The program must address both the technical controls that limit what any individual can do with their authorized access and the procedural and behavioral controls that create accountability, reduce opportunity, and enable early detection of concerning patterns. Effective insider threat protection requires integration across personnel security, access management, monitoring, and incident response functions, treating the insider threat as an ongoing operational risk to be managed continuously rather than a problem solved by initial personnel vetting alone. | AC-14 AC-3(11) AC-3(13) AC-3(15) AC-6 AT-2 AT-2(2) AT-2(4) AT-2(5) AT-2(6) AU-10 AU-12 AU-13 AU-6 AU-7 CA-7 CP-2 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) IA-4 IR-2(3) IR-4 IR-4(6) IR-4(7) MA-7 MP-7 PE-2 PL-8 PL-8(1) PM-12 PM-14 PS-3 PS-4 PS-5 PS-8 RA-10 SA-3 SA-8 SC-38 SC-7 SI-4 SR-11(2) | D3-OAM D3-AM D3-OM D3-CH D3-SPP D3-MFA D3-UAP D3-UBA | A.8.4 A.5.15 A.8.2 A.8.18 7.3 A.6.3 A.8.7 A.5.25 A.6.8 A.8.15 A.8.15 A.8.12 A.8.16 9.1 9.3.2 9.3.3 A.5.36 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.16 A.5.25 A.5.26 A.5.27 A.5.10 A.7.10 A.7.2 A.5.8 A.6.1 A.5.11 A.6.5 A.5.11 A.6.5 7.3 A.6.4 A.5.7 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.16 | |
| CM0054 | Two-Person Rule | The two-person rule (TPR) requires that all access to and actions within systems possessing command-level authority over the spacecraft be conducted in the continuous presence of two separately authorized individuals, neither of whom alone can complete the access or action. This control reduces the opportunity for unauthorized, coerced, erroneous, or malicious commanding by requiring two independently authorized individuals to participate in the protected access or action. Its effectiveness depends on individual attribution, independent review, resistance to credential sharing or account misuse, and protection against collusion or bypass of the enforcement mechanism. The TPR requires two distinct, appropriately authorized individuals to participate in the same protected access or action. Participation may be physically co-located, remotely performed through authenticated technical controls, or implemented through a combination of physical and logical mechanisms, as defined by mission policy. The second individual must independently review and approve the specific access or action before it is completed. Under CM0054, the two-person rule applies to access and actions involving systems with command-level access to the spacecraft to include reprograming the flight computer/flight software. If the mission tailors the rule to selected commanding functions, the retained scope, excluded access and actions, compensating controls, and associated risk acceptance must be explicitly documented and approved. | AC-14 AC-3(13) AC-3(15) AC-3(2) AU-9(5) CP-2 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) PE-3 SA-8(15) | D3-OAM D3-AM D3-ODM D3-OM D3-MFA | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.7.1 A.7.2 A.7.3 A.7.4 | |
| CM0079 | Maneuverability | Spacecraft maneuverability provides an active physical defense capability against kinetic and certain directed energy threats by enabling the satellite to relocate from a predicted intercept trajectory when a threat is detected with sufficient warning time. Against unguided projectiles, maneuvering out of the predicted impact trajectory can be effective, requiring only sufficient delta-v and warning time to execute a displacement maneuver before impact. Against guided threats, including direct-ascent anti-satellite (ASAT) weapons and co-orbital ASAT platforms equipped with onboard sensors, maneuverability is significantly more constrained in its effectiveness; evasion requires displacing the satellite beyond the seeker or sensor acquisition range of the guided warhead, which demands larger delta-v margins and more precise threat characterization than unguided intercept scenarios. The effectiveness of maneuverability as a countermeasure is therefore strongly dependent on the warning time provided by space domain awareness (SDA) capabilities, the propulsion capacity of the spacecraft, the fidelity of threat trajectory characterization, and whether the threat employs passive or active terminal guidance. Maneuverability also provides operational flexibility for avoiding predictable orbital slots that adversaries may have targeted in advance, complicating targeting planning even in the absence of an active threat event. | CP-10(6) CP-13 CP-2 CP-2(1) CP-2(3) CP-2(5) PE-20 PE-21 | None | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 A.5.29 A.5.10 | |
| CM0084 | Physical Seizure | Physical seizure capability employs spacecraft equipped with docking, manipulation, or proximity maneuvering systems to counter space-based threats and mitigate post-attack effects through direct physical interaction with other on-orbit objects. Primary applications include seizing or neutralizing a threatening satellite actively attacking or endangering other spacecraft, capturing a satellite that has been disabled or hijacked and is being operated for hostile purposes, and collecting and disposing of harmful orbital debris resulting from a kinetic attack. The effectiveness of a physical seizure system is fundamentally constrained by propellant and time: a seizure asset stored in a particular orbital regime cannot efficiently reach objects in significantly different orbits due to the delta-v required for large orbital plane changes or altitude transfers, making geostationary Earth orbit (GEO) assets poorly positioned to respond to threats in low Earth orbit (LEO) and vice versa. This constraint drives a basing trade between pre-positioned on-orbit assets and ground-based responsive-launch assets. On-orbit assets may provide shorter response times but remain limited by their current orbit, propellant reserves, and readiness state. Ground-based assets may be launched closer to the required orbital plane and altitude but remain constrained by launch readiness, vehicle performance, launch-site geometry, and the time required to reach and rendezvous with the target. | CP-13 PE-20 | D3-AM | A.5.29 A.5.10 | |
| CM0002 | COMSEC | Communications security (COMSEC) denies unauthorized parties access to information derived from telecommunications while ensuring the authenticity of those communications. COMSEC is commonly defined as a broad discipline that may encompass cryptographic security, transmission security, emissions security, cryptographic key management, traffic-flow security, and physical security of COMSEC material. Within SPARTA, these areas are further broken down through separate countermeasures, including CM0029 | TRANSEC, CM0030 | Crypto Key Management, CM0003 | TEMPEST/EMSEC, and CM0073 | Traffic Flow Analysis Defense. CM0002 provides the overarching communications-security context and supports the coordinated application of these specialized countermeasures. All mission links, particularly telemetry, tracking, and commanding (TT&C) links, should employ communications-security protections appropriate to the sensitivity, criticality, operational environment, and threat exposure of the information being exchanged. These protections may include cryptographic protection, transmission security, emissions security, traffic-flow protection, secure key management, and physical protection of COMSEC material, as addressed by the applicable specialized countermeasures. Spacecraft should not provide an operational mode that permits required cryptographic protection or command authentication on TT&C links to be bypassed or disabled. Operational, maintenance, test, recovery, and contingency modes should be considered when evaluating whether communications-security protections can be unintentionally or improperly circumvented. Communication receivers and associated signal-processing or TRANSEC mechanisms should detect and, when mission-defined criteria are met, reject or otherwise safely handle transmissions exhibiting anomalous signal characteristics consistent with communications deception. Cryptographic mechanisms should authenticate and integrity-check received content but should not be treated as RF-deception detectors. | AC-17 AC-17(1) AC-17(10) AC-17(2) AC-18 AC-18(1) AC-2(11) AC-3(10) CA-3 IA-4(9) IA-5 IA-5(7) IA-7 PL-8 PL-8(1) SA-8(18) SA-8(19) SA-9(6) SC-10 SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-13 SC-16(3) SC-28(1) SC-28(3) SC-7 SC-7(10) SC-7(11) SC-7(18) SC-7(5) SC-8(1) SC-8(3) SI-10 SI-10(3) SI-10(5) SI-10(6) SI-19(4) SI-3(8) | D3-ET D3-MH D3-MAN D3-MENCR D3-NTF D3-ITF D3-OTF D3-CH D3-DTP D3-NTA D3-CAA D3-DNSTA D3-IPCTA D3-NTCD D3-RTSD D3-PHDURA D3-PMAD D3-CSPP D3-MA D3-SMRA D3-SRA | A.5.14 A.6.7 A.8.1 A.8.16 A.5.14 A.8.1 A.8.20 A.5.14 A.8.21 A.5.16 A.5.17 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.12 A.5.33 A.8.20 A.8.24 A.8.24 A.8.26 A.5.31 A.5.33 A.8.11 | |
| CM0030 | Crypto Key Management | Effective cryptographic key management is a foundational requirement for all mission encryption and authentication functions; the security of cryptographic implementations is only as strong as the protection afforded to the keys those implementations rely upon. Key management must conform to recognized cryptographic guidance and address the full lifecycle applicable to each key type, including generation or establishment, distribution, storage, activation, use, replacement, deactivation or revocation, recovery where authorized, compromise response, and destruction. Only approved cryptographic algorithms, key generation methods, key distribution techniques, and authentication mechanisms may be used; the use of unapproved, deprecated, or custom cryptographic primitives is prohibited regardless of perceived functional adequacy. Encryption key handling must be performed outside of onboard software and protected through dedicated cryptographic mechanisms, preventing keys from being exposed through software vulnerabilities, memory inspection, or software-level debugging interfaces. Secret and private key material must not be retrievable in plaintext through telecommands, telemetry, diagnostic outputs, debugging interfaces, or other externally accessible mechanisms, regardless of the privilege level of the requesting entity. | CM-3(6) PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-9(6) SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-28(3) SC-8(1) | D3-CH D3-CP | A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 A.8.24 | |
| CM0031 | Authentication | All command-bearing sessions, frames, or messages involving spacecraft command links, crosslinks, or relay services shall provide cryptographic authentication of the command origin and integrity verification before commands are accepted. Mutual or bidirectional authentication shall be required where both endpoints must authenticate one another and the link and protocol architecture support that exchange. Acquisition requirements should mandate cryptographically based, bidirectional authentication for all command sessions across external links, including ground-to-spacecraft uplinks, spacecraft-to-spacecraft crosslinks, and any relay or intermediary ground station connections, with authentication required aBidirectional authentication enables both communicating entities to verify each other’s identity and helps prevent impersonation. Authentication establishes identity but does not by itself authorize a command, protect mission-data confidentiality, or prevent session hijacking. Command acceptance must also enforce authorization, and authenticated sessions or security associations must maintain integrity and replay resistance so that subsequent traffic remains bound to the authenticated entities. Beyond external links, authentication is strongly recommended for spacecraft internal bus communications and onboard inter-component connections, as an adversary with access to internal interfaces, whether through a compromised component or a physical access event, should face the same authentication barrier as an external adversary attempting to inject commands from outside the spacecraft. | AC-14 AC-17 AC-17(10) AC-17(2) AC-18 AC-18(1) IA-2 IA-3(1) IA-4 IA-4(9) IA-7 IA-9 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(1) SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) SI-7(6) | D3-MH D3-MAN D3-CH D3-BAN D3-MFA D3-TAAN D3-CBAN | A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.5.16 A.5.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 | |
| CM0033 | Relay Protection | Replay attacks capture and later retransmit previously valid authentication messages, frames, credentials, or tokens. Relay attacks forward an authentication exchange in real time between legitimate endpoints, causing an endpoint to authenticate a connection or action that the adversary is relaying without requiring compromise of the underlying cryptographic keys. Relay- and replay-resistant authentication mechanisms must be implemented when establishing remote connections or security associations with the spacecraft and for authenticated communications on spacecraft internal buses. The protections must prevent previously accepted authentication material or authenticated traffic from being reused outside its authorized context. Replay resistance should use freshness and anti-reuse mechanisms such as nonces, sequence numbers, timestamps where operationally suitable, and managed anti-replay windows. Relay resistance additionally requires authentication to be cryptographically bound to the intended endpoints, security association, session or channel context, and authenticated action. Challenge-response authentication provides replay resistance when fresh challenges are used but does not, by itself, prevent an adversary from relaying the challenge and response between legitimate endpoints. These protections must be applied at both external interface boundaries, including ground-to-spacecraft command links and crosslinks, and internal spacecraft bus connections where component-to-component authentication is implemented. | AC-17(10) IA-2(8) IA-3 IA-3(1) IA-4 IA-7 SC-13 SC-16(1) SC-23 SC-23(1) SC-23(3) SC-7 SC-7(11) SC-7(18) SI-10 SI-10(5) SI-10(6) SI-3(8) | D3-ITF D3-NTA D3-OTF | A.5.16 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.24 A.8.26 A.5.31 | |
| CM0003 | TEMPEST | TEMPEST controls (i.e., emissions security (EMSEC)) protect spacecraft system components, internal data communications, and communication buses against side-channel and proximity-based attacks that exploit unintended electromagnetic, electrical, or acoustic emanations. Critical components must be enclosed within appropriate casings or shielding structures that attenuate unintended emissions to levels that deny adversaries the ability to reconstruct processed data or infer system state from externally observable signals. Shielding must extend to internal buses and data pathways, not only to individual processing elements, as inter-component communications represent a significant and often overlooked emanations surface. The physical enclosure strategy must be integrated with the broader system architecture so that shielding effectiveness is not degraded by penetrations, connectors, or cable routing that create unintended emissions paths. During sustainment & maintenance, Spacecraft TEMPEST and EMSEC protections are primarily established during design, fabrication, and integration, but sustainment remains applicable through configuration control, review of deployment-state or hardware changes, preservation of qualification evidence, assessment of relevant anomalies, and evaluation of refurbishment, replacement, or follow-on production changes. The guidance below addresses these spacecraft considerations as well as applicable ground-segment maintenance activities. | PE-19 PE-19(1) PE-21 SC-8(3) | D3-PH D3-RFS | A.7.5 A.7.8 A.8.12 | |
| CM0050 | On-board Message Encryption | Authentication controls on the spacecraft internal bus verify the identity of communicating components but do not protect the confidentiality of the data in transit; an adversary with access to the bus, whether through a compromised component, a hardware implant, or a physical access event, can observe all unencrypted inter-component communications regardless of whether authentication is enforced. Encrypting data traversing the spacecraft internal bus protects the confidentiality of selected message content from entities that can observe the bus but do not possess authorization and the applicable cryptographic keys. The protection does not prevent disclosure to a compromised component that legitimately possesses the decryption key, and it may not conceal unencrypted protocol headers, addressing information, message timing, or traffic volume. Bus encryption should be considered for bus segments or message types carrying information whose unauthorized disclosure would create unacceptable mission, security, privacy, or operational risk. Criticality alone does not establish a confidentiality requirement. Where confidentiality is required, encryption must be combined with message integrity, source authentication, and replay protection through an approved authenticated-encryption mechanism or an appropriately composed set of cryptographic protections. | AC-4 AC-4(23) AC-4(24) AC-4(26) AC-4(31) AC-4(32) PL-8 PL-8(1) SA-3 SA-8 SA-8(18) SA-8(19) SA-8(9) SA-9(6) SC-13 SC-16 SC-16(1) SC-16(2) SC-16(3) SC-8(1) SC-8(3) SI-19(4) SI-4(10) SI-4(25) | D3-MH D3-MENCR D3-ET | A.5.14 A.8.22 A.8.23 A.8.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 A.8.24 A.8.26 A.5.31 A.8.11 | |
| CM0036 | Session Termination | Where session-oriented communications are used between ground systems and spacecraft, between ground system components, or across internal spacecraft interfaces, the associated connection or session must be terminated upon completion or after a period of inactivity exceeding a threshold defined in the mission’s concept of operations (CONOPS). Failure to terminate idle or completed sessions leaves authenticated connections open and exploitable, providing adversaries with an opportunity to inject commands or data into an existing authenticated session without needing to complete the authentication process independently. Inactivity timeout thresholds must be established through the CONOPS process rather than set arbitrarily, balancing the security benefit of rapid session termination against the operational consequences of terminating a session that an operator or automated process may legitimately require across a contact gap or processing delay. Session termination must invalidate the associated session identifiers, authorization state, and cryptographic session state so that the terminated session cannot be reused. Where secure session resumption is operationally required, it must use a mission-approved, cryptographically protected mechanism with defined validity limits and must not permit reuse of expired, revoked, or invalidated session state. | AC-12 AC-12(2) SC-10 SI-14(3) SI-4(7) | D3-SDA | A.8.20 | |
| CM0055 | Secure Command Mode(s) | Secure command modes provide additional layers of restriction on spacecraft command acceptance beyond standard authentication and encryption, constraining when, where, and under what operational conditions the spacecraft will process commands. These supplemental controls reduce the window of opportunity for unauthorized commanding by limiting command receptivity to defined parameters that an adversary would need to satisfy simultaneously with authentication requirements, substantially increasing the difficulty of a successful command injection attack. Specific implementations include geographic restriction, in which the spacecraft accepts commands only when in contact with designated ground station locations; operational mode restrictions, in which special flight software (FSW) modes must be active before certain command categories are accepted; and temporal controls, in which the spacecraft enforces time-bounded windows during which commands are valid. These mechanisms complement command authentication, integrity protection, anti-replay controls, and authorization and do not replace them. Encryption should also be applied where command confidentiality is required. Secure command modes may combine geographic, temporal, operational-state, source, or other mission-defined conditions according to the active command policy. Secure command modes helps create a multi-dimensional command acceptance policy that an adversary must defeat in its entirety to achieve unauthorized command execution. | AC-17(1) AC-17(10) AC-2(11) AC-2(12) AC-3 AC-3(2) AC-3(3) AC-3(4) AC-3(8) CA-3(7) IA-10 PL-8 PL-8(1) SA-3 SA-8 SC-7 SI-3(8) | D3-AH D3-ACH D3-MFA D3-OTP | A.8.16 A.5.15 A.5.33 A.8.3 A.8.4 A.8.18 A.8.20 A.8.2 A.8.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 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 | Nearly all D3FEND Techniques apply to Ground | None | |
| CM0034 | Monitor Critical Telemetry Points | Monitoring defined spacecraft telemetry points provides a key source of evidence for detecting adversary activity against on-orbit systems, where observability is largely limited to the events and conditions the spacecraft can sense, record, and report. Monitored telemetry must include both accepted and rejected commands, command mode transitions, command counters, and other indicators of commanding activity, enabling detection of unauthorized command attempts that fail authentication as well as anomalous patterns in legitimate command traffic. Monitoring scope should include RF and link-quality indicators that support detection and triage of interference or suspected jamming. These indicators should be correlated with expected link conditions and other available evidence before hostile activity is concluded. Security-relevant telemetry should be integrated and time-correlated with ground-based defensive cyber operations infrastructure, including security information and event management (SIEM) and audit platforms, to provide unified space-system cybersecurity situational awareness. The resulting view should correlate spacecraft observations with relevant ground-system security events while accounting for telemetry latency, contact availability, and other observability limitations. | AC-17(1) AU-3(1) CA-7(6) IR-4(14) PL-8 PL-8(1) SA-8(13) SC-16 SC-16(1) SC-7 SI-3(8) SI-4(7) | D3-NTA D3-PM D3-PMAD D3-RTSD | A.8.16 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 | |
| CM0035 | Protect Authenticators | Authenticators and associated authenticator material, including passwords, secret and private keys, tokens, biometric templates, shared secrets, certificates, and trust-store entries, must be protected against unauthorized modification and, where the material is confidential, unauthorized disclosure throughout their lifecycle. Disclosure of secret authenticator material may enable adversaries to impersonate legitimate users or systems. Unauthorized modification of authenticators, certificates, or trust information can deny access to legitimate entities, substitute adversary-controlled credentials, or corrupt the trust basis of mission authentication mechanisms. Protection must apply to authenticators at rest, in transit, and in use, and must extend to all forms and storage locations, including credential databases, configuration files, embedded device credentials, hardware security tokens, and cryptographic key stores. Authenticator protection is a prerequisite for the effectiveness of any authentication-based access control; an authentication system whose authenticators are unprotected provides no meaningful security regardless of the strength of the underlying authentication protocol. | AC-17(6) AC-3(11) CM-3(6) IA-4(9) IA-5 IA-5(6) PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(13) SA-8(19) SC-16 SC-16(1) SC-8(1) | D3-CE D3-ANCI D3-CA D3-ACA D3-PCA D3-CRO D3-CTS D3-SPP | A.8.4 A.5.16 A.5.17 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 | |
| CM0053 | Physical Security Controls | Physical security controls form the outermost defensive layer protecting systems that can command the spacecraft, limiting access to commanding infrastructure to personnel who are both identity-verified and specifically authorized to be in those environments. Unauthorized physical access may enable theft, tampering, connection to exposed interfaces, use of unattended sessions, or attempts to extract or alter protected information. Physical security must therefore complement authentication, encryption, session management, tamper protection, and other technical controls rather than assume those controls will remain sufficient without protection of the underlying equipment. Physical security measures for commanding facilities and infrastructure must use layered controls selected according to the facility threat environment, system criticality, site characteristics, and consequence of unauthorized access. Controls may include perimeter barriers, controlled entry points, interior protected areas, identity and authorization verification, locks, intrusion detection, surveillance, and security personnel. Access to the facility must not, by itself, authorize physical access to commanding systems. Physical security controls must be commensurate with the sensitivity and criticality of the commanding functions they protect, with the most sensitive commanding capabilities requiring the most stringent physical access restrictions. | AC-14 CA-3(6) CA-8 CA-8(1) CA-8(3) PE-2 PE-2(1) PE-2(3) PE-3 PE-3(1) PE-3(2) PE-3(3) PE-3(5) PE-3(7) SA-3 SA-8 SC-12(6) SC-51 SC-8(5) SR-11(2) | D3-RFS D3-AM | A.7.2 A.7.1 A.7.2 A.7.3 A.7.4 A.8.12 A.7.4 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | |
| CM0070 | Alternate Communications Paths | Establishing alternate communications paths for spacecraft and ground system operations reduces the likelihood that a single adversarial event, physical disruption, or technical failure will deny all mission communications. Reliance on a single communications pathway creates a single point of failure that adversaries can exploit through jamming, denial of service against ground infrastructure, physical disruption of a ground station, or compromise of network connectivity, any of which could result in complete loss of commanding and telemetry capability. Alternate paths must be assessed end to end for shared failure modes and operational dependencies. Differences in frequency, ground station, relay service, or network provider provide meaningful resilience only when the paths do not remain dependent on the same critical spacecraft, ground, management, or service infrastructure. The selection and configuration of alternate paths must be governed by the mission's concept of operations (CONOPS), which defines the conditions under which each path is used, the priority and switchover procedures between paths, and the minimum communications capability that must be maintained to satisfy mission safety and operational continuity requirements. | AC-17 CP-2 CP-4(2) CP-8(3) PL-8 PL-8(1) SC-47 | D3-NM D3-NTPM | A.5.14 A.6.7 A.8.1 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.8 | |
| CM0032 | On-board Intrusion Detection & Prevention | An on-board intrusion detection and prevention system (IDS/IPS) monitors mission-critical spacecraft components and systems, generates and stores audit records, and supports mission-approved responses to detected threats. Depending on the mission architecture, threat, and availability of ground support, responses may be autonomous, ground-directed, or a combination of both. The system should address both known attack patterns and previously unseen anomalous behavior through complementary signature-based and behavior- or anomaly-based detection methods. Machine learning or adaptive technologies may be used when their performance, resource consumption, and failure behavior have been validated for the mission environment. Detection and response coverage should address applicable adversary activities across the attack lifecycle, including initial access, execution, persistence, defense evasion, and exfiltration. The on-board IDS/IPS must be integrated with the spacecraft's traditional fault management system to provide a unified approach to anomaly response, ensuring that cyber-triggered responses are compatible with fault management logic and do not produce unintended effects or fratricide against the spacecraft's own systems; countermeasures that are incompatible with fault management are considered unsafe and must not be executed autonomously. The response hierarchy must prioritize vehicle safety and continued mission operations. Advanced containment or deception responses may be considered when they can be executed without unacceptable mission risk. The system should preserve evidence that supports post-event analysis, threat characterization, and potential attribution by authorized ground support. | AU-14 AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(2) AU-5(5) AU-6(1) AU-6(4) AU-8 AU-9 AU-9(2) AU-9(3) CA-7(6) CM-11(3) CP-10 CP-10(4) IR-4 IR-4(11) IR-4(12) IR-4(14) IR-4(5) IR-5 IR-5(1) PL-8 PL-8(1) RA-10 RA-3(4) SA-8(21) SA-8(22) SA-8(23) SC-16(2) SC-32(1) SC-5 SC-5(3) SC-7(10) SC-7(9) SI-10(6) SI-16 SI-17 SI-3 SI-3(10) SI-3(8) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(13) SI-4(16) SI-4(17) SI-4(2) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-4(7) SI-6 SI-7(17) SI-7(8) | D3-FA D3-DA D3-FCR D3-FH D3-ID D3-IRA D3-HD D3-IAA D3-FHRA D3-NTA D3-PMAD D3-RTSD D3-ANAA D3-CA D3-CSPP D3-ISVA D3-PM D3-SDM D3-SFA D3-SFV D3-SICA D3-USICA D3-FBA D3-FEMC D3-FV D3-OSM D3-PFV D3-EHB D3-IDA D3-MBT D3-SBV D3-PA D3-PSMD D3-PSA D3-SEA D3-SSC D3-SCA D3-FAPA D3-IBCA D3-PCSV D3-FCA D3-PLA D3-UBA D3-RAPA D3-SDA D3-UDTA D3-UGLPA D3-ANET D3-AZET D3-JFAPA D3-LAM D3-NI D3-RRID D3-NTF D3-ITF D3-OTF D3-EI D3-EAL D3-EDL D3-HBPI D3-IOPR D3-KBPI D3-MAC D3-SCF | A.8.15 A.8.15 A.8.6 A.8.17 A.5.33 A.8.15 A.8.15 A.5.29 A.5.25 A.5.26 A.5.27 A.5.8 A.5.7 A.8.12 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16 | |
| CM0067 | Smart Contracts | Smart contracts provide an automated, consensus-based enforcement mechanism for security protocols governing data exchange across a spacecraft bus, particularly in hosted payload architectures where multiple independently operated payloads or subsystems share common infrastructure. By encoding security rules as deterministic contract logic, participating validator nodes can evaluate authenticated observations of bus activity and reach consensus on whether a defined violation occurred. A trusted bus controller, gateway, or access-control mechanism must then enforce any approved restriction because the smart contract itself cannot directly observe or block physical bus traffic. This approach is directly applicable to scenarios where a hosted payload is compromised or behaves maliciously, as the smart contract framework can detect the violation, achieve consensus among the remaining bus participants, and enforce exclusion of the offending payload before the attack propagates to other bus components or the host spacecraft. The consensus mechanism should prevent a single participating node from causing payload exclusion when the approved quorum and membership rules require agreement from multiple independent validators. Its effectiveness depends on the validator architecture, quorum threshold, communication assumptions, and number of compromised or unavailable validators. Smart contract-based enforcement is particularly valuable in multi-tenant spacecraft architectures where payload operators are organizationally distinct from the spacecraft bus operator and cannot be governed through a single chain of administrative control. | IA-9 SI-4 SI-4(2) | D3-AM D3-PH D3-LFP D3-SCP | A.8.16 | |
| CM0037 | Disable Physical Ports | Physical data connection, debug, programming, and maintenance interfaces (e.g., joint test action group (JTAG)) that are not required for spacecraft operations must be disabled, removed, or otherwise made inaccessible before spacecraft operations begin. Interfaces required for operational functions must be explicitly identified and protected against unauthorized physical access and use. These interfaces, essential during development for programming, debugging, and testing, represent persistent attack surfaces in the operational environment: an adversary with physical access to the spacecraft before launch, during ground handling, or at a shared launch facility could exploit active debug interfaces to read memory, modify firmware, bypass security controls, or implant persistent malicious code without leaving detectable traces in software-visible logs. Disabling or removing unused physical interfaces closes a direct hardware-access pathway and reduces reliance on procedural controls or physical security alone. The capability to disable these interfaces must be designed into the system from the outset, as physical removal or reliable hardware-enforced disablement cannot be easily retrofitted into a completed board design. | AC-14 MA-7 PL-8 PL-8(1) SA-3 SA-4(5) SA-4(9) SA-8 SC-41 SC-7(14) | D3-EI D3-IOPR | A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | |
| CM0065 | OSAM Dual Authorization | Before a cooperative OSAM engagement enters a protected proximity, capture, docking, mating, or servicing phase, the servicing spacecraft must be authenticated and the specific engagement authorized by both the serviced asset’s mission control authority and, where technically capable, the serviced asset itself. Authentication establishes the identity of the servicer, while dual authorization requires two independent approval decisions for the proposed activity. The approvals may be sequential rather than simultaneous but must both remain valid and be bound to the same servicer, client, service scope, mission phase, interfaces, operational constraints, and validity period. Failure to obtain or maintain authorization must cause the serviced asset to withhold cooperation and interface enablement and must invoke the approved hold, retreat, or abort response. These controls reduce the risk of unauthorized servicing but cannot physically prevent a hostile or non-cooperative spacecraft from approaching the asset. | CA-3(6) IA-2(1) IA-2(2) IA-2(6) | D3-OAM D3-AM D3-ODM D3-OM D3-MFA | None | |
| CM0029 | TRANSEC | Transmission security (TRANSEC) is the component of communications security (COMSEC) concerned with protecting the characteristics of the transmission itself, as distinct from protecting the content of the information being communicated. TRANSEC controls reduce the likelihood, effectiveness, or operational impact of transmission interception, signal disruption, communications deception, and exploitation of transmission characteristics within the defined threat model. Applicable TRANSEC techniques include jam-resistant waveforms that increase resistance to jamming and communications deception, spread spectrum and frequency hopping techniques that reduce signal predictability and improve resistance to interception and disruption, low probability of intercept and low probability of detection (LPI/LPD) signal designs that reduce transmission observability, and transmission scheduling or pattern discipline that limits the intelligence value of traffic analysis. TRANSEC requirements should be applied to mission communication links according to link criticality (e.g., TT&C, crosslinks), threat exposure, and operational consequence. TRANSEC must be treated as a distinct layer of protection complementary to, but not a substitute for, cryptographic protection of information content. | AC-17 AC-18 AC-18(5) CA-3 CP-8 PL-8 PL-8(1) SA-8(19) SC-16 SC-16(1) SC-40 SC-40(1) SC-40(3) SC-40(4) SC-5 SC-8(1) SC-8(3) SC-8(4) | D3-MH D3-MAN D3-MENCR D3-NTA D3-DNSTA D3-ISVA D3-NTCD D3-RTA D3-PMAD D3-FC D3-CSPP D3-ANAA D3-RPA D3-IPCTA D3-NTCD D3-NTPM D3-TAAN | A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.5.14 A.8.21 A.5.29 A.7.11 A.5.8 A.5.33 | |