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.

ID: CM0034

Tier: I

Onboard SV CM Ground CM

Created: 2022/10/19

Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should mandate the definition of a monitored telemetry point list as a program deliverable, specifying the commanding, RF, and operational health telemetry parameters to be collected and evaluated for security-relevant anomalies, with the list derived from the mission's threat model and criticality analysis. Requirements should specify that telemetry designs include both accepted and rejected command records, with sufficient metadata, including timestamps, command identifiers, source indicators, and rejection reason codes, to support security event reconstruction and forensic analysis. Contract language should require that ground system designs include integration between the telemetry processing pipeline and defensive cyber operations infrastructure, such as SIEM platforms, enabling correlated analysis of spacecraft telemetry and ground system security events in a unified operational picture. Evaluation criteria should assess offerors' proposed telemetry monitoring architectures, their experience designing telemetry systems for security monitoring purposes, and their proposed approach to SIEM integration for space system situational awareness. Verification should include demonstration that the monitoring system correctly detects and records both successful and rejected command events and that telemetry data is accessible to the ground-based security monitoring infrastructure in operationally useful timescales.

Pre-Operations Developer/Supplier

Telemetry architecture design must explicitly account for security monitoring requirements alongside operational health and status functions, with security-relevant telemetry points identified during the threat modeling process and included in the telemetry definition before the command and data handling subsystem design is finalized. Command telemetry should be designed to capture sufficient context for each command event, including whether the command was accepted or rejected, the basis for rejection, and any available source or session information, so that the telemetry record supports security analysis rather than providing only functional status. RF monitoring telemetry should include available receiver and link-quality measurements, with sampling, aggregation, and retention sufficient to support detection and triage of interference events within mission resource constraints to support detection of transient interference events that may indicate adversary activity. Ground system architectures should establish automated data pipelines that route security-relevant telemetry to SIEM or equivalent platforms for correlation with ground system audit logs, network security events, and threat intelligence feeds, enabling analysts to view the complete space system security posture rather than spacecraft and ground system events in isolation. Alert thresholds and correlation rules applied to monitored telemetry points should be defined during the design phase, informed by the threat model, and validated through simulation or testbed exercises before operational deployment.

Sustainment & Maintenance Government

Operational telemetry monitoring requires that alert thresholds and SIEM correlation rules be maintained as living configurations, updated as the spacecraft's nominal operating profile evolves and as new threat intelligence identifies patterns that warrant additional detection coverage. Baseline profiles for monitored telemetry should be established and reviewed when mission phases, spacecraft configuration, environmental conditions, aging, or operational patterns materially change expected behavior. Baseline changes should be validated and controlled to prevent anomalous or adversary-influenced behavior from being incorporated as normal activity. Each security-relevant telemetry anomaly, including rejected commands, unexpected mode transitions, and RF interference events, should be investigated through a defined triage process that assesses whether the anomaly represents a benign operational condition, a system fault, or a potential adversary action, with escalation procedures defined for each outcome. SIEM integration pipelines should be monitored for health and continuity, as a failure in the telemetry-to-SIEM data pathway would create a monitoring blind spot that reduces the organization's ability to detect and respond to adversary activity during the outage period. Records of security-relevant telemetry events and investigation outcomes should be retained for the duration of the mission, supporting trend analysis, post-incident forensics, and threat intelligence development.

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-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.
IA-0009		Trusted Relationship	Adversaries obtain first execution by riding connections that the mission already trusts, formal interconnections with partners, vendors, and user communities. Once a third party is compromised, the actor inherits that entity’s approved routes into mission enclaves: VPNs and jump hosts into ground networks, API keys into cloud tenants, automated file drops that feed command or update pipelines, and collaboration spaces where procedures and dictionaries circulate. Because traffic, credentials, and artifacts originate from known counterparts, the initial execution event can appear as a routine payload task, scheduled procedure, or software update promoted through established processes.
	.02	Vendor	Vendors that design, integrate, or support mission systems often hold elevated, persistent routes into operations: remote administration of ground software and modems, access to identity providers and license servers, control of cloud-hosted services, and authority to deliver firmware, bitstreams, or patches. Attackers who compromise a vendor’s enterprise or build environment can assume these roles, issuing commands through approved consoles, queuing updates in provider-operated portals, or invoking maintenance procedures that the mission expects the vendor to perform. Some vendor pathways terminate directly on RF equipment or key-management infrastructure; others ride cross-account cloud roles or managed SaaS backends that handle mission data and scheduling.
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.
EX-0013		Flooding	Flooding overwhelms a communication or processing path by injecting traffic at rates or patterns the system cannot comfortably absorb. In space contexts this can occur across layers: RF/optical links (continuous carriers, wideband noise, or protocol-shaped bursts); link/protocol layers (valid-looking frames at excessive cadence); application layers (command and telemetry messages that saturate parsers and queues); and internal vehicles buses where repeated messages starve critical publishers. Effects range from outright denial of service, dropped commands, lost telemetry, missed windows, to subtler corruption, such as out-of-order processing, watchdog trips, or autonomy entering protective modes due to backlogged health data. Secondary impacts include power and thermal strain as decoders, modems, or software loops spin at maximum duty, storage filling from retries, and control loops jittering when their messages are delayed. Timing matters: floods during handovers, maneuvers, or safing transitions can magnify consequences because margins are thinnest.
	.01	Valid Commands	Here the adversary saturates paths with legitimate telecommands or bus messages so the spacecraft burns scarce resources honoring them. Inputs may be innocuous (no-ops, time queries, telemetry requests) or low-risk configuration edits, but at scale they consume command handler cycles, fill queues, generate events and logs, trigger acknowledgments, and provoke downstream work in subsystems (e.g., repeated state reports, mode toggles, or file listings). On internal buses, valid actuator or housekeeping messages replayed at high rate can starve higher-priority publishers or cause control laws to chase stale stimuli. Because the traffic is syntactically correct, and often contextually plausible, the system attempts to process it rather than discard it early, increasing CPU usage, memory pressure, and power draw. Consequences include delayed or preempted legitimate operations, transient loss of commandability, and knock-on FDIR activity as deadlines slip and telemetry appears inconsistent.
	.02	Erroneous Input	In this variant, the attacker injects non-useful energy or data, noise, malformed frames, or near-valid messages, so receivers and parsers labor to acquire, decode, and reject it. At the RF layer, wideband or protocol-shaped interference drives AGC and clock recovery to hunt, elevates BER, and forces repeated acquisitions; at the link layer, frames with correct preambles but bad CRCs keep decoders busy while yielding no payload; at the application layer, malformed packets force parse/validate/deny cycles that still consume CPU and fill error logs. On internal buses, collisions or bursts of misaddressed traffic reduce effective bandwidth and reorder legitimate messages. Even though little of the injected content passes semantic checks, the effort of dealing with it crowds out real work and may trigger retransmission storms or fallback modes that further increase load. The hallmark is volumetric invalid activity, crafted to engage front ends and parsers just long enough, that degrades integrity and availability without relying on privileged or authenticated commands.
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.
DE-0002		Disrupt or Deceive Downlink	Threat actors may target any point in the telemetry chain, onboard generation and transmission, the downlink path itself, or ground-side reception, processing, and display, to disrupt the operator’s visibility into spacecraft health and activity. This may involve denial-based attacks that prevent the spacecraft from transmitting telemetry to the ground (e.g., disabling telemetry links or crashing telemetry software), or more subtle deception-based attacks that manipulate telemetry content to conceal unauthorized actions. Since telemetry is the primary method ground controllers rely on to monitor spacecraft status, any disruption or manipulation can delay or prevent detection of malicious activity, suppress automated or manual mitigations, or degrade trust in telemetry-based decision support systems.
	.02	Jam Link Signal	Threat actors may overwhelm/jam the downlink signal to prevent transmitted telemetry signals from reaching their destination without severe modification/interference, effectively leaving ground controllers unaware of vehicle activity during this time. Telemetry is the only method in which ground controllers can monitor the health and stability of the spacecraft while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place.
DE-0003		On-Board Values Obfuscation	The adversary manipulates housekeeping and control values that operators and autonomy rely on to judge activity, health, and command hygiene. Targets include command/telemetry counters, event/severity flags, downlink/reporting modes, cryptographic-mode indicators, and the system clock. By rewriting, freezing, or biasing these fields, and by selecting reduced or summary telemetry modes, unauthorized actions can proceed while the downlinked picture appears routine or incomplete. The result is delayed recognition, misattribution to environmental effects, or logs that cannot be reconciled post-facto.
	.01	Vehicle Command Counter (VCC)	The VCC tracks how many commands the spacecraft has accepted. An adversary masks activity by zeroing, freezing, or selectively decrementing the VCC, or by steering actions through paths that do not increment it (maintenance dictionaries, alternate receivers, hidden handlers). They may also overwrite the telemetry field that reports the VCC so ground displays show a lower or steady count while high volumes of commands are processed. This breaks simple “command volume” heuristics and makes bursty activity look normal.
	.02	Rejected Command Counter	This counter records commands that failed checks or were refused. To hide probing and trial-and-error, the adversary suppresses increments, periodically clears the value, or forges the downlinked field so rejection rates appear benign. Variants also tamper with associated reason codes or event entries, replacing them with innocuous outcomes. Analysts reviewing telemetry see no evidence of failed attempts even as the system is being exercised aggressively.
	.03	Command Receiver On/Off Mode	By toggling receiver enable states (per-receiver, per-antenna, or per-band), the adversary creates deliberate “quiet windows” in which outside intervention cannot arrive. Turning a command receiver off, or shifting to a configuration that ignores the primary path, allows queued actions or onboard procedures to run without interruption, while operators perceive a transient loss of commandability consistent with geometry or environment. Brief, well-timed toggles can also desynchronize counters and handovers, complicating reconstruction of what occurred.
	.04	Command Receivers Received Signal Strength	Threat actors may target the on-board command receivers received signal parameters (i.e., automatic gain control (AGC)) in order to stop specific commands or signals from being processed by the spacecraft. For ground controllers to communicate with spacecraft in orbit, the on-board receivers need to be configured to receive signals with a specific signal to noise ratio (ratio of signal power to the noise power). Targeting values related to the antenna signaling that are modifiable can prevent the spacecraft from receiving ground commands.
	.05	Command Receiver Lock Modes	Receivers advertise acquisition states, bit lock, frame lock, and command lock, that indicate readiness to accept telecommands. Adversaries leverage these indicators in two ways: (1) use command-lock tests to validate geometry, power, Doppler, and polarization without risking visible command execution; and (2) tamper with the values that report lock status so ground views never show that lock was achieved. Techniques include freezing or clearing lock flags and counters, raising/lowering internal thresholds so lock occurs without being reported (or vice versa), and timing brief lock intervals between telemetry samples. The result is a window where the spacecraft is receptive to commands while downlinked status suggests otherwise.
	.06	Telemetry Downlink Modes	Spacecraft expose modes that control what telemetry is sent and how, real-time channels, recorder playback, beacon/summary only, event-driven reporting, and per-virtual-channel/APID selections. By switching modes or editing the associated parameters (rates, filters, playback queues, index ranges), an adversary can thin, defer, or reroute observability. Typical effects include suppressing high-rate engineering streams in favor of minimal beacons, delaying playback of time periods of interest, replaying benign segments, or redirecting packets to alternate virtual channels that are not routinely monitored. Telemetry continues to flow, but it no longer reflects the activity the operators need to see.
	.07	Cryptographic Modes	Many missions separate authentication from confidentiality and allow on-orbit selection of algorithms, keys, profiles, or “crypto off/clear” states. Adversaries manipulate these mode controls and selectors to desynchronize ground and space or to hide content: flipping to a profile that the ground is not using, requesting clear telemetry while maintaining authenticated uplink, or rotating key IDs so frames validate internally but appear undecodable to external tools. Mode indicators and status words can also be biased so ground displays show expected settings while the link actually operates under attacker-chosen parameters, masking command and data exchanges within normal-looking traffic.
	.08	Received Commands	Spacecraft typically maintain histories of accepted, rejected, and executed commands, buffers, logs, or file records that can be downlinked on demand or periodically. An adversary conceals activity by editing or pruning these artifacts: removing entries, altering opcodes or arguments, rewriting timestamps and source identifiers, rolling logs early, or repopulating with benign-looking commands to balance counters. Related acknowledgments and event records may be suppressed or reclassified so cross-checks appear consistent. After manipulation, the official command history shows a plausible narrative that omits or mischaracterizes the adversary’s actions.
	.09	System Clock for Evasion	The adversary biases the spacecraft’s authoritative time so that telemetry, event logs, and command histories appear shifted or inconsistent. By writing clock registers, altering disciplining sources (e.g., GNSS vs. free-running oscillator), or tweaking distribution services and offsets, they can make stored commands execute “earlier” or “later” on the timeline and misalign acknowledgments with actual actions. Downlinked frames still carry plausible timestamps near packet headers, but those stamps no longer reflect when data was produced, complicating reconstruction of sequences and masking causality during incident analysis.
	.10	GPS Ephemeris	A satellite with a GPS receiver can use ephemeris data from GPS satellites to estimate its own position in space. A hostile actor could spoof the GPS signals to cause erroneous calculations of the satellite’s position. The received ephemeris data is often telemetered and can be monitored for indications of GPS spoofing. Reception of ephemeris data that changes suddenly without a reasonable explanation (such as a known GPS satellite handoff), could provide an indication of GPS spoofing and warrant further analysis. Threat actors could also change the course of the vehicle and falsify the telemetered data to temporarily convince ground operators the vehicle is still on a proper course.
	.11	Watchdog Timer (WDT) for Evasion	By modifying watchdog parameters or who “pets” them, an adversary shapes what evidence survives. Extending or disabling timeouts allows long-running processes to operate without forced resets that would expose abnormal CPU or power usage; conversely, shortening windows or relocating the petting source to a low-level ISR can induce frequent resets that wipe volatile traces, break correlation in logs, and explain anomalies as “spurious reboots.” In both directions, the watchdog becomes a timing tool for hiding activity rather than a guardrail against it.
	.13	Trusted Process Reporting Suppression	Adversaries may leverage process injection methods to execute malicious functionality within trusted onboard software processes in order to suppress, delay, filter, or selectively conceal telemetry and operational reporting associated with unauthorized activity. By operating inside legitimate telemetry handlers, flight software tasks, middleware, or operating system services, attackers can interfere with the generation, aggregation, or transmission of monitoring data before it is downlinked or processed by onboard monitoring systems. Unlike direct modification of individual operational values, this technique focuses on manipulating the reporting path itself to prevent malicious activity from being observed, correlated, or reconstructed by operators or autonomy systems. Examples may include suppressing telemetry associated with unauthorized commands, filtering fault events prior to downlink, selectively disabling event reporting during malicious operations, delaying housekeeping updates, or preventing monitoring services from publishing anomalous state information.
DE-0004		Masquerading	The adversary presents themselves as an authorized origin so activity appears legitimate across RF, protocol, and organizational boundaries. Techniques include crafting telecommand frames with correct headers, counters, and dictionaries; imitating station “fingerprints” such as Doppler, polarization, timing, and framing; replaying or emulating crosslink identities; and using insider-derived credentials or roles to operate mission tooling. Masquerading can also target metadata, virtual channel IDs, APIDs, source sequence counts, and facility identifiers, so logs and telemetry attribute actions to expected entities. The effect is that commands, file transfers, or configuration changes are processed as if they came from approved sources, reducing scrutiny and delaying detection.
DE-0010		Overflow Audit Log	The adversary hides activity by exhausting finite on-board logging and telemetry buffers so incriminating events are overwritten before they can be downlinked. Spacecraft typically use ring buffers with severity filters, per-subsystem quotas, and scheduled dump windows; by generating bursts of benign but high-frequency events (file listings, status queries, low-severity housekeeping, repeated mode toggles) or by provoking chatter from chatty subsystems, the attacker accelerates rollover. Variants target recorder indexes and event catalogs so new entries displace older ones, or they align floods with known downlink gaps and pass handovers when retention is shortest. To analysts on the ground, logs appear present but incomplete, showing a plausible narrative that omits the very interval when unauthorized commands or updates occurred.
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-IT-5	Onboard control procedures (i.e., ATS/RTS) that execute a scripts/sets of commands
SV-AV-5	Using fault management system against you. Understanding the fault response could be leveraged to get satellite in vulnerable state. Example, safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of TLM to cause action from ground, or some sort of RPO to cause S/C to go into safe mode;
SV-DCO-1	Not knowing that you were attacked, or attack was attempted
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
SV-AV-1	Communications system jamming resulting in denial of service and loss of availability and data integrity

Sample Requirements

SPARTA ID	Requirement	Rationale/Additional Guidance/Notes
SPR-4	The [spacecraft] security implementation shall ensure that information should not be allowed to flow between partitioned applications unless explicitly permitted by the system.{SV-AC-6,SV-MA-3,SV-SP-7}{AC-3(3),AC-3(4),AC-4,AC-4(6),AC-4(21),CA-9,IA-9,SA-8(3),SA-8(18),SA-8(19),SC-2(2),SC-7(29),SC-16,SC-32}	Strict partitioning prevents compromise of one application from cascading into mission-critical subsystems. Many spacecraft attacks exploit flat architectures where subsystems implicitly trust one another. Explicit inter-partition authorization limits lateral movement and privilege escalation. This supports containment and fault isolation under both cyber and fault conditions.
SPR-7	The [organization] shall document and design a security architecture using a defense-in-depth approach that allocates the [organization]s defined safeguards to the indicated locations and layers: [Examples include: operating system abstractions and hardware mechanisms to the separate processors in the platform, internal components, and the FSW].{SV-MA-6}{CA-9,PL-7,PL-8,PL-8(1),SA-8(3),SA-8(4),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30)}	Spacecraft security cannot rely on a single control; layered defenses reduce the likelihood of catastrophic compromise. Documenting safeguard allocation across hardware, OS, firmware, and FSW ensures coverage across attack surfaces. This supports resiliency against both cyber intrusion and supply chain weaknesses. Clear documentation enables verification and independent assessment.
SPR-8	The [organization] shall ensure that the allocated security safeguards operate in a coordinated and mutually reinforcing manner.{SV-MA-6}{CA-7(5),PL-7,PL-8(1),SA-8(19)}	Independent controls that operate in isolation may create security gaps or conflicting behaviors. Coordinated safeguards ensure that encryption, authentication, partitioning, and monitoring functions reinforce each other rather than undermine availability or safety. This reduces bypass risk and improves fault/cyber response integration. Cohesive operation is essential for resilient mission assurance.
SPR-9	The [organization] shall implement a security architecture and design that provides the required security functionality, allocates security controls among physical and logical components, and integrates individual security functions, mechanisms, and processes together to provide required security capabilities and a unified approach to protection.{SV-MA-6}{PL-7,SA-2,SA-8,SA-8(1),SA-8(2),SA-8(3),SA-8(4),SA-8(5),SA-8(6),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30),SC-32,SC-32(1)}	Security functionality must be intentionally distributed across physical and logical components rather than bolted on post-design. A unified architecture prevents inconsistent enforcement, duplicated controls, or unprotected interfaces. Integrated design reduces attack surface and improves verification of mission-critical protections.
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-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-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-25	The [spacecraft] shall prevent unauthorized access to system resources by employing an efficient capability based object model that supports both confinement and revocation of these capabilities when the platform security deems it necessary.{SV-AC-6}{AC-3(8),IA-4(9),PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(18),SA-8(19),SC-2(2),SC-4,SC-16,SC-32,SI-3}	Capability models restrict access to explicit, revocable tokens of authority. This enforces least privilege and supports dynamic revocation under threat conditions. Confinement reduces damage radius of compromised processes. Revocation capability enables adaptive cyber response.
SPR-27	The [spacecraft] shall define the security functions and security-relevant information for which the system must protect from unauthorized access.{SV-MA-4,SV-MA-6}{AC-6(1),SA-8(19),SC-7(13),SC-16}	Clearly identifying security-relevant functions ensures protections are applied to the correct assets. Undefined security boundaries create ambiguity and inconsistent enforcement. Explicit definition supports verification, testing, and threat modeling. This forms the basis for risk-informed control allocation.
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-53	The [organization] shall employ automated tools that provide notification to ground operators upon discovering discrepancies during integrity verification.{CM-3(5),CM-6,IR-6,IR-6(2),SA-8(21),SC-51,SI-3,SI-4(7),SI-4(12),SI-4(24),SI-7(2)}
SPR-56	The [spacecraft] shall provide automated onboard mechanisms that integrate audit review, analysis, and reporting processes to support mission processes for investigation and response to suspicious activities to determine the attack class in the event of a cyber attack.{SV-DCO-1}{AU-6(1),IR-4,IR-4(1),IR-4(12),IR-4(13),PM-16(1),RA-10,SA-8(21),SA-8(22),SC-5(3),SI-3,SI-3(10),SI-4(7),SI-4(24),SI-7(7)}	* Identifying the class (e.g., exfiltration, Trojans, etc.), nature, or effect of cyberattack (e.g., exfiltration, subverted control, or mission interruption) is necessary to determine the type of response. The first order of identification may be to determine whether the event is an attack or a non-threat event (anomaly). The objective requirement would be to predict the impact of the detected signature. * Unexpected conditions can include RF lockups, loss of lock, failure to acquire an expected contact and unexpected reports of acquisition, unusual AGC and ACS control excursions, unforeseen actuator enabling's or actions, thermal stresses, power aberrations, failure to authenticate, software or counter resets, etc. Mitigation might include additional TMONs, more detailed AGC and PLL thresholds to alert operators, auto-capturing state snapshot images in memory when unexpected conditions occur, signal spectra measurements, and expanded default diagnostic telemetry modes to help in identifying and resolving anomalous conditions.
SPR-57	The [spacecraft] shall monitor and collect all onboard cyber- data (from multiple system components), including identification of potential attacks and information about the attack for subsequent analysis.{SV-DCO-1}{AC-6(9),AC-20,AC-20(1),AU-2,AU-12,IR-4,IR-4(1),RA-10,SI-3,SI-3(10),SI-4,SI-4(1),SI-4(2),SI-4(7),SI-4(24)}	The spacecraft will monitor and collect data that provides accountability of activity occurring onboard the spacecraft. Due to resource limitations on the spacecraft, analysis must be performed to determine which data is critical for retention and which can be filtered. Full system coverage of data and actions is desired as an objective; it will likely be impractical due to the resource limitations. “Cyber-relevant data” refers to all data and actions deemed necessary to support accountability and awareness of onboard cyber activities for the mission. This would include data that may indicate abnormal activities, critical configuration parameters, transmissions on onboard networks, command logging, or other such data items. This set of data items should be identified early in the system requirements and design phase. Cyber-relevant data should support the ability to assess whether abnormal events are unintended anomalies or actual cyber threats. Actual cyber threats may rarely or never occur, but non-threat anomalies occur regularly. The ability to filter out cyber threats for non-cyber threats in relevant time would provide a needed capability. Examples could include successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels).
SPR-58	The [spacecraft] shall generate cyber related audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, and the outcome of the event. For privileged or hazardous commands, the audit record shall include the approver identifiers and the command identifier.{SV-DCO-1}{AU-3,AU-3(1),AU-12,IR-4,IR-4(1),RA-10,SI-3,SI-3(10),SI-4(7),SI-4(24)}	Detailed audit records are essential for attribution, anomaly detection, and post-incident forensic reconstruction. Capturing what occurred, when, where, and by whom enables rapid differentiation between system fault and adversarial activity. Including approver identifiers for privileged or hazardous commands strengthens accountability and insider threat mitigation. Without complete audit context, recovery and containment decisions may be delayed or misinformed.
SPR-59	The [spacecraft] shall attribute cyber attacks and identify unauthorized use of the platform by downlinking onboard cyber information to the mission ground station within [Program‑defined time ≤ 3 minutes].{SV-DCO-1,SV-IT-1,SV-IT-2}{AU-4(1),IR-4,IR-4(1),IR-4(12),IR-4(13),RA-10,SA-8(22),SI-3,SI-3(10),SI-4,SI-4(5),SI-4(7),SI-4(12),SI-4(24)}	Rapid transmission of cyber-relevant telemetry supports near-real-time ground-based fusion and correlation with enterprise security events. Delayed reporting increases risk of adversary persistence or mission degradation. Early attribution enables containment actions before cascading effects occur. Defined timeliness ensures detection capability aligns with operational tempo.
SPR-60	The [spacecraft] shall integrate cyber related detection and responses with existing fault management capabilities to ensure tight integration between traditional fault management and cyber intrusion detection and prevention.{SV-DCO-1}{AU-6(4),IR-4,IR-4(1),RA-10,SA-8(21),SA-8(26),SC-3(4),SI-3,SI-3(10),SI-4(7),SI-4(13),SI-4(16),SI-4(24),SI-4(25),SI-7(7),SI-13}	The onboard IPS system should be integrated into the existing onboard spacecraft fault management system (FMS) because the FMS has its own fault detection and response system built in. SV corrective behavior is usually limited to automated fault responses and ground commanded recovery actions. Intrusion prevention and response methods will inform resilient cybersecurity design. These methods enable detected threat activity to trigger defensive responses and resilient SV recovery.
SPR-61	The [spacecraft] shall protect information obtained from logging/intrusion-monitoring from unauthorized access, modification, and deletion.{SV-DCO-1}{AU-9,AU-9(3),RA-10,SI-4(7),SI-4(24)}	Monitoring data is a high-value target for attackers seeking to evade detection or erase traces of compromise. Protecting log integrity preserves evidentiary value and detection continuity. Unauthorized modification or deletion could mask malicious behavior or delay response. Cryptographic protection and access controls ensure monitoring mechanisms cannot be silently disabled.
SPR-62	The [spacecraft] shall enter a cyber-safe mode when conditions that threaten the platform are detected, enters a cyber-safe mode of operation with restrictions as defined based on the cyber-safe mode.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4,IR-4(1),IR-4(3),PE-10,RA-10,SA-8(16),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-13,SI-17}	Cyber-safe mode provides a deterministic fallback posture when compromise or anomalous conditions threaten mission integrity. Restricting non-essential functions reduces attack surface and prevents further propagation of malicious activity. Defined restrictions ensure predictable behavior under cyber stress conditions. This supports survivability and controlled recovery rather than uncontrolled degradation.
SPR-63	The [spacecraft] shall be able to locate the onboard origin of a cyber attack and alert ground operators within [Program‑defined time ≤ 3 minutes].{SV-DCO-1}{IR-4,IR-4(1),IR-4(12),IR-4(13),RA-10,SA-8(22),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(16),SI-4(24)}	The origin of any attack onboard the vehicle should be identifiable to support mitigation. At the very least, attacks from critical element (safety-critical or higher-attack surface) components should be locatable quickly so that timely action can occur.
SPR-64	The [spacecraft] shall detect and deny unauthorized outgoing communications posing a threat to the spacecraft.{SV-DCO-1}{IR-4,IR-4(1),RA-5(4),RA-10,SC-7(9),SC-7(10),SI-4,SI-4(1),SI-4(4),SI-4(7),SI-4(11),SI-4(13),SI-4(24),SI-4(25)}	Outbound communications may indicate data exfiltration, covert channels, or compromised subsystem behavior. Monitoring and blocking unauthorized egress prevents leakage of mission data or cryptographic material. Many attacks rely on command-and-control or data extraction channels; egress control disrupts this persistence mechanism. Outbound traffic should be as tightly controlled as inbound command paths.
SPR-65	The [spacecraft] shall select and execute safe countermeasures against cyber attacks prior to entering cyber-safe mode.{SV-DCO-1}{IR-4,RA-10,SA-8(21),SA-8(24),SI-4(7),SI-17}	These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker exquisitely—with or without ground aiding. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system." These countermeasures are likely executed prior to entering into a cyber-safe mode.
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-69	The [spacecraft] shall alert in the event of the audit/logging processing failures.{SV-DCO-1}{AU-5,AU-5(1),AU-5(2),SI-3,SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(24)}	Failure of logging mechanisms may signal active tampering or resource exhaustion attacks. Immediate alerting ensures loss of visibility does not go unnoticed. Silent failure of audit systems creates blind spots exploitable by adversaries. Monitoring the monitors is critical to resilient detection.
SPR-70	The [spacecraft] shall provide an alert immediately to [at a minimum the mission director, administrators, and security officers] when the following failure events occur: [minimally but not limited to: auditing software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity reaching 95%, 99%, and 100%] of allocated capacity, including security component failover events; alerts shall include component identity, time, and fault reason.{SV-DCO-1}{AU-5,AU-5(1),AU-5(2),SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(24),SI-7(7)}	Intent is to have human on the ground be alerted to failures. This can be decomposed to SV to generate telemetry and to Ground to alert.
SPR-71	The [spacecraft] shall provide the capability of a cyber “black-box” to capture necessary data for cyber forensics of threat signatures and anomaly resolution when cyber attacks are detected. The [spacecraft] shall automatically route audit events to the alternate audit logging capability upon primary audit failure and shall resynchronize the alternate store to the primary upon recovery.{SV-DCO-1}{AU-5(5),AU-9(2),AU-9(3),AU-12,IR-4(12),IR-4(13),IR-5(1),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(7),SI-4(24),SI-7(7)}	Similar concept of a "black box" on an aircraft where all critical information is stored for post forensic analysis. Black box can be used to record CPU utilization, GNC physical parameters, audit records, memory contents, TT&C data points, etc. The timeframe is dependent upon implementation but needs to meet the intent of the requirement. For example, 30 days may suffice.
SPR-72	The [spacecraft] shall automatically notify ground operators when onboard integrity verification detects discrepancies.{SV-IT-2}{CM-3(5),SA-8(21),SI-3,SI-4(7),SI-4(12),SI-4(24),SI-7(2),SI-7(12)}	Integrity check failures may indicate unauthorized modification, corruption, or hardware faults induced by malicious activity. Automatic notification ensures ground teams can rapidly assess risk and initiate recovery procedures. Delay in reporting increases mission impact. Transparency between onboard detection and ground response is essential for coordinated defense.
SPR-73	The [spacecraft], upon detection of a potential integrity violation, shall provide the capability to [audit the event and alert ground operators].{SV-DCO-1}{CM-3(5),SA-8(21),SI-3,SI-4(7),SI-4(12),SI-4(24),SI-7(8)}	One example would be for bad commands where the system would reject the command and not increment the Vehicle Command Counter (VCC) and include the information in telemetry.
SPR-74	The [organization] shall define the security safeguards that are to be automatically employed when integrity violations are discovered.{SV-IT-2}{CP-2,SA-8(21),SI-3,SI-4(7),SI-4(12),SI-7(5),SI-7(8)}	Predefined safeguards ensure consistent and timely response to detected integrity violations. Ad hoc response increases uncertainty and recovery time. Automated actions may include isolation, reconstitution from gold images, or transition to cyber-safe mode. Defined response paths improve resilience and reduce operator burden during crisis.
SPR-87	The [spacecraft] shall be configured to provide only essential capabilities.{SV-SP-7,SV-SP-1}{CM-6,CM-7,SA-8(2),SA-8(7),SA-8(13),SA-8(23),SA-8(26),SA-15(5)}	Minimizing enabled functionality reduces attack surface and complexity. Unused services create unnecessary exposure. Essential-only configuration aligns with least functionality principles. This simplifies validation and reduces exploit vectors.
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-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-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-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-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-302	The [organization] shall document the platform's security architecture, and how it is established within and is an integrated part of the overall [organization] mission security architecture.{SV-MA-6,SV-MA-4}{PL-7,SA-8(7),SA-8(13),SA-8(29),SA-8(30),SA-17}	Architecture documentation provides structural clarity. Integration into enterprise mission security ensures alignment. Clear documentation reduces misinterpretation. Transparency strengthens lifecycle governance.
SPR-386	The [organization] shall implement automated mechanisms to assist in the execution and implementation of the Continuous Monitoring Program (CMP).{SV-DCO-1}{CA-7(6)}	Automation ensures continuous monitoring activities are consistent, repeatable, and not dependent on manual effort. Space systems generate large volumes of telemetry that require automated analysis to detect trends and anomalies. Automation reduces human error and accelerates response timelines. This strengthens adaptive security posture over the mission lifecycle.
SPR-479	The [organization] shall define, baseline, and maintain the purposing of the space platform and link segment, including intended objectives, authorized capabilities, prohibited functions, and operational constraints, and shall use this baseline to bound requirements, updates, and on-orbit operations.{SV-AC-8,SV-MA-6}{PM-32,PL-8}	Defining authorized and prohibited functions prevents scope creep. Clear purposing bounds updates and operational use. Governance limits misuse potential. Structured baseline supports disciplined operations.
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-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-519	The [spacecraft] shall cryptographically bind audit records to their origin using per‑record MACs/signatures or sequence‑linked hashes and include station/operator ID and selected RF/link indicators (e.g., SNR/BER, frame counters) when available; ground shall verify and log the results.{SV-IT-2,SV-AC-2,SV-DCO-1}{AU-3,AU-3(1),AU-9,AU-9(2),AU-10}	Per-record signatures prevent tampering or replay. Sequence linkage detects gaps. Including RF indicators enhances forensic value. Verified logging strengthens evidentiary integrity.
SPR-527	The [organization] shall ingest vendor advisories, SBOM deltas, and provenance changes for components/toolchains into the Continuous Monitoring Program and correlate exposure with the “as‑flown” configuration to prioritize mitigations.{SV-SP-6,SV-SP-4,SV-DCO-1}{CA-7,CA-7(6),CM-8}	Exposure must be evaluated against actual deployed versions. SBOM deltas enable precise mitigation prioritization. Continuous ingestion strengthens responsiveness. Configuration awareness improves risk management.
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.

Monitor Critical Telemetry Points

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