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.

Sources

CCSDS 355.0-B-2 — Space Data Link Security Protocol

CCSDS 357.0-B-1 — CCSDS Authentication Credentials

ID: CM0033

Tier: I

Onboard SV CM Ground CM

Created: 2022/10/19

Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should explicitly address relay and replay resistance as distinct authentication properties, separate from basic authentication requirements, recognizing that an authentication mechanism can be cryptographically sound yet still vulnerable to relay or replay exploitation if session binding and freshness controls are not implemented. Requirements should specify that remote connection or security-association establishment with the spacecraft, and authenticated communications on spacecraft buses, employ mechanisms with demonstrable relay and replay resistance, with the specific freshness and session-binding mechanisms to be used documented in the system security architecture. Contract language should require that relay and replay resistance be verified through adversarial testing that captures and retransmits authentication exchanges, confirms that retransmitted material is rejected, and validates that session tokens cannot be transferred between connections or sessions. Flow-down provisions should require that subcontractors developing communication subsystems, bus interfaces, or command handling components implement relay and replay-resistant authentication at their respective interfaces. Evaluation criteria should assess offerors' proposed authentication mechanisms for explicit relay and replay resistance properties, and should require that the security architecture submission demonstrate how freshness and session binding are enforced across all authenticated interfaces.

Pre-Operations Developer/Supplier

Relay and replay protections should be incorporated into communication and bus protocol design because they affect message formats, security-association state, timing, and interoperability. Adding these protections later may require substantial protocol and implementation changes. Nonces used as authentication challenges must be unique or statistically unique for the applicable key and authentication context. Replay state should be maintained using a mechanism appropriate to the protocol, such as challenge state, sequence counters, or a managed anti-replay window, so that previously accepted authentication messages cannot be accepted again. Where timestamp-based replay protection is used, validity checks must account for communication delay, clock accuracy, and expected drift. Timestamp-based mechanisms should be used only when the mission can maintain sufficiently reliable time synchronization and a validity window that provides meaningful replay resistance. Challenge-response authentication provides replay resistance when the verifier generates a fresh challenge and the response is cryptographically bound to that challenge and the intended authentication context. Additional endpoint, channel, or transaction binding is required to address relay attacks because a fresh challenge and its valid response may otherwise be forwarded between legitimate endpoints. For spacecraft bus authentication, the selected mechanism must be compatible with the protocol’s timing, bandwidth, and state-management constraints. Following resets, power cycling, or loss of synchronization, anti-replay state must either be securely preserved or reestablished through an authenticated resynchronization process before protected communications are accepted.

Sustainment & Maintenance Government

Operational maintenance of relay and replay-resistant authentication requires that the state management components of the prevention mechanisms, including nonce databases, sequence number counters, and timestamp synchronization, be monitored for correct function and included in the system's configuration management baseline. Any software update that modifies authentication handling, session management, or bus communication logic must be validated through end-to-end relay and replay resistance testing before deployment, as updates to adjacent code can inadvertently disable or weaken freshness controls. Clock synchronization between the spacecraft and ground systems, which underpins timestamp-based replay prevention, should be monitored for drift that could cause legitimate authentication exchanges to be rejected as replays or widen the effective validity window to a degree that reduces replay resistance. Anomalous authentication patterns detected in operational logs, such as repeated submission of identical authentication tokens or authentication attempts at unexpected times or from unexpected sources, should be flagged for investigation as potential indicators of relay or replay attack attempts.

Sustainment & Maintenance Developer/Supplier

Techniques Addressed by Countermeasure

ID		Name	Description
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-0004		Secondary/Backup Communication Channel	Adversaries pursue alternative paths to the spacecraft that differ from the primary TT&C in configuration, monitoring, or authentication. Examples include backup MOC/ground networks, contingency TT&C chains, maintenance or recovery consoles, low-rate emergency beacons, and secondary receivers or antennas on the vehicle. These channels exist to preserve commandability during outages, safing, or maintenance; they may use different vendors, legacy settings, or simplified procedures. Initial access typically pairs reconnaissance of failover rules with actions that steer operations onto the backup path, natural events, induced denial on the primary, or simple patience until scheduled tests and handovers occur. Once traffic flows over the alternate path, the attacker leverages its distinct procedures, dictionaries, or rate/size limits to introduce commands or data that would be harder to inject on the primary.
	.01	Ground Station	Threat actors may target the backup ground segment, standby MOC sites, alternate commercial stations, or contingency chains held in reserve. Threat actors establish presence on the backup path (operator accounts, scheduler/orchestration, modem profiles, antenna control) and then exploit moments when operations shift: planned exercises, maintenance at the primary site, weather diversions, or failover during anomalies. They may also shape conditions so traffic is re-routed, e.g., by saturating the primary’s RF front end or consuming its schedules, without revealing their involvement. Once on the backup, prepositioned procedures, macros, or configuration sets allow command injection, manipulation of pass timelines, or quiet collection of downlink telemetry.
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.
	.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.
	.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.
	.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.
	.02	Rogue Spacecraft	Adversaries may employ their own satellite or hosted payload to achieve proximity and a privileged RF geometry. After phasing into the appropriate plane or drift orbit, the rogue vehicle operates as a local peer: emitting narrow-beam or crosslink-compatible signals, relaying user-channel traffic that the target will honor, or advertising services that appear to originate from a trusted neighbor. Close range reduces path loss and allows highly selective interactions, e.g., targeted spoofing of acquisition exchanges, presentation of crafted routing/time distribution messages, or injection of payload tasking that rides established inter-satellite protocols. The rogue platform can also perform spectrum and protocol reconnaissance in situ, refining message formats and timing before attempting first execution.
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.
	.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.
	.02	Bus Traffic Replay	Instead of the RF path, the attacker targets internal command/data handling by injecting or retransmitting messages on the spacecraft bus (e.g., 1553, SpaceWire, custom). Because many subsystems act on the latest message or on message rate rather than on uniqueness, a flood of historical yet well-formed frames can consume bandwidth, starve critical publishers, or cause subsystems to perform the same action repeatedly. Secondary effects include stale sensor values being re-consumed, watchdog timers being reset at incorrect intervals, and autonomy rules misclassifying the situation due to out-of-order but valid-looking events. On time-triggered or scheduled buses, replaying at precise offsets can collide with or supersede legitimate messages, steering system state without changing software. The goal is to harness the bus’s determinism, repeating prior internal stimuli to recreate prior effects or to induce resource exhaustion.
PER-0003		Ground System Presence	The adversary maintains long-lived access by residing within mission ground infrastructure that already has end-to-end reach to the spacecraft. Persistence can exist in operator workstations and mission control software, schedulers/orchestrators, station control (antenna/mount, modem/baseband), automation scripts and procedure libraries, identity and ticketing systems, and cloud-hosted mission services. With this foothold, the actor can repeatedly queue commands, updates, or file transfers during routine passes; mirror legitimate operator behavior to blend in; and refresh their tooling as software is upgraded. Presence on the ground also supports durable reconnaissance (pass plans, dictionaries, key/counter states) and continuous staging so each window to the vehicle can be exploited without re-establishing access.
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.
EXF-0001		Replay	The adversary re-sends previously valid commands or procedures to cause the spacecraft to transmit data again, then captures the resulting downlink. Typical targets are recorder playbacks, payload product dumps, housekeeping snapshots, or file directory listings. By aligning replays with geometry (e.g., when the satellite is in view of actor-controlled apertures) and with acceptance conditions (counters, timetags, mode), the attacker induces legitimate transmissions that appear routine to operators. Variants include selectively replaying index ranges to fetch only high-value intervals, reissuing subscription/telemetry-rate changes to increase data volume, or queueing playbacks that fire during later passes when interception is feasible.

Space Threats Addressed by Countermeasure

ID	Description
SV-AC-1	Attempting access to an access-controlled system resulting in unauthorized access
SV-AC-2	Replay of recorded authentic communications traffic at a later time with the hope that the authorized communications will provide data or some other system reaction
SV-CF-1	Tapping of communications links (wireline, RF, network) resulting in loss of confidentiality; Traffic analysis to determine which entities are communicating with each other without being able to read the communicated information
SV-IT-1	Communications system spoofing resulting in denial of service and loss of availability and data integrity

Sample Requirements

SPARTA ID	Requirement	Rationale/Additional Guidance/Notes
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-15	The [spacecraft] shall implement cryptographic mechanisms to identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters.{SV-AV-1,SV-IT-1}{AC-3,AC-20,SA-8(19),SC-8(1),SC-23(3),SC-40(3),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}	Adversaries may attempt imitative RF signals to inject commands or manipulate spacecraft behavior. Signal parameter validation (modulation, power, timing, waveform characteristics) strengthens command authentication beyond cryptographic validation alone. This helps mitigate spoofing, replay, and rogue emitter attacks. RF-layer validation complements cryptographic controls.
SPR-18	The [spacecraft] shall protect the confidentiality and integrity of information during preparation for transmission, transmission, and reception, in accordance with the [organization]‑provided encryption matrix.{SV-AC-7}{AC-3,SA-8(19),SC-8,SC-8(1),SC-8(2),SC-16,SC-16(1),SC-40}	* Preparation for transmission and during reception includes the aggregation, packing, and transformation options performed prior to transmission and the undoing of those operations that occur upon receipt.
SPR-19	The [spacecraft] shall encrypt all telemetry on downlink regardless of operating mode to protect current state of spacecraft.{SV-CF-4}{AC-3(10),RA-5(4),SA-8(18),SA-8(19),SC-8,SC-8(1),SC-13}	Telemetry exposes real-time spacecraft state and configuration. Unencrypted telemetry can reveal vulnerabilities, operational status, or targeting information. Enforcing encryption across all modes prevents intelligence collection and mission state inference. This mitigates passive RF interception threats.
SPR-21	The [spacecraft], when transferring information between different security domains, shall implement security‑policy filters that require fully enumerated formats that restrict data structure and content.{SV-AC-6}{AC-3(3),AC-3(4),AC-4(14),IA-9,SA-8(19),SC-16,SI-10}	Fully enumerated formats prevent injection of malformed or malicious data across security domains. This reduces parser exploitation, data smuggling, and covert channel abuse. Strict domain filtering supports deterministic and auditable inter-domain communication. Only explicitly defined data structures should be permitted.
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-33	The [spacecraft] shall utilize TRANSEC. TRANSEC shall be implemented and verified as a distinct layer in coordination with Traffic Flow Security and RF anti‑fingerprinting.{SV-AV-1}{CP-8,RA-5(4),SA-8(18),SA-8(19),SC-8(1),SC-8(4),SC-16,SC-16(1),SC-16(2),SC-16(3),SC-40,SC-40(4)}	Transmission Security (TRANSEC) is used to ensure the availability of transmissions and limit intelligence collection from the transmissions. TRANSEC is secured through burst encoding, frequency hopping, or spread spectrum methods where the required pseudorandom sequence generation is controlled by a cryptographic algorithm and key. Such keys are known as transmission security keys (TSK). The objectives of transmission security are low probability of interception (LPI), low probability of detection (LPD), and antijam which means resistance to jamming (EPM or ECCM).
SPR-34	The [spacecraft] shall recover to a known cyber-safe state when an anomaly is detected.{IR-4,IR-4(1),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-10(6),SI-13,SI-17}
SPR-46	The [spacecraft] shall monitor [Program‑defined telemetry points] for malicious commanding attempts and alert ground operators upon detection.{SV-AC-2,SV-IT-1,SV-DCO-1}{AC-17,AC-17(1),AC-17(10),AU-3(1),RA-10,SC-7,SC-16,SC-16(2),SC-16(3),SI-3(8),SI-4,SI-4(1),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}	Telemetry-based detection enables identification of anomalous command patterns, replay attempts, and injection attacks. Early detection allows rapid containment before mission impact escalates. Onboard monitoring is critical when ground latency limits intervention. This supports proactive defense.
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-49	The [spacecraft] shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with CNSSP 12 and applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{IA-7,SC-8(1),SC-13,SI-12}
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-88	The [spacecraft] shall detect and recover from detected memory errors or transitions to a known cyber-safe state.{SV-IT-4,SV-AV-6}{IR-4,IR-4(1),SA-8(16),SA-8(24),SI-3,SI-4(7),SI-10(6),SI-13,SI-17}	Memory corruption may result from radiation, fault injection, or malicious manipulation. Detection prevents silent data corruption from propagating to mission-critical functions. Recovery mechanisms or safe-state transitions preserve availability. Rapid containment supports mission survivability.
SPR-93	The [spacecraft] shall require multi‑factor authorization for: (a) all spacecraft operating system and application updates; (b) updates to task‑scheduling functionality; and (c) creation or update of onboard stored command sequences.{SV-SP-9,SV-SP-11}{AC-3(2),CM-3(8),CM-5,IA-2,PM-12,SA-8(8),SA-8(31),SA-10(2),SI-3(8),SI-7(12),SI-10(6)}	The intent is for multiple checks to be performed prior to executing these SV SW updates. One action is mere act of uploading the SW to the spacecraft. Another action could be check of digital signature (ideal but not explicitly required) or hash or CRC or a checksum. Crypto boxes provide another level of authentication for all commands, including SW updates but ideally there is another factor outside of crypto to protect against FSW updates. Multi-factor authorization could be the "two-man rule" where procedures are in place to prevent a successful attack by a single actor (note: development activities that are subsequently subject to review or verification activities may already require collaborating attackers such that a "two-man rule" is not appropriate).
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-97	All [spacecraft] commands which have unrecoverable consequence must have dual authentication prior to command execution. The [spacecraft] shall verify two independent cryptographic approvals prior to execution and shall generate an audit record binding both approver identifiers to the command identifier, time, and outcome.{SV-AC-4,SV-AC-8,SV-AC-2}{AU-9(5),IA-3,IA-4,IA-10,PE-3,PM-12,SA-8(15),SA-8(21),SC-16(2),SC-16(3),SI-3(8),SI-3(9),SI-4(13),SI-4(25),SI-7(12),SI-10(6),SI-13}	Commands with irreversible impact require heightened assurance to prevent catastrophic mission loss. Dual independent cryptographic approvals mitigate insider threat, key compromise, and single-point credential abuse. Binding approver identifiers to the audit trail strengthens accountability and deterrence. This reduces the probability of unauthorized hazardous command execution.
SPR-98	The [spacecraft] shall have a method to ensure the integrity of which have unrecoverable consequence and validate their authenticity before execution.{SV-AC-2,SV-IT-2,SV-IT-1}{AU-9(5),IA-3,IA-4,IA-10,PE-3,PM-12,SA-8(15),SA-8(21),SC-16(2),SC-16(3),SI-3(8),SI-3(9),SI-4(13),SI-4(25),SI-7(12),SI-10(6),SI-13}	Hazardous commands must be cryptographically protected and validated prior to execution. Integrity and authenticity checks prevent replay, modification, or injection of destructive instructions. Without validation, RF interception or command path compromise could result in mission-ending actions. This ensures critical commands are both authorized and unaltered.
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-106	The [spacecraft] shall provide non-identical methods, or functionally independent methods, for commanding a mission critical function when the software is the sole control of that function.{AC-3(2),SI-3(8),SI-13}
SPR-116	The [organization] shall ensure reused TT&C software has adequate uniqueness for command decoders/dictionaries so that commands are received by only the intended satellite.{SV-SP-6}{AC-17(10),SC-16(3),SI-3(9)}	The goal is to eliminate risk that compromise of one command database does not affect a different one due to reuse. The intent is to ensure that one SV can not process the commands from another SV. Given the crypto setup with keys and VCC needing to match, this requirement may be inherently met as a result of using type-1 cryptography. The intent is not to recreate entire command dictionaries but have enough uniqueness in place that it prevents a SV from receiving a rogue command. As long as there is some uniqueness at the receiving end of the commands, that is adequate.
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-128	The [spacecraft] shall accept hazardous commands only when prerequisite checks are satisfied.{SV-AC-8,SV-AV-5}{AC-17(4),SI-10,SI-10(6)}	Precondition validation ensures hazardous commands are executed only under safe system states. This prevents execution under anomalous or compromised conditions. Independent verification reduces false activation risk. Safety and cyber controls must be integrated.
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-130	The [spacecraft] shall discriminate between valid and invalid input into the software and rejects invalid input.{SV-SP-1,SV-IT-2}{SC-16(2),SI-3(8),SI-10,SI-10(3),SI-10(6)}	Input validation prevents buffer overflows, injection, and parser exploitation. Rejecting malformed or unexpected data reduces denial-of-service and corruption risks. Deterministic validation improves resilience. Robust input handling is fundamental to secure software.
SPR-131	The [spacecraft] shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission.{SV-AC-2,SV-AV-4}{SC-16(2),SI-4(13),SI-4(25),SI-10,SI-10(6),SI-13}	Command sequencing enforces operational logic and safety interlocks. Out-of-sequence commands may bypass safeguards. Sequence enforcement prevents replay and control manipulation. This preserves control flow integrity.
SPR-132	The [spacecraft] software subsystems shall accept [Program defined hazardous] commands only when prerequisite checks are satisfied.{SV-MA-3,SV-AV-7}{SI-10}
SPR-133	The [spacecraft] software subsystems shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission.{SV-MA-3,SV-AV-7}{SI-10}
SPR-134	The [spacecraft] software subsystems shall perform prerequisite checks for the execution of hazardous commands.{SV-MA-3,SV-AV-7}{SI-10}
SPR-135	The [organization] shall ensure that all viable commands are known to the mission and SV "owner.{SV-AC-8}{SI-10,SI-10(3)}	This is a concern for bus re-use. It is possible that the manufacturer left previously coded commands in their syntax rather than starting from a clean slate. This leaves potential backdoors and other functionality the mission does not know about.
SPR-136	The [organization] shall perform analysis of critical (backdoor) commands that could adversely affect mission success if used maliciously.{SV-AC-8}{SI-10,SI-10(3)}	Heritage and commercial products often have many residual operational (e.g., hardware commands) and test capabilities that are unidentified or unknown to the end user, perhaps because they were not expressly stated mission requirements. These would never be tested and their effects unknown, and hence, could be used maliciously. Test commands not needed for flight should be deleted from the flight database.
SPR-137	The [spacecraft] shall only use or include [organization]-defined critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted.{SV-AC-8}{SI-10,SI-10(3)}	The intent is protect against misuse of critical commands. On potential scenario is where you could use accounts with different privileges, could require an additional passphrase or require entry into a different state or append an additional footer to a critical command. There is room for design flexibility here that can still satisfy this requirement.
SPR-138	The [spacecraft] software subsystems shall discriminate between valid and invalid input into the software and rejects invalid input.{SV-MA-3,SV-AV-7}{SI-10,SI-10(3)}
SPR-139	The [spacecraft] software subsystems shall properly handle spurious input and missing data.{SV-MA-3,SV-AV-7}{SI-10,SI-10(3)}
SPR-140	The [spacecraft] shall properly handle spurious input and missing data.{SV-SP-1,SV-AV-6}{SI-10,SI-10(3),SI-10(6)}	Spurious or missing data may indicate attack or fault conditions. Robust handling prevents cascading failures. Defensive programming ensures safe defaults and fallback states. This reduces exploitability of abnormal input conditions.
SPR-141	The [spacecraft] shall perform prerequisite checks for the execution of hazardous commands.{SI-10,SI-10(6),SI-13}
SPR-142	The [spacecraft] shall only use or include critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted.{SI-3(8),SI-10,SI-10(3)}
SPR-144	The [spacecraft] shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit, or perform a hazardous action.{SV-AC-8,SV-MA-3}{SI-10(3),SI-10(6),SI-13}	Redundant validation mechanisms ensure hazardous transitions cannot occur through single-point compromise. Independent parameters strengthen control integrity. This reduces exploit paths for inhibit removal. Critical operations demand dual validation logic.
SPR-145	The [spacecraft] mission/cyber critical commands shall be "complex" or diverse from other commands so that a single bit flip could not transform a benign command into a hazardous command.{SV-MA-3,SV-AV-7}{SI-10(5)}	Complex command encoding reduces risk of single-bit errors causing hazardous action. Diversity prevents accidental transformation into destructive instructions. This protects against radiation-induced bit flips and malicious bit manipulation. Safety and cyber resiliency intersect here.
SPR-146	The [spacecraft] shall provide at least one independent command for each operator-initiated action used to shutdown a function leading to or reducing the control of a hazard.{SV-MA-5,SV-MA-3}{SI-10(5)}	Independent shutdown commands ensure operators retain control during anomalous conditions. Redundant control paths reduce systemic failure risk. This supports safe recovery from hazardous states. Separation enhances mission survivability.
SPR-147	The [spacecraft] software subsystems shall provide at least one independent command for each operator-initiated action used to shut down a function leading to or reducing the control of a hazard.{SV-MA-3,SV-AV-7}{SI-10(5)}
SPR-245	The [organization] shall define processes and procedures to be followed when integrity verification tools detect unauthorized changes to software, firmware, and information.{SV-IT-2}{CM-3,CM-3(1),CM-3(5),CM-5(6),CM-6,CP-2,IR-6,IR-6(2),PM-30,SC-16(1),SC-51,SI-3,SI-4(7),SI-4(24),SI-7,SI-7(7),SI-7(10)}	Predefined response procedures reduce reaction time. Clear escalation paths improve containment. Consistent handling prevents confusion during incidents. Preparedness strengthens resilience.
SPR-246	The [organization] shall ensure that all Electrical, Electronic, Electro-mechanical & Electro-optical (EEEE) and mechanical piece parts procured from the Original Component Manufacturer (OCM) or their authorized distribution network.{SA-8(9),SA-8(11),SA-12,SA-12(1),SC-16(1),SR-1,SR-5}
SPR-389	The [organization] shall perform analysis of critical backdoor commands that could adversely affect mission success if used maliciously.{SV-AC-8}{SI-10,SI-10(3)}	Backdoor or maintenance commands may bypass safeguards if misused. Analysis identifies high-impact commands requiring additional controls. Understanding abuse potential reduces catastrophic misuse. Preventive governance strengthens operational assurance.
SPR-457	The [spacecraft] shall verify cryptographic integrity and origin of data at each relay hop before forwarding information between internal components, payloads, crosslinks, and ground.{SV-IT-1,SV-IT-2,SV-AC-3}{CA-3(7),SC-8(1),SC-13,SC-23}	End-to-end security alone is insufficient in multi-hop spacecraft architectures. Verifying integrity and origin at each relay prevents compromised subsystems from forwarding malicious data laterally. Hop-by-hop validation limits propagation of injected commands or payload tampering. This enforces zero-trust principles internally.
SPR-464	The [spacecraft] shall accept command and telemetry sessions from [organization]-authorized alternate ground or relay providers only when presented with valid cryptographic credentials and whitelisted link characteristics.{SV-IT-1,SV-AC-4,SV-MA-7}{AC-17,SC-23}	Accepting sessions only from authorized, cryptographically verified providers prevents rogue ground station compromise. Whitelisted link characteristics reduce spoofing risk. Strict admission control strengthens link-layer assurance. This supports TRANSEC alignment.
SPR-490	The [spacecraft] shall ensure cross domain exchanges occur only through [organization] defined, verified guards that enforce format, rate, and content checks.{SV-AC-6,SV-IT-2}{AC-4,SC-7,SC-32(1)}	Verified guards ensure controlled data exchange. Format and rate checks prevent covert channel exploitation. Enforced mediation supports mandatory control. Guarded exchange strengthens isolation.
SPR-501	The [organization] shall assign and record unique cryptographic identities for flight-critical hardware components, firmware images, and software builds and shall maintain an authoritative registry mapping identities to approved suppliers and versions.{SV-SP-4,SV-SP-5}{SR-4(1),IA-3}	Unique identities enable provenance tracking. Registry mapping supports supplier validation. Identity governance strengthens supply chain assurance. Structured attestation supports lifecycle integrity.
SPR-502	The [spacecraft] shall report component and software identities and version fingerprints in telemetry at boot and upon changes to support provenance verification.{SV-SP-4,SV-MA-4}{SR-4(1),IA-3}	On-orbit reporting enables real-time provenance verification. Version fingerprints support anomaly detection. Transparency reduces silent drift. Telemetry-based attestation strengthens oversight.
SPR-522	The [organization] shall implement a canonical time base and identifiers (station ID, session ID, command ID/APID, image/bitstream IDs) across TT&C front ends, consoles, and on‑board logs and shall de‑duplicate and gap‑detect during aggregation with rules for the source of truth for command history.{SV-IT-1,SV-AC-2,SV-DCO-1}{AU-6,AU-6(4),AU-8,IA-4}	Unified identifiers prevent ambiguity in command history. Gap detection identifies dropped or spoofed entries. Clear source-of-truth logic prevents dispute. Time discipline strengthens forensic precision.
SPR-543	The [spacecraft] shall complement link‑layer protections with per‑message MACs/signatures for commands and selected telemetry so integrity and origin assurance persist across relays and storage/forwarding; operator feedback shall distinguish corruption vs. integrity vs. authentication failures.{SV-IT-1,SV-AC-2}{AC-17(10),SC-8,SC-8(2)}	Storage/forwarding relays can break link-layer trust. Message-level MACs preserve end-to-end assurance. Clear error distinctions aid operators. Layered integrity strengthens trust continuity.
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.

Relay Protection

Sources

Pre-Operations Government

Pre-Operations Developer/Supplier

Sustainment & Maintenance Government

Sustainment & Maintenance Developer/Supplier

NIST Rev5 Controls

D3FEND Techniques

D3FEND Artifacts

ISO 27001

NASA Best Practice Guide

ESA Space Shield Mitigation

Related MITRE EMB3D Mitigations

Related CSF 2.0

Related BSI Security Measures

Techniques Addressed by Countermeasure

Space Threats Addressed by Countermeasure

Sample Requirements