A one-time password is valid for only one user authentication.
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
| CM0004 | Development Environment Security | A secure development environment requires a current and sufficiently complete inventory of the people, devices, software, services, credentials, and automated identities capable of accessing or influencing the environment. The development environment includes source-code repositories, developer workstations, build servers, CI/CD runners, compiler and linker toolchains, container and virtual machine images, package registries, artifact repositories, signing systems, test environments, integration laboratories, and release-staging systems. For space systems, these environments may produce or manage flight software images, firmware, FPGA bitstreams, software-defined radio waveforms, command and telemetry databases, configuration tables, ephemerides, calibration products, fault-management logic, and on-orbit update packages. Unmanaged assets, unauthorized access, compromised dependencies, altered toolchains, and untrusted build services are significant pathways through which adversaries may maliciously modify software or other mission artifacts during development and build activities. All personnel and assets touching the development environment must be inventoried and actively managed. MFA shall be enforced for human access, while non-human identities shall use managed workload identities, scoped credentials, protected secrets, and defined rotation or expiration period, with particular rigor applied to code repositories, where threat actors may attempt to inject malicious code into software under development without detection. Zero-trust access controls should govern repository access, with protected branch and tag policies shall restrict direct modification, prohibit unauthorized force pushes or deletion, require successful security checks, and require independent review before merging or releasing critical code. Effective development environment security also requires integrated change management, privilege management, comprehensive audit logging, and continuous in-depth monitoring across all components of the environment. | AC-17 AC-18 AC-20(5) AC-3(11) AC-3(13) AC-3(15) CA-8 CA-8(1) CM-11 CM-14 CM-2(2) CM-3(2) CM-3(7) CM-3(8) CM-4(1) CM-5(6) CM-7(8) CP-2(8) MA-7 PL-8 PL-8(1) PL-8(2) PM-30 PM-30(1) RA-3(1) RA-3(2) RA-5 RA-5(2) RA-9 SA-10 SA-10(4) SA-11 SA-11(1) SA-11(2) SA-11(4) SA-11(5) SA-11(6) SA-11(7) SA-11(8) SA-15 SA-15(3) SA-15(5) SA-15(7) SA-15(8) SA-17 SA-3 SA-3(1) SA-3(2) SA-4(12) SA-4(3) SA-4(5) SA-4(9) SA-8 SA-8(19) SA-8(30) SA-8(31) SA-9 SC-38 SI-2 SI-2(6) SI-7 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-3(2) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5(2) SR-6 SR-6(1) SR-7 | D3-AI D3-AVE D3-SWI D3-HCI D3-NNI D3-OAM D3-AM D3-OM D3-DI D3-MFA D3-CH D3-OTP D3-BAN D3-PA D3- FAPA D3- DQSA D3-IBCA D3-PCSV D3-PSMD | A.8.4 A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.8.9 A.8.9 A.8.31 A.8.19 A.5.30 A.5.8 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.8.8 A.5.22 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 A.8.28 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.9 A.8.28 A.8.30 A.8.32 A.8.29 A.8.30 A.8.28 A.5.8 A.8.25 A.8.28 A.8.25 A.8.27 A.6.8 A.8.8 A.8.32 5.2 5.3 7.5.1 7.5.2 7.5.3 A.5.1 A.5.2 A.5.4 A.5.19 A.5.31 A.5.36 A.5.37 A.5.19 A.5.20 A.5.21 A.8.30 A.5.20 A.5.21 A.5.21 A.8.30 A.5.20 A.5.21 A.5.23 A.8.29 A.5.22 A.5.22 | |
| CM0055 | Secure Command Mode(s) | Secure command modes provide additional layers of restriction on spacecraft command acceptance beyond standard authentication and encryption, constraining when, where, and under what operational conditions the spacecraft will process commands. These supplemental controls reduce the window of opportunity for unauthorized commanding by limiting command receptivity to defined parameters that an adversary would need to satisfy simultaneously with authentication requirements, substantially increasing the difficulty of a successful command injection attack. Specific implementations include geographic restriction, in which the spacecraft accepts commands only when in contact with designated ground station locations; operational mode restrictions, in which special flight software (FSW) modes must be active before certain command categories are accepted; and temporal controls, in which the spacecraft enforces time-bounded windows during which commands are valid. These mechanisms complement command authentication, integrity protection, anti-replay controls, and authorization and do not replace them. Encryption should also be applied where command confidentiality is required. Secure command modes may combine geographic, temporal, operational-state, source, or other mission-defined conditions according to the active command policy. Secure command modes helps create a multi-dimensional command acceptance policy that an adversary must defeat in its entirety to achieve unauthorized command execution. | AC-17(1) AC-17(10) AC-2(11) AC-2(12) AC-3 AC-3(2) AC-3(3) AC-3(4) AC-3(8) CA-3(7) IA-10 PL-8 PL-8(1) SA-3 SA-8 SC-7 SI-3(8) | D3-AH D3-ACH D3-MFA D3-OTP | A.8.16 A.5.15 A.5.33 A.8.3 A.8.4 A.8.18 A.8.20 A.8.2 A.8.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 | |
| ID | Name | Description | |
|---|---|---|---|
| REC-0006 | Gather FSW Development Information | Adversaries collect a cradle-to-operations view of how flight software is built, tested, signed, and released. Useful artifacts include architecture docs, source trees and SBOMs, compiler/linker toolchains and flags, RTOS and middleware versions, build scripts, CI/CD pipelines, code-signing workflows, defect trackers, and release notes that describe “as-built” vs. “as-flown” deltas. They also seek integration environments, emulators/SIL, flatsats/iron birds, hardware-in-the-loop rigs, and the autonomy/FDIR logic that governs mode transitions and patch acceptance. With this knowledge, a threat actor can identify weak crypto or provenance controls on update paths, predict error-handling behavior, and craft inputs that slip past unit/integration tests. Even small disclosures (e.g., a linker script, an assert string, or a sanitized crash dump) shrink the search space for exploitation. | |
| REC-0006.01 | Development Environment | Threat actors enumerate the exact environment used to produce flight builds: IDEs and plugins, cross-compilers and SDKs, container images/VMs, environment variables, path conventions, build systems, static libraries, and private package registries. They correlate repository layouts (mono- vs multi-repo), branch and review policies, protected branches/tags, and CI orchestrators to find where policy gaps allow unreviewed code or tool updates. Secrets embedded in configs (tokens, service accounts), permissive compiler/linker flags, or disabled hardening options are especially valuable. Knowledge of debug/diagnostic builds, symbol servers, and crash-dump handling lets an adversary reconstruct higher-fidelity testbeds or derive function boundaries in stripped images. | |
| IA-0001 | Compromise Supply Chain | Adversaries achieve first execution before the spacecraft ever flies by inserting malicious code, data, or configuration during manufacturing, integration, or delivery. Targets include software sources and dependencies, build systems and compilers, firmware/bitstreams for MCUs and FPGAs, configuration tables, test vectors, and off-the-shelf avionics. Inserted artifacts are designed to appear legitimate, propagate through normal processes, and activate under routine procedures or specific modes (e.g., safing, maintenance). Common insertion points align with where trust is assumed, vendor updates, mirrors and registries, CI/CD runners, programming stations, and “golden image” repositories. The result is pre-positioned access that blends with baseline behavior, often with delayed or conditional triggers and strong deniability. | |
| IA-0001.02 | Software Supply Chain | Here the manipulation targets software delivered to flight or ground systems: altering source before build, swapping signed binaries at distribution edges, subverting update metadata, or using stolen signing keys to issue malicious patches. Space-specific vectors include mission control applications, schedulers, gateway services, flight tables and configuration packages, and firmware loads during I&T or LEOP. Adversaries craft payloads that pass superficial validation, trigger under particular operating modes, or reintroduce known weaknesses through version rollback. “Data payloads” such as malformed tables, ephemerides, or calibration products can double as exploits when parsers are permissive. The objective is to ride the normal promotion pipeline so the implant arrives pre-trusted and executes as part of routine operations. | |
| IA-0002 | Compromise Software Defined Radio | Adversaries target SDR-based transceivers and payload radios because reconfigurable waveforms, FPGA bitstreams, and software flowgraphs create programmable footholds. Manipulation can occur in the radio’s development pipeline (toolchains, out-of-tree modules), at integration (loading of bitstreams, DSP coefficients, calibration tables), or in service via update channels that deliver new waveforms or patches. On-orbit SDRs often expose control planes (command sets for mode/load/select), data planes (baseband I/Q), and management/telemetry paths, any of which can embed covert behavior, alternate demod paths, or hidden subcarriers. A compromised SDR can establish clandestine command-and-control by activating non-public waveforms, piggybacking on idle fields, or toggling to time/ephemeris-triggered profiles that blend with nominal operations. On the ground, compromised SDR modems can be used to fabricate mission-compatible emissions or to decode protected downlinks for reconnaissance. Attackers leverage the SDR’s malleability so that malicious signaling, once seeded, presents as a legitimate but rarely exercised configuration. | |
| 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. | |
| IA-0004.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-0006 | Compromise Hosted Payload | Adversaries target hosted payloads as an alternate doorway into the host spacecraft. Hosted payloads often expose their own command sets, file services, and telemetry paths, sometimes via the host’s TT&C chain, sometimes through a parallel ground infrastructure under different operational control. Initial access arises when an attacker obtains the ability to issue payload commands, upload files, or alter memory/register state on the hosted unit. Because data and control must traverse an interface to the host bus (power, time, housekeeping, data routing, gateway processors), the payload–host boundary can also carry management functions: mode transitions, table loads, firmware updates, and cross-strapped links that appear only in maintenance or contingency modes. With knowledge of the interface specification and command dictionaries, a threat actor can activate rarely used modes, inject crafted data products, or trigger gateway behaviors that extend influence beyond the payload itself. In multi-tenant or commercial hosting arrangements, differences in keying, procedures, or scheduling between the payload operator and the bus operator provide additional opportunity for a first foothold that looks like routine payload commanding. | |
| IA-0007 | Compromise Ground System | Compromising the ground segment gives an adversary the most direct path to first execution against a spacecraft. Ground systems encompass operator workstations and mission control mission control software, scheduling/orchestration services, front-end processors and modems, antenna control, key-loading tools and HSMs, data gateways (SLE/CSP), identity providers, and cloud-hosted mission services. Once inside, a threat actor can prepare on-orbit updates, craft and queue valid telecommands, replay captured traffic within acceptance windows, or manipulate authentication material and counters to pass checks. The same foothold enables deep reconnaissance: enumerating mission networks and enclaves, discovering which satellites are operated from a site, mapping logical topology between MOC and stations, identifying in-band “birds” reachable from a given aperture, and learning pass plans, dictionaries, and automation hooks. From there, initial access to the spacecraft is a matter of timing and presentation, injecting commands, procedures, or update packages that align with expected operations so the first execution event appears indistinguishable from normal activity. | |
| IA-0007.01 | Compromise On-Orbit Update | Adversaries may target the pipeline that produces and transmits updates to an on-orbit vehicle. Manipulation points include source repositories and configuration tables, build and packaging steps that generate images or differential patches, staging areas on ground servers, update metadata (versions, counters, manifests), and the transmission process itself. Spacecraft updates span flight software patches, FPGA bitstreams, bootloader or device firmware loads, and operational data products such as command tables, ephemerides, and calibration files, each with distinct formats, framing, and acceptance rules. An attacker positioned in the ground system can substitute or modify an artifact, alter its timing and timetags to match pass windows, and queue it through the same procedures operators use for nominal maintenance. Activation can be immediate or deferred: implants may lie dormant until a specific mode, safing entry, or table index is referenced. | |
| IA-0007.02 | Malicious Commanding via Valid GS | Adversaries may use a compromised, mission-owned ground system to transmit legitimate-looking commands to the target spacecraft. Because the ground equipment is already configured for the mission, correct waveforms, framing, dictionaries, and scheduling, the attacker’s traffic blends with routine operations. Initial access unfolds by inserting commands or procedures into existing timelines, modifying rate/size limits or command queues, or invoking maintenance dictionaries and rapid-response workflows that accept broader command sets. Pre-positioned scripts can chain actions across multiple passes and stations, while telemetry routing provides immediate feedback to refine follow-on steps. Exfiltration can be embedded in standard downlink channels or forwarded through gateways as ordinary mission data. The distinguishing feature is that command origin appears valid, transmitted from approved apertures using expected parameters, so the first execution event is not a protocol anomaly but a misuse of legitimate command authority obtained through the compromised ground system. | |
| IA-0008 | Rogue External Entity | Adversaries obtain a foothold by interacting with the spacecraft from platforms outside the authorized ground architecture. A “rogue external entity” is any actor-controlled transmitter, platform, or node, ground, maritime, airborne, or space-based. Most interact by radiating or exchanging traffic using mission-compatible waveforms, framing, or crosslink protocols. Others carry no mission-compatible capability at all, and instead apply interference, directed energy, or physical proximity to shape the conditions under which access becomes possible. The technique exploits the fact that many vehicles must remain commandable and discoverable over wide areas and across multiple modalities. Using public ephemerides, pass predictions, and knowledge of acquisition procedures, the actor times transmissions to line-of-sight windows, handovers, or maintenance periods. Initial access stems from presenting traffic that the spacecraft will parse or prioritize, such as syntactically valid telecommands, crafted ranging/acquisition exchanges, crosslink service advertisements, or payload/user-channel messages that bridge into the command/data path, or, for entities operating by effect rather than by protocol, from the contingency behavior those effects induce. | |
| IA-0008.01 | Rogue Ground Station | Adversaries may field their own ground system, transportable or fixed, to transmit and receive mission-compatible signals. A typical setup couples steerable apertures and GPS-disciplined timing with SDR/modems configured for the target’s bands, modulation/coding, framing, and beacon structure. Using pass schedules and Doppler/polarization predictions, the actor crafts over-the-air traffic that appears valid at the RF and protocol layers. | |
| IA-0008.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. | |
| IA-0009.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. | |
| IA-0012 | Assembly, Test, and Launch Operation Compromise | Assembly, Test, and Launch Operation (ATLO) concentrates people, tools, and authority while components first exchange real traffic across flight interfaces. Test controllers, EGSE, simulators, flatsats, loaders, and data recorders connect to the same buses and command paths that will exist on orbit. Threat actors exploit this density and dynamism: compromised laptops or transient cyber assets push images and tables; lab networks bridge otherwise separate enclaves; vendor support accounts move software between staging and flight hardware; and “golden” artifacts created or modified in ATLO propagate into the as-flown baseline. Malware can traverse shared storage and scripting environments, ride update/checklist execution, or piggyback on protocol translators and gateways used to stimulate subsystems. Because ATLO often introduces late firmware loads, key/counter initialization, configuration freezes, and full-system rehearsals, a single well-placed change can yield first execution on multiple devices and persist into LEOP. | |
| IA-0013 | Compromise Host Spacecraft | The inverse of "IA-0006: Compromise Hosted Payload", this technique describes adversaries that are targeting a hosted payload, the host space vehicle (SV) can serve as an initial access vector to compromise the payload through vulnerabilities in the SV's onboard systems, communication interfaces, or software. If the SV's command and control systems are exploited, an attacker could gain unauthorized access to the vehicle's internal network. Once inside, the attacker may laterally move to the hosted payload, particularly if it shares data buses, processors, or communication links with the vehicle. | |
| EX-0001 | Replay | Replay is the re-transmission of previously captured traffic, over RF links, crosslinks, or internal buses, to elicit the same processing and effects a second time. Adversaries first observe and record authentic exchanges (telecommands, ranging/acquisition frames, housekeeping telemetry acknowledgments, bus messages), then resend them within acceptance conditions that the system recognizes, matching link geometry, timetags, counters, or mode states. The aim can be functional (re-triggering an action such as a mode change), observational (fingerprinting how the vehicle reacts at different states), or disruptive (saturating queues and bandwidth to crowd out legitimate traffic). Because replays preserve valid syntax and often valid context, they can blend with normal operations, especially during periods with reduced monitoring or when counters and windows reset (e.g., handovers, safing entries). On encrypted links, metadata replays (acquisition beacons, schedule requests) may still yield informative responses. | |
| EX-0001.01 | Command Packets | Threat actors may resend authentic-looking telecommands that were previously accepted by the spacecraft. Captures may include whole command PDUs with framing, CRC/MAC, counters, and timetags intact, or they may be reconstructed from operator tooling and procedure logs. When timing, counters, and mode preconditions align, the replayed packet can cause the same effect: toggling relays, initiating safing or recovery scripts, adjusting tables, commanding momentum dumps, or scheduling delta-v events. Even when outright execution fails, repeated “near-miss” injections can map acceptance windows, rate/size limits, and interlocks by observing the spacecraft’s acknowledgments and state changes. At scale, streams of valid-but-stale commands can congest command queues, delay legitimate activity, or trigger nuisance FDIR responses. | |
| PER-0002 | Backdoor | A backdoor is a covert access path that bypasses normal authentication, authorization, or operational checks so the attacker can reenter the system on demand. Backdoors may be preexisting (undocumented service modes, maintenance accounts, debug features) or introduced by the adversary during development, integration, or on-orbit updates. Triggers range from “magic” opcodes and timetags to specific geometry/time conditions, counters, or data patterns embedded in routine traffic. The access they provide varies from expanded command sets and relaxed rate/size limits to alternate communications profiles and hidden file/parameter interfaces. Well-crafted backdoors blend with nominal behavior, appearing as ordinary operations while quietly accepting instructions that other paths would reject, thereby sustaining the attacker’s foothold across passes, resets, and operator handovers. | |
| PER-0002.02 | Software Backdoor | Software backdoors are code paths intentionally crafted or later inserted to provide privileged functionality on cue. In flight contexts, they appear as hidden command handlers, alternate authentication checks, special user/role constructs, or procedure/script hooks that accept nonpublic inputs. They can be embedded in flight applications, separation kernels or drivers, gateway processors that translate bus/payload traffic, or update/loader utilities that handle tables and images. SDR configurations offer another avenue: non-public waveforms, subcarriers, or framing profiles that, when selected, expose a private command channel. Activation is often conditional, specific timetags, geometry, message sequences, or file names, to keep the feature dormant during routine testing and operations. Once present, the backdoor provides a repeatable way to execute commands or modify state without traversing the standard control surfaces, sustaining the adversary’s access over time. | |
| 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-0012 | Component Collusion | This technique involves two or more compromised components operating in coordination to conceal malicious activity. Threat actors compromise multiple software modules during the supply chain process and design them to behave cooperatively. Each component independently performs only a limited, seemingly benign function, such that when analyzed in isolation, no single module appears malicious. An example of implementation involves one component acting as a trigger agent, waiting for specific mission or system conditions (e.g., GPS fix, telemetry state) and writing a signal to a shared resource (e.g., file, bus). A separate action agent monitors this resource and only executes the malicious behavior (such as data exfiltration or command injection) upon receiving the trigger. This division of responsibilities significantly undermines traditional detection techniques, such as log analysis, static code review, or heuristic-based behavior monitoring. | |
| LM-0001 | Hosted Payload | The adversary pivots through the host–payload boundary to reach additional subsystems. Hosted payloads exchange power, time, housekeeping, and data with the bus via defined gateways (e.g., SpaceWire, 1553, Ethernet) and often support file services, table loads, and command dictionaries distinct from the host’s. A foothold on the payload can be used to inject traffic through the gateway processor, request privileged services (time/ephemeris distribution, firmware loads), or ride shared backplanes where payload traffic is bridged into C&DH networks. In some designs, payload processes execute on host compute or expose maintenance modes that temporarily widen access, creating paths from the payload into attitude, power, storage, or recorder resources. The movement is transitive: compromise a co-resident unit, then traverse the trusted interface that already exists for mission operations. | |
| 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. | |
| EXF-0006 | Modify Communications Configuration | The adversary alters radio/optical link configuration so the spacecraft emits mission data over paths the program does not monitor or control. Levers include retuning carriers, adding sidebands or subcarriers, changing modulation/coding profiles, remapping virtual channels/APIDs, editing beacon content, or redirecting routing tables in regenerative payloads. Data can be embedded steganographically (idle fields, padding, frame counters, pilot tones) or carried on a covert auxiliary downlink/crosslink pointed at attacker-owned apertures. Because these emissions conform to plausible waveforms and scheduler behavior, they appear as ordinary link activity while quietly conveying payload products, housekeeping, or file fragments to non-mission receivers. | |
| EXF-0006.01 | Software Defined Radio | Programmable SDRs let an attacker introduce new waveforms or piggyback payloads into existing ones. By modifying DSP chains (filters, mixers, FEC, framing), the actor can: add a low-rate subcarrier under the main modulation, alter preamble/pilot sequences to encode bits, vary puncturing/interleaver patterns as a covert channel, or schedule brief “maintenance” bursts that actually carry exfiltrated data. Changes may be packaged as legitimate updates or configuration profiles so the SDR transmits toward attacker-visible geometry using standard equipment, while mission tooling interprets the emission as routine. | |
| EXF-0006.02 | Transponder | On bent-pipe or regenerative transponders, configuration controls what is translated, amplified, and routed. An adversary can remap input–output paths, shift translation frequencies, adjust polarization or gain to favor non-mission receivers, or enable auxiliary ports so selected virtual channels or recorder playbacks are forwarded outside the planned ground segment. In regenerative systems, edited routing tables or QoS rules can mirror traffic to an attacker-controlled endpoint. The result is a sanctioned-looking carrier that quietly delivers mission data to unauthorized listeners. | |
| EXF-0008 | Compromised Developer Site | By breaching development or integration environments (at the mission owner, contractor, or partner), the adversary gains access to source code, test vectors, telemetry captures, build artifacts, documentation, and configuration data, material that is often more complete than flight archives. Beyond theft of intellectual property, the attacker can embed telemetry taps, extended logging, or data “export” features into test harnesses, simulators, or flight builds so that, once fielded, the system produces extra observables or forwards content to non-mission endpoints. This activity typically occurs pre-launch during software production and ATLO, positioning exfiltration mechanisms to activate later in flight. | |
| ID | Description | |
| SV-AC-3 |
Compromised master keys or any encryption key |
|
| SV-CF-2 |
Eavesdropping (RF and proximity) |
|
| SV-IT-2 |
Unauthorized modification or corruption of data |
|
| SV-MA-2 |
Heaters and flow valves of the propulsion subsystem are controlled by electric signals so cyberattacks against these signals could cause propellant lines to freeze, lock valves, waste propellant or even put in de-orbit or unstable spinning |
|
| SV-AV-4 |
Attacking the scheduling table to affect tasking |
|
| SV-IT-5 |
Onboard control procedures (i.e., ATS/RTS) that execute a scripts/sets of commands |
|
| SV-MA-3 |
Attacks on critical software subsystems Attitude Determination and Control (AD&C) subsystem determines and controls the orientation of the satellite. Any cyberattack that could disrupt some portion of the control loop - sensor data, computation of control commands, and receipt of the commands would impact operations Telemetry, Tracking and Commanding (TT&C) subsystem provides interface between satellite and ground system. Computations occur within the RF portion of the TT&C subsystem, presenting cyberattack vector Command and Data Handling (C&DH) subsystem is the brains of the satellite. It interfaces with other subsystems, the payload, and the ground. It receives, validate, decodes, and sends commands to other subsystems, and it receives, processes, formats, and routes data for both the ground and onboard computer. C&DH has the most cyber content and is likely the biggest target for cyberattack. Electrical Power Subsystem (EPS) provides, stores, distributes, and controls power on the satellite. An attack on EPS could disrupt, damage, or destroy the satellite. |
|
| SV-SP-1 |
Exploitation of software vulnerabilities (bugs); Unsecure code, logic errors, etc. in the FSW. |
|
| SV-SP-3 |
Introduction of malicious software such as a virus, worm, Distributed Denial-Of-Service (DDOS) agent, keylogger, rootkit, or Trojan Horse |
|
| SV-SP-6 |
Software reuse, COTS dependence, and standardization of onboard systems using building block approach with addition of open-source technology leads to supply chain threat |
|
| SV-SP-9 |
On-orbit software updates/upgrades/patches/direct memory writes. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code |
|
| SV-AC-5 |
Proximity operations (i.e., grappling satellite) |
|
| SV-AC-6 |
Three main parts of S/C. CPU, memory, I/O interfaces with parallel and/or serial ports. These are connected via busses (i.e., 1553) and need segregated. Supply chain attack on CPU (FPGA/ASICs), supply chain attack to get malware burned into memory through the development process, and rogue RTs on 1553 bus via hosted payloads are all threats. Security or fault management being disabled by non-mission critical or payload; fault injection or MiTM into the 1553 Bus - China has developed fault injector for 1553 - this could be a hosted payload attack if payload has access to main 1553 bus; One piece of FSW affecting another. Things are not containerized from the OS or FSW perspective; |
|
| SV-AC-8 |
Malicious Use of hardware commands - backdoors / critical commands |
|
| SV-AV-2 |
Satellites base many operations on timing especially since many operations are automated. Cyberattack to disrupt timing/timers could affect the vehicle (Time Jamming / Time Spoofing) |
|
| SV-AV-3 |
Affect the watchdog timer onboard the satellite which could force satellite into some sort of recovery mode/protocol |
|
| SV-IT-3 |
Compromise boot memory |
|
| SV-IT-4 |
Cause bit flip on memory via single event upsets |
|
| SV-MA-8 |
Payload (or other component) is told to constantly sense or emit or run whatever mission it had to the point that it drained the battery constantly / operated in a loop at maximum power until the battery is depleted. |
|
| SV-SP-11 |
Software defined radios - SDR is also another computer, networked to other parts of the spacecraft that could be pivoted to by an attacker and infected with malicious code. Once access to an SDR is gained, the attacker could alter what the SDR thinks is correct frequencies and settings to communicate with the ground. |
|
| SV-SP-7 |
Software can be broken down into three levels (operating system and drivers’ layer, data handling service layer, and the application layer). Highest impact on system is likely the embedded code at the BIOS, kernel/firmware level. Attacking the on-board operating systems. Since it manages all the programs and applications on the computer, it has a critical role in the overall security of the system. Since threats may occur deliberately or due to human error, malicious programs or persons, or existing system vulnerability mitigations must be deployed to protect the OS. |
|
| 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-AV-6 |
Complete compromise or corruption of running state |
|
| SV-DCO-1 |
Not knowing that you were attacked, or attack was attempted |
|
| SV-MA-5 |
Not being able to recover from cyberattack |
|
| 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-CF-4 |
Adversary monitors for safe-mode indicators such that they know when satellite is in weakened state and then they launch attack |
|
| SV-IT-1 |
Communications system spoofing resulting in denial of service and loss of availability and data integrity |
|
| SV-AC-7 |
Weak communication protocols. Ones that don't have strong encryption within it |
|
| SV-AV-1 |
Communications system jamming resulting in denial of service and loss of availability and data integrity |
|
| SV-MA-7 |
Exploit ground system and use to maliciously to interact with the spacecraft |
|
| SV-AC-4 |
Masquerading as an authorized entity in order to gain access/Insider Threat |
|
| SV-AV-7 |
The TT&C is the lead contributor to satellite failure over the first 10 years on-orbit, around 20% of the time. The failures due to gyro are around 12% between year one and 6 on-orbit and then ramp up starting around year six and overtake the contributions of the TT&C subsystem to satellite failure. Need to ensure equipment is not counterfeit and the supply chain is sound. |
|
| SV-CF-3 |
Knowledge of target satellite's cyber-related design details would be crucial to inform potential attacker - so threat is leaking of design data which is often stored Unclass or on contractors’ network |
|
| SV-MA-4 |
Not knowing what your crown jewels are and how to protect them now and in the future. |
|
| SV-MA-6 |
Not planning for security on SV or designing in security from the beginning |
|
| SV-SP-10 |
Compromise development environment source code (applicable to development environments not covered by threat SV-SP-1, SV-SP-3, and SV-SP-4). |
|
| SV-SP-2 |
Testing only focuses on functional requirements and rarely considers end to end or abuse cases |
|
| SV-SP-4 |
General supply chain interruption or manipulation |
|
| SV-SP-5 |
Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused} |
|
| SPARTA ID | Requirement | Rationale/Additional Guidance/Notes |
|---|---|---|
| SPR-2 | The [spacecraft] shall ensure that sensitive information can only be accessed by personnel with appropriate roles and an explicit need for such information to perform their duties.{SV-CF-3,SV-AC-4}{AC-3(11),CM-12} | Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations. |
| SPR-3 | The [spacecraft] shall enforce approved authorizations for controlling the flow of information within the platform and between interconnected systems so that information does not leave the platform boundary unless it is encrypted. Flow control shall be implemented in conjunction with protected processing domains, security‑policy filters with fully enumerated formats, and a default‑deny communications baseline.{SV-AC-6}{AC-3(3),AC-3(4),AC-4,AC-4(2),AC-4(6),AC-4(21),CA-3,CA-3(6),CA-3(7),CA-9,IA-9,SA-8(19),SC-8(1),SC-16(3)} | Spacecraft operate in constrained and deterministic environments where uncontrolled data flows can enable data exfiltration, cross-domain leakage, or lateral movement between subsystems. Enforcing approved authorizations with enumerated formats and a default-deny posture ensures only explicitly permitted communications occur. Encryption enforcement at platform boundaries prevents unauthorized disclosure of telemetry or state information. |
| 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-10 | The [spacecraft] shall protect authenticator content from unauthorized disclosure and modification.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),IA-5,IA-5(6),RA-5(4),SA-8(18),SA-8(19),SC-28(3)} | Authenticators (keys, tokens, counters, certificates) are primary targets for persistent access attacks. Disclosure or modification enables command spoofing, replay, and privilege escalation. Protecting authenticator content preserves command integrity and prevents adversaries from maintaining covert control. Integrity protections must apply both at rest and in use. |
| SPR-11 | The [spacecraft] encryption key handling shall be handled outside of the onboard software and protected using cryptography.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(1),SC-28(3)} | Key management separated from modifiable flight software reduces exposure to software compromise. If keys are accessible to onboard applications, malicious code could extract or misuse them. Hardware-anchored or externally managed key handling reduces persistence risk. This supports trust-chain assurance and mitigates firmware-level compromise. |
| SPR-12 | The [spacecraft] encryption keys shall be restricted so that the onboard software is not able to access the information for key readout.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(3)} | Even privileged software must not be able to retrieve plaintext keys. Preventing readout mitigates malware harvesting and insider misuse. Key usage should be mediated through cryptographic modules rather than direct exposure. This enforces least privilege at the cryptographic boundary. |
| SPR-13 | The [spacecraft] encryption keys shall be restricted so that they cannot be read via any telecommands.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(3)} | Telecommand paths are high-value targets for adversarial exploitation. Allowing keys to be retrieved via command interfaces creates a catastrophic failure mode. This constraint prevents exfiltration even under partial compromise of command processing logic. It ensures encryption protections cannot be remotely dismantled. |
| SPR-14 | The [spacecraft] shall authenticate the ground station (and all commands) and other spacecraft before establishing remote connections using bidirectional authentication that is cryptographically based.{SV-AC-1,SV-AC-2}{AC-3,AC-17,AC-17(2),AC-17(10),AC-18(1),AC-20,IA-3(1),IA-4,IA-4(9),IA-7,IA-9,SA-8(18),SA-8(19),SA-9(2),SC-7(11),SC-16(1),SC-16(2),SC-16(3),SC-23(3),SI-3(9)} | Authorization can include embedding opcodes in command strings, using trusted authentication protocols, identifying proper link characteristics such as emitter location, expected range of receive power, expected modulation, data rates, communication protocols, beamwidth, etc.; and tracking command counter increments against expected values. |
| SPR-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-16 | The [spacecraft] shall ensure that processes reusing a shared system resource (e.g., registers, main memory, secondary storage) do not have access to information (including encrypted representations of information) previously stored in that resource after formal release, by clearing or zeroizing the resource prior to reuse.{SV-AC-6}{AC-3,PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(19),SC-4,SI-3} | Residual data in memory or registers can create covert channels or leakage paths between partitions. Zeroization prevents recovery of sensitive data by subsequent processes. This mitigates cross-domain leakage and memory scraping attacks. Clearing encrypted remnants is equally important to prevent cryptanalytic exploitation. |
| SPR-17 | The [spacecraft] shall protect the confidentiality and integrity of all information at rest using cryptography.{SV-CF-1,SV-CF-2,SV-AC-3}{AC-3,SA-8(19),SC-28,SC-28(1),SI-7(6)} | * The intent as written is for all transmitted traffic to be protected. This includes internal to internal communications and especially outside of the boundary. |
| 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-20 | The [spacecraft] shall prevent use of a mode of operations where cryptography on the TT&C link can be disabled; encryption and authentication shall remain enabled even when automated access control mechanisms are overridden.{SV-AC-1,SV-CF-1,SV-CF-2}{AC-3(10),SA-8(18),SA-8(19),SC-16(2),SC-16(3),SC-40,SC-40(4)} | Emergency or override modes often become attack vectors if protections are weakened. Cryptography must remain enforced even during safe-mode or degraded operations. Removing encryption capability creates a single-point catastrophic exposure. Persistent protection ensures no operational shortcut undermines mission assurance. |
| SPR-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-22 | The [spacecraft] shall implement boundary protections to separate bus, communications, and payload components supporting their respective functions.{SV-AC-6}{AC-3(3),AC-3(4),CA-9,SA-8(3),SA-8(14),SA-8(18),SA-8(19),SA-17(7),SC-2,SC-2(2),SC-7(13),SC-7(21),SC-7(29),SC-16(3),SC-32,SI-3,SI-4(13),SI-4(25)} | Flat architectures allow compromise of one subsystem to impact all others. Segregated boundaries reduce lateral movement and mission degradation. Isolation ensures payload compromise does not impact TT&C or bus control. This supports containment and survivability. |
| SPR-23 | The [spacecraft] shall isolate mission critical functionality from non-mission critical functionality.{SV-AC-6}{AC-3(3),AC-3(4),CA-9,SA-8(3),SA-8(19),SA-17(7),SC-2,SC-3,SC-3(4),SC-7(13),SC-7(29),SC-32,SC-32(1),SI-3,SI-7(10),SI-7(12)} | Non-critical functions often expand attack surface. Isolation prevents less-trusted components from affecting propulsion, attitude control, or power systems. This reduces cascading failure risk under compromise. Mission-critical systems must maintain operational continuity. |
| SPR-24 | The [spacecraft] data within partitioned applications shall not be read or modified by other applications/partitions.{SV-AC-6}{AC-3(3),AC-3(4),SA-8(19),SC-2(2),SC-4,SC-6,SC-32} | Application partitions must enforce strict read/write controls to prevent unauthorized state modification. Without this control, malicious code can alter mission parameters or falsify telemetry. Isolation protects integrity of subsystem data and prevents corruption propagation. |
| 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-26 | The [spacecraft] shall use protected processing domains to enforce the policy that information does not leave the platform boundary unless it is encrypted as a basis for flow‑control decisions and shall enumerate permitted inter‑domain flows and enforce domain‑gate checks on any domain switch. {SV-AC-6}{AC-4(2),IA-9,SA-8(19),SC-8(1),SC-16(3)} | Domain gates provide controlled transition points between security domains. Enumerated flows prevent unintentional data leakage and enforce encryption policies at boundaries. This mitigates cross-domain injection and exfiltration. Strong gate enforcement prevents privilege escalation during context switching. |
| 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-28 | The [spacecraft] shall provide the capability to enter the platform into a known good, operational cyber-safe mode from a tamper-resistant, configuration-controlled (“gold”) image that is authenticated as coming from an acceptable supplier, and has its integrity verified. The [spacecraft] shall refresh only from cryptographically authenticated [organization]-approved sources.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4(3),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-13,SI-17} | Cyber-safe mode is an operating mode of a spacecraft during which all nonessential systems are shut down and the spacecraft is placed in a known good state using validated software and configuration settings. Within cyber-safe mode authentication and encryption should still be enabled. The spacecraft should be capable of reconstituting firmware and SW functions to preattack levels to allow for the recovery of functional capabilities. This can be performed by self-healing, or the healing can be aided from the ground. However, the spacecraft needs to have the capability to replan, based on available equipment still available after a cyberattack. The goal is for the vehicle to resume full mission operations. If not possible, a reduced level of mission capability should be achieved. |
| SPR-29 | The [spacecraft] shall enter cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable.{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-17} | |
| SPR-30 | The [spacecraft] shall fail to a known secure state for failures during initialization, and aborts preserving information necessary to return to operations in failure.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(24),SC-24,SI-13,SI-17} | |
| 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-32 | The [spacecraft] shall provide or support the capability for recovery and reconstitution to a known state after a disruption, compromise, or failure.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-4(4),CP-10,CP-10(4),CP-10(6),CP-13,IR-4,IR-4(1),SA-8(16),SA-8(19),SA-8(24)} | |
| 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-35 | The [spacecraft] shall perform an orderly, controlled system shut-down to a known cyber-safe state upon receipt of a termination command or condition.{PE-11,PE-11(1),SA-8(16),SA-8(19),SA-8(24),SI-17} | |
| SPR-36 | The [spacecraft] shall operate securely in off-nominal power conditions, including loss of power and spurious power transients.{SV-AV-6,SV-MA-2}{PE-11,PE-11(1),SA-8(16),SA-8(19),SI-13,SI-17} | Power anomalies may induce undefined states exploitable by attackers. Cryptographic and security mechanisms must not degrade into insecure configurations during brownout or transient conditions. This mitigates fault-induced bypass attacks. Resilient operation preserves trust chain continuity. |
| SPR-37 | The [spacecraft] shall protect system components, associated data communications, and communication buses in accordance with: (i) national emissions and TEMPEST policies and procedures, and (ii) the security category or sensitivity of the transmitted information, and shall demonstrate compliance via pre‑launch TEMPEST‑like evaluation for co‑located payload configurations.{SV-CF-2,SV-MA-2}{PE-14,PE-19,PE-19(1),RA-5(4),SA-8(18),SA-8(19),SC-8(1)} | The measures taken to protect against compromising emanations must be in accordance with DODD S-5200.19, or superseding requirements. The concerns addressed by this control during operation are emanations leakage between multiple payloads within a single space platform, and between payloads and the bus. |
| SPR-38 | The [spacecraft] shall be designed so that it protects itself from information leakage due to electromagnetic signals emanations.{SV-CF-2,SV-MA-2}{PE-19,PE-19(1),RA-5(4),SA-8(19)} | This requirement applies if system components are being designed to address EMSEC and the measures taken to protect against compromising emanations must be in accordance with DODD S-5200.19, or superseding requirements. |
| SPR-39 | The [spacecraft] shall prevent unauthorized and unintended information transfer via shared system resources.{SV-AC-6}{PM-32,SA-8(2),SA-8(5),SA-8(6),SA-8(19),SC-2(2),SC-4} | Shared buses, memory, or peripherals can become covert channels. Controls must prevent unintended information propagation across shared infrastructure. This mitigates cross-partition leakage and data exfiltration. Shared resources must not undermine domain isolation. |
| SPR-40 | The [spacecraft] shall only use communication protocols that support encryption within the mission.{SV-AC-7,SV-CF-1,SV-CF-2}{SA-4(9),SA-8(18),SA-8(19),SC-40(4)} | Protocols lacking encryption create unavoidable exposure. Selecting encryption-capable protocols ensures confidentiality and integrity can be enforced mission-wide. This reduces risk from protocol downgrade attacks. |
| SPR-41 | The [spacecraft] shall maintain a separate execution domain for each executing process.{SV-AC-6}{SA-8(14),SA-8(19),SC-2(2),SC-7(21),SC-39,SI-3} | Process isolation prevents one compromised task from impacting others. Separate execution domains mitigate memory corruption and privilege escalation. This strengthens containment of malicious code. Deterministic isolation enhances both safety and cybersecurity. |
| SPR-42 | The [spacecraft] flight software shall not be able to tamper with the security policy or its enforcement mechanisms.{SV-AC-6}{SA-8(16),SA-8(19),SC-3,SC-7(13)} | Security enforcement must be independent of mission application logic. If FSW can alter policy, adversaries can disable protections post-compromise. This control preserves integrity of access controls and monitoring functions. Separation of enforcement from application reduces systemic risk. |
| SPR-43 | The [spacecraft] shall initialize the platform to a known safe state.{SA-8(19),SA-8(23),SA-8(24),SI-17} | |
| SPR-44 | The [spacecraft] shall maintain the confidentiality and integrity of information during preparation for transmission and during reception in accordance with [organization] provided encryption matrix.{SV-CF-1,SV-CF-2,SV-IT-2}{SA-8(19),SC-8,SC-8(1),SC-8(2),SC-8(3)} | * 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-45 | The [spacecraft] shall implement cryptographic mechanisms that achieve protection against the effects of intentional electromagnetic interference; verification evidence for EMI/EPM shall be distinct from EMSEC/TEMPEST, anti‑jam/anti‑spoof protections, and EMP/HANE hardness.{SV-AV-1,SV-IT-1}{SA-8(19),SC-8(1),SC-40,SC-40(1)} | Intentional electromagnetic interference may attempt to induce predictable faults or bypass protections. Cryptographic resilience ensures corrupted transmissions are rejected. Verification must distinguish EMI/EPM resilience from TEMPEST and anti-jam protections. This ensures integrity under hostile RF environments. |
| 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-54 | The [spacecraft] shall retain the capability to update/upgrade operating systems while on-orbit.{SV-SP-7}{SA-4(5),SA-8(8),SA-8(31),SA-10(2),SI-3} | The operating system updates should be performed using multi-factor authorization and should only be performed when risk of compromise/exploitation of identified vulnerability outweighs the risk of not performing the update. |
| 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-75 | The [organization] shall define acceptable secure communication protocols available for use within the mission in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-AC-7}{SA-4(9)} | The secure communication protocol should include "strong" authenticated encryption characteristics. |
| SPR-76 | The [spacecraft] shall only use [organization]-defined communication protocols within the mission.{SV-AC-7}{SA-4(9)} | Restricting protocols prevents introduction of undocumented or insecure communication paths. Unapproved protocols may lack encryption, replay protection, or monitoring integration. Standardization reduces attack surface and simplifies validation. Controlled protocol selection strengthens supply chain and integration assurance. |
| SPR-77 | The [spacecraft] shall employ the principle of least privilege, allowing only authorized accesses processes which are necessary to accomplish assigned tasks in accordance with system functions.{SV-AC-6}{AC-3,AC-6,AC-6(9),CA-9,CM-5,CM-5(5),CM-5(6),SA-8(2),SA-8(5),SA-8(6),SA-8(14),SA-8(23),SA-17(7),SC-2,SC-7(29),SC-32,SC-32(1),SI-3} | Least privilege limits damage from compromised processes or insider misuse. Processes receive only the minimum access necessary for assigned functions. This reduces lateral movement and privilege escalation pathways. In deterministic spacecraft systems, privilege boundaries must be tightly defined and enforced. |
| SPR-80 | The [spacecraft] shall execute procedures for ensuring that security-relevant hardware, software, and firmware updates uploaded are exactly as specified by the gold copies. {SV-SP-9,SV-IT-3,SV-SP-3}{CM-3(5),SA-8(8),SA-8(21),SA-8(31),SA-10(3),SA-10(4),SA-10(6),SI-7(10),SI-7(12)} | Ensuring updates match approved gold copies prevents insertion of malicious or altered firmware/software. Compromise during update processes is a high-impact attack vector. Validation protects the trusted computing baseline. This supports recovery and reconstitution integrity. |
| 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-90 | The [organization] shall define and document the transitional state or security-relevant events when the spacecraft will perform integrity checks on software, firmware, and information.{SV-IT-2}{SA-8(21),SI-7(1),SI-7(10),SR-4(4)} | Integrity checks must be executed at well-defined lifecycle transitions (e.g., boot, mode change, update, anomaly). Clear documentation prevents gaps in validation coverage. Transitional state definitions ensure consistent enforcement across mission phases. This supports predictable and auditable trust verification. |
| SPR-91 | The [spacecraft] shall prevent the installation of Flight Software without verification that the component has been digitally signed.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-9}{CM-3,CM-3(8),CM-5,CM-5(3),CM-14,SA-8(8),SA-8(31),SA-10(2),SI-3,SI-7(12),SI-7(15)} | Requiring digital signature verification before installing flight software prevents unauthorized, malicious, or tampered code from being introduced into the spacecraft environment. Software supply chain compromise is a high-impact attack vector that can result in persistent control or loss of mission. Cryptographic validation ensures only approved and trusted binaries are executed. This maintains integrity of the trusted computing baseline. |
| 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-95 | The [spacecraft] shall enforce an attribute-based access control policy over subjects and objects as defined in AC-3(3).{SV-AC-1,SV-AC-4}{AC-3(13)} | Attribute-based access control (ABAC) enables dynamic, context-aware enforcement beyond static role assignments. This reduces privilege abuse and insider misuse by incorporating mission state, location, and environmental factors into decisions. ABAC supports least privilege while enabling operational flexibility. Proper enforcement limits lateral movement and unauthorized data access. |
| SPR-96 | The [spacecraft] shall uniquely identify and authenticate the ground station and other spacecraft before establishing a remote connection.{SV-AC-1,SV-AC-2}{AC-3,AC-17,AC-17(10),AC-20,IA-3,IA-4,SA-8(18),SI-3(9)} | |
| SPR-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-101 | The [spacecraft] shall require multi-factor authorization for all updates to the task scheduling functionality within the spacecraft.{SV-AV-4}{AC-3(2)} | 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-102 | The [spacecraft] shall require multi-factor authorization for new and updates to on-board stored command sequences.{SV-IT-5}{AC-3(2)} | 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-103 | The [spacecraft] software subsystems 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.{SV-MA-3,SV-AV-7}{AC-3(2)} | When software is sole controller of a critical function, redundant and functionally independent command paths reduce systemic risk. A single vulnerability should not allow full compromise of a hazardous control. Diverse mechanisms increase resilience against common-mode failures. This supports both safety and cybersecurity assurance. |
| SPR-104 | The [spacecraft] software subsystems shall provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard.{SV-MA-3,SV-AV-7}{AC-3(2)} | Disabling fault tolerance creates a high-risk operational state. Requiring two independent and unique commands reduces likelihood of accidental or malicious deactivation. This prevents a single compromised control path from undermining redundancy. Hazard mitigation systems must not be easily bypassed. |
| SPR-105 | The [spacecraft] shall provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard.{AC-3(2),PE-10,SA-8(15)} | |
| 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-117 | The [spacecraft] shall provide the capability to restrict command lock based on geographic location of ground stations.{SV-AC-1}{AC-2(11),IA-10,SI-4(13),SI-4(25)} | This could be performed using command lockout based upon when the spacecraft is over selected regions. This should be configurable so that when conflicts arise, the Program can update. The goal is so the spacecraft won't accept a command when the spacecraft determines it is in a certain region. |
| SPR-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-152 | The [spacecraft] shall use automated mechanisms to maintain and validate baseline configuration to ensure the [spacecraft] is up-to-date, complete, accurate, and readily available.{SV-SP-3}{CM-2(2),CM-3(5),CM-3(7),CM-6,SA-8(8)} | This could be command trigger from Ground or elsewhere. The point here is that the self-test is executed onboard the spacecraft via onboard HW/SW self-test mechanisms and its result is reported to the Ground |
| SPR-153 | The [spacecraft] operating system, if COTS or FOSS, shall be selected from a [organization]-defined acceptance list.{SV-SP-7}{CM-7(8),CM-7(5)} | Selecting OS from approved list reduces exposure to unvetted vulnerabilities. Controlled selection supports maintainability and patch governance. This mitigates risk from insecure or unsupported platforms. Trusted baselines simplify compliance verification. |
| SPR-154 | The [spacecraft] shall be capable of removing flight software after updated versions have been installed.{SV-SP-1,SV-SP-9}{SA-8(8),SI-2(6)} | Removing outdated software prevents reactivation of vulnerable versions. This reduces persistence opportunities for adversaries. Maintaining minimal installed versions reduces attack surface. Clean update lifecycle supports system hygiene. |
| SPR-227 | The [organization] shall identify all locations (including ground and contractor systems) that store or process sensitive system information.{SV-CF-3,SV-SP-4,SV-SP-10}{AC-3(11),CM-12} | Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations. |
| SPR-228 | The [organization] shall identify sensitive mission data (e.g.CPI) and document the specific on-board components on which the information is processed and stored.{SV-MA-4,SV-CF-3}{AC-3(11),CM-12} | Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations. |
| SPR-229 | The [organization] shall protect documentation and Controlled Unclassified Information (CUI) as required, in accordance with the risk management strategy.{SV-CF-3,SV-SP-4,SV-SP-10}{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-10,SC-8(1),SC-28(3),SI-12} | Documentation may reveal architecture details exploitable by adversaries. Proper handling prevents leakage. Protection of CUI supports regulatory compliance. Information governance complements technical controls. |
| SPR-230 | The [organization] shall identify and properly classify mission sensitive design/operations information and access control shall be applied in accordance with classification guides and applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-CF-3,SV-AV-5}{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-8(19),SC-8(1),SC-28(3),SI-12} | * Mission sensitive information should be classified as Controlled Unclassified Information (CUI) or formally known as Sensitive but Unclassified. Ideally these artifacts would be rated SECRET or higher and stored on classified networks. Mission sensitive information can typically include a wide range of candidate material: the functional and performance specifications, the RF ICDs, databases, scripts, simulation and rehearsal results/reports, descriptions of uplink protection including any disabling/bypass features, failure/anomaly resolution, and any other sensitive information related to architecture, software, and flight/ground /mission operations. This could all need protection at the appropriate level (e.g., unclassified, SBU, classified, etc.) to mitigate levels of cyber intrusions that may be conducted against the project’s networks. Stand-alone systems and/or separate database encryption may be needed with controlled access and on-going Configuration Management to ensure changes in command procedures and critical database areas are tracked, controlled, and fully tested to avoid loss of science or the entire mission. |
| SPR-231 | The [organization] shall distribute documentation to only personnel with defined roles and a need to know.{SV-CF-3,SV-AV-5}{CM-12,CP-2,SA-5,SA-10} | Least privilege and need to know should be employed with the protection of all documentation. Documentation can contain sensitive information that can aid in vulnerability discovery, detection, and exploitation. For example, command dictionaries for ground and space systems should be handles with extreme care. Additionally, design documents for missions contain many key elements that if compromised could aid in an attacker successfully exploiting the system. |
| SPR-232 | The [organization] shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design.{SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4}{CP-2,CP-2(8),PL-7,PM-11,PM-30(1),RA-3(1),RA-9,SA-8(9),SA-8(11),SA-8(25),SA-12,SA-14,SA-15(3),SC-7(29),SR-1} | During SCRM, criticality analysis will aid in determining supply chain risk. For mission critical functions/components, extra scrutiny must be applied to ensure supply chain is secured. |
| SPR-233 | The [organization] shall identify the applicable physical and environmental protection policies covering the development environment and spacecraft hardware. {SV-SP-4,SV-SP-5,SV-SP-10}{PE-1,PE-14,SA-3,SA-3(1),SA-10(3)} | Development environments must be protected from tampering. Physical controls prevent hardware supply chain compromise. Policy clarity ensures consistent safeguards. Secure development underpins secure deployment. |
| SPR-234 | The [organization] shall develop and document program-specific identification and authentication policies for accessing the development environment and spacecraft. {SV-SP-10,SV-AC-4}{AC-3,AC-14,IA-1,SA-3,SA-3(1)} | Strong authentication prevents unauthorized development access. Development compromise can introduce malicious code. Documented policies ensure consistent enforcement. Identity governance supports supply chain integrity. |
| SPR-235 | The [organization] shall ensure security requirements/configurations are placed in accordance with NIST 800-171 with enhancements in 800-172 on the development environments to prevent the compromise of source code from supply chain or information leakage perspective.{SV-SP-4,SV-SP-10,SV-CF-3}{AC-3,SA-3,SA-3(1),SA-15} | Supply chain threats target development environments. Enhanced controls reduce risk of source code exfiltration. Compliance strengthens contractual and regulatory assurance. Development security directly impacts spacecraft integrity. |
| SPR-236 | The [organization] shall implement a verifiable flaw remediation process into the developmental and operational configuration management process.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-5,SA-3,SA-3(1),SA-11,SI-3,SI-3(10)} | The verifiable process should also include a cross reference to mission objectives and impact statements. Understanding the flaws discovered and how they correlate to mission objectives will aid in prioritization. |
| SPR-237 | The [organization] shall establish robust procedures and technical methods to perform testing to include adversarial testing (i.e.abuse cases) of the platform hardware and software.{SV-SP-2,SV-SP-1}{CA-8,CP-4(5),RA-5,RA-5(1),RA-5(2),SA-3,SA-4(3),SA-11,SA-11(1),SA-11(2),SA-11(5),SA-11(7),SA-11(8),SA-15(7)} | Abuse-case testing reveals design weaknesses before deployment. Red-teaming strengthens defensive posture. Proactive validation reduces operational risk. Testing must simulate realistic threat scenarios. |
| SPR-238 | The [organization] shall require subcontractors developing information system components or providing information system services (as appropriate) to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)} | Select the particular subcontractors, software vendors, and manufacturers based on the criticality analysis performed for the Program Protection Plan and the criticality of the components that they supply. Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc. |
| SPR-239 | The [organization] shall approve, document, and control the use of operational data in preproduction environments (i.e., development, I&T, etc.).{SV-CF-3,SV-SP-10}{SA-3(2)} | Operational data in test environments increases exposure risk. Controlled handling prevents unintended leakage. Proper governance reduces insider and supply chain risk. Sensitive data must be protected at all lifecycle stages. |
| SPR-240 | The [organization] shall categorize/classify preproduction environments (i.e., development, I&T, etc.) at the same level as any operational data in use within the environment and protect the system consistent with its categorization/classification.{SV-SP-10,SV-SP-4}{SA-3(2)} | Development systems often become attack vectors. Equal classification ensures consistent safeguards. Protection must reflect data sensitivity. Weak dev security undermines operational integrity. |
| SPR-241 | The [organization] shall require the developer of the system, system component, or system services to identify organizational data that will be processed or stored on non-organizational systems.{SV-CF-3,SV-SP-6}{SA-4(12)} | Awareness of data location prevents uncontrolled exposure. Third-party systems may lack equivalent security. Explicit identification enables mitigation. Data governance strengthens risk management. |
| SPR-242 | The [organization] shall require the developer of the system, system component, or system services to remove all organizational data from contractor system(s) when no longer needed for development purposes or whenever instructed by the organization.{SV-CF-3}{SA-4(12),SI-21} | Residual data increases breach impact. Timely removal reduces exposure. Lifecycle data hygiene is critical. Controlled offboarding prevents persistence of sensitive information. |
| SPR-244 | The [organization] shall define the secure communication protocols to be used within the mission in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-AC-7,SV-CF-1}{PL-7,RA-5(4),SA-4(9),SA-8(18),SA-8(19),SC-8(1),SC-16(3),SC-40(4),SI-12} | Standardized secure protocols reduce interoperability risk. Alignment with federal standards ensures validated cryptography. Defined protocols prevent ad hoc insecure implementations. Governance strengthens communication assurance. |
| 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-248 | The [organization] shall employ Operations Security (OPSEC) safeguards to protect supply chain-related information for the system, system components, or system services. {CP-2(8),PM-30,SA-12(9),SC-38,SR-7} | Supply chain information can reveal vulnerabilities. OPSEC reduces adversary intelligence gathering. Controlled disclosure minimizes targeting risk. Information discipline strengthens strategic defense. |
| SPR-249 | The [organization] shall employ [Program-defined Operations Security (OPSEC) safeguards] to protect supply chain-related information for the system, system components, or system services.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CP-2(8),PM-30,SA-12(9),SC-38,SR-7} | OPSEC safeguards may include: (1) Limiting the disclosure of information needed to design, develop, test, produce, deliver, and support the element for example, supplier identities, supplier processes, potential suppliers, security requirements, design specifications, testing and evaluation result, and system/component configurations, including the use of direct shipping, blind buys, etc.; (2) Extending supply chain awareness, education, and training for suppliers, intermediate users, and end users; (3) Extending the range of OPSEC tactics, techniques, and procedures to potential suppliers, contracted suppliers, or sub-prime contractor tier of suppliers; and (4) Using centralized support and maintenance services to minimize direct interactions between end users and original suppliers. |
| SPR-250 | The [organization] shall verify that the scope of security testing/evaluation provides complete coverage of required security controls (to include abuse cases and penetration testing) at the depth of testing defined in the test documents.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,RA-5(3),SA-11(5),SA-11(7)} | * The frequency of testing should be driven by Program completion events and updates. * Examples of approaches are static analyses, dynamic analyses, binary analysis, or a hybrid of the three approaches |
| SPR-251 | The [organization] shall maintain evidence of the execution of the security assessment plan and the results of the security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11} | Documented evidence provides traceability and accountability for security testing activities. Without retained artifacts, organizations cannot demonstrate due diligence or validate corrective actions. Preserved results support audits, mission reviews, and lessons learned. This strengthens governance and compliance posture. |
| SPR-252 | The [organization] shall create and implement a security assessment plan that includes: (1) The types of analyses, testing, evaluation, and reviews of all software and firmware components; (2) The degree of rigor to be applied to include abuse cases and/or penetration testing; and (3) The types of artifacts produced during those processes.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11,SA-11(5)} | The security assessment plan should include evaluation of mission objectives in relation to the security of the mission. Assessments should not only be control based but also functional based to ensure mission is resilient against failures of controls. |
| SPR-253 | The [organization] shall coordinate penetration testing on mission critical spacecraft components (hardware and/or software).{SV-MA-4}{CA-8,CA-8(1),CP-4(5)} | Not all defects (i.e., buffer overflows, race conditions, and memory leaks) can be discovered statically and require execution of the system. This is where space-centric cyber testbeds (i.e., cyber ranges) are imperative as they provide an environment to maliciously attack components in a controlled environment to discover these undesirable conditions. Technology has improved to where digital twins for spacecraft are achievable, which provides an avenue for cyber testing that was often not performed due to perceived risk to the flight hardware. |
| SPR-254 | The [organization] shall employ dynamic analysis (e.g.using simulation, penetration testing, fuzzing, etc.) to identify software/firmware weaknesses and vulnerabilities in developed and incorporated code (open source, commercial, or third-party developed code).{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-8,CM-10(1),RA-3(1),SA-11(5),SA-11(8),SA-11(9),SI-3,SI-7(10)} | Dynamic testing uncovers runtime vulnerabilities not visible through static review. Techniques such as fuzzing and penetration testing simulate realistic adversarial behavior. Runtime validation improves detection of memory corruption, logic flaws, and unsafe state transitions. This reduces latent vulnerabilities prior to deployment. |
| SPR-255 | The [organization] shall employ independent third-party analysis and penetration testing of all software (COTS, FOSS, Custom) associated with the system, system components, or system services.{SV-SP-1,SV-SP-3,SV-SP-6}{CA-2,CA-2(1),CA-8(1),CM-10(1),SA-9,SA-11(3),SA-12(11),SI-3,SI-3(10),SR-4(4),SR-6(1)} | Independent assessment reduces bias and uncovers blind spots in internal reviews. External testers provide objective validation of system resilience. Independent penetration testing strengthens confidence in defensive posture. Separation of duties enhances credibility and assurance. |
| SPR-256 | The [organization] shall perform penetration testing/analysis: (1) On potential system elements before accepting the system; (2) As a realistic simulation of the active adversary’s known adversary tactics, techniques, procedures (TTPs), and tools; and (3) Throughout the lifecycle on physical and logical systems, elements, and processes.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CA-8(1),SA-9,SA-11(5),SR-5(2)} | Penetration testing should be performed throughout the lifecycle on physical and logical systems, elements, and processes including: (1) Hardware, software, and firmware development processes; (2) Shipping/handling procedures; (3) Personnel and physical security programs; (4) Configuration management tools/measures to maintain provenance; and (5) Any other programs, processes, or procedures associated with the production/distribution of supply chain elements. |
| SPR-257 | The [organization] shall analyze changes to the spacecraft to determine potential security impacts prior to change implementation.{SV-MA-6,SV-SP-9}{CM-4,CM-3,CM-3(2),CM-3(7),CM-4(2),SA-10} | Changes to spacecraft configuration may introduce unintended vulnerabilities. Pre-implementation impact analysis prevents security regression. Structured review ensures modifications align with risk tolerance. Change control supports mission assurance. |
| SPR-264 | The [organization] shall report counterfeit information system components to [organization] officials. {SV-SP-4}{IR-6,IR-6(2),PM-30,SA-19,SR-11} | Counterfeit components may contain malicious implants or reliability risks. Reporting ensures centralized tracking and mitigation. Early notification prevents systemic exposure. Hardware integrity underpins mission assurance. |
| SPR-265 | The [organization] shall report identified systems or system components containing software affected by recently announced cybersecurity-related software flaws (and potential vulnerabilities resulting from those flaws) to [organization] officials with cybersecurity responsibilities.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-11}{IR-6,IR-6(2),SI-2,SI-3,SI-4(12),SR-4(4)} | Rapid reporting of vulnerable components enables proactive remediation. Awareness of newly disclosed flaws prevents exploitation. Coordination ensures mission-wide response. Visibility reduces systemic risk. |
| SPR-266 | The [organization] shall determine the vulnerabilities/weaknesses that require remediation, and coordinate the timeline for that remediation, in accordance with the analysis of the vulnerability scan report, the mission assessment of risk, and mission needs.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-5,CM-3,RA-5,RA-7,SI-3,SI-3(10)} | Not all vulnerabilities carry equal mission impact. Risk-informed prioritization ensures critical flaws are addressed first. Coordinated timelines balance mission needs with security posture. Structured remediation strengthens governance. |
| SPR-267 | The [organization] shall perform software component analysis (a.k.a.origin analysis) for developed or acquired software.{SV-SP-4,SV-SP-6}{CM-10,CM-10(1),RA-3(1),RA-5,SA-15(7),SI-3,SI-3(10),SR-4(4)} | Origin analysis identifies embedded third-party libraries and dependencies. Transparency reduces supply chain opacity. Knowing component lineage enables targeted vulnerability tracking. This mitigates inherited risk. |
| SPR-268 | The [organization] shall share information obtained from the vulnerability scanning process and security control assessments with [Program-defined personnel or roles] to help eliminate similar vulnerabilities in other systems (i.e., systemic weaknesses or deficiencies).{SV-SP-1}{RA-5} | Sharing scan results prevents repeated weaknesses across systems. Enterprise/Mission visibility reduces systemic vulnerabilities. Collaborative learning enhances resilience. Cross-program transparency strengthens collective defense. |
| SPR-269 | The [organization] shall ensure that the vulnerability scanning tools (e.g., static analysis and/or component analysis tools) used include the capability to readily update the list of potential information system vulnerabilities to be scanned.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,RA-5(1),RA-5(3),SI-3} | Threat landscapes evolve rapidly. Regular tool updates ensure detection coverage remains current. Outdated signatures create blind spots. Continuous improvement sustains effectiveness. |
| SPR-270 | The [organization] shall perform vulnerability analysis and risk assessment of all systems and software. The analysis shall include results from hardware‑in‑the‑loop vulnerability scanning of flight software, firmware, and link‑segment interfaces.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,RA-5(3),SA-15(7),SI-3} | Integrated hardware-in-the-loop testing identifies operationally relevant weaknesses. Combined software, firmware, and interface scanning provides holistic coverage. Risk assessment ensures mitigation aligns with mission priorities. End-to-end analysis strengthens assurance. |
| SPR-271 | The [organization] shall ensure that vulnerability scanning tools and techniques are employed that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: (1) Enumerating platforms, custom software flaws, and improper configurations; (2) Formatting checklists and test procedures; and (3) Measuring vulnerability impact. Scanning shall cover flight software, firmware, and link‑segment interfaces in hardware‑in‑the‑loop environments.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,RA-5(3),SI-3} | Component/Origin scanning looks for open-source libraries/software that may be included into the baseline and looks for known vulnerabilities and open-source license violations. |
| SPR-272 | The [organization] shall perform static binary analysis of all firmware that is utilized on the spacecraft.{SV-SP-7,SV-SP-11}{RA-5,SA-10,SA-11,SI-7(10)} | Many commercial products/parts are utilized within the system and should be analyzed for security weaknesses. Blindly accepting the firmware is free of weakness is unacceptable for high assurance missions. The intent is to not blindly accept firmware from unknown sources and assume it is secure. This is meant to apply to firmware the vendors are not developing internally. In-house developed firmware should be going through the vendor's own testing program and have high assurance it is secure. When utilizing firmware from other sources, "expecting" does not meet this requirement. Each supplier needs to provide evidence to support that claim that their firmware they are getting is genuine and secure. |
| SPR-273 | The [organization] shall perform static source code analysis for all available source code looking for [[organization]-defined Top CWE List] weaknesses using complimentary set of static code analysis tools (i.e.more than one).{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,SA-11(1),SA-15(7)} | Static analysis detects coding weaknesses before execution. Using multiple tools increases detection coverage. Alignment with defined CWE priorities ensures focus on high-risk flaws. Early detection reduces downstream remediation cost. |
| SPR-274 | The [organization] shall analyze vulnerability/weakness scan reports and results from security control assessments.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,SI-3} | Scan results require expert interpretation to avoid false positives or overlooked risks. Structured analysis ensures meaningful remediation. Correlating findings with mission context refines prioritization. Review strengthens governance. |
| SPR-275 | The [organization] shall have automated means to evaluate adherence to coding standards.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15,SA-15(7),RA-5} | Manual review cannot scale across the code base; you must have a way to scale in order to confirm your coding standards are being met. The intent is for automated means to ensure code adheres to a coding standard. |
| SPR-276 | The [organization] shall perform component analysis (a.k.a.origin analysis) for developed or acquired software.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15(7),RA-5} | |
| SPR-277 | In coordination with [organization], the [organization] shall prioritize and remediate flaws identified during security testing/evaluation.{SV-SP-1,SV-SP-3}{CA-2,CA-5,SA-11,SI-3,SI-3(10)} | Timely remediation reduces exploitation window. Coordination ensures mission continuity during patching. Documented prioritization demonstrates due diligence. Structured response enhances accountability. |
| SPR-278 | The [organization] shall correct flaws identified during security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11} | Flaws that impact the mission objectives should be prioritized. |
| SPR-279 | The [organization] shall perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Program-defined depth and coverage].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11} | The depth needs to include functional testing as well as negative/abuse testing. |
| SPR-280 | The [organization] shall require the developer of the system, system component, or system service to deliver the system, component, or service with [Program-defined security configurations] implemented.{SV-SP-1,SV-SP-9}{SA-4(5)} | For the spacecraft FSW, the defined security configuration could include to ensure the software does not contain a pre-defined list of Common Weakness Enumerations (CWEs)and/or CAT I/II Application STIGs. |
| SPR-282 | The [organization] shall use all-source intelligence analysis of suppliers and potential suppliers of the information system, system components, or system services to inform engineering, acquisition, and risk management decisions.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-16,PM-30,RA-2,RA-3(1),RA-3(2),RA-7,SA-9,SA-12(8),SR-5(2)} | * The Program should also consider sub suppliers and potential sub suppliers. * All-source intelligence of suppliers that the organization may use includes: (1) Defense Intelligence Agency (DIA) Threat Assessment Center (TAC), the enterprise focal point for supplier threat assessments for the DOD acquisition community risks; (2) Other U.S. Government resources including: (a) Government Industry Data Exchange Program (GIDEP) – Database where government and industry can record issues with suppliers, including counterfeits; and (b) System for Award Management (SAM) – Database of companies that are barred from doing business with the US Government. |
| SPR-283 | The [organization] shall request threat analysis of suppliers of critical components and manage access to and control of threat analysis products containing U.S.person information.{SV-SP-3,SV-SP-4,SV-SP-11}{PM-16,PM-30(1),RA-3(1),SA-9,SA-12,SR-1} | The intent of this requirement is to address supply chain concerns on hardware and software vendors. Not required for trusted suppliers accredited to the Defense Microelectronic Activity (DMEA). If the Program intends to use a supplier not accredited by DMEA, the government customer should be notified as soon as possible. If the Program has internal processes to vet suppliers, it may meet this requirement. All software used and its origins must be included in the SBOM and be subjected to internal and Government vulnerability scans. |
| SPR-284 | The [organization] shall use all-source intelligence analysis on threats to mission critical capabilities and/or system components to inform risk management decisions.{SV-MA-4}{PM-16,RA-3(2),RA-3(3),RA-7,RA-9,SA-12(8),SA-15(8)} | Intelligence-informed risk management anticipates adversary capabilities. External threat awareness improves proactive defense. Integration into decision-making strengthens resilience. Threat-informed design reduces reactive posture. |
| SPR-291 | The [organization] shall use the threat and vulnerability analyses of the as-built system, system components, or system services to inform and direct subsequent testing/evaluation of the as-built system, component, or service.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-3(3),SA-11(2),SA-15(8),SI-3} | Security analysis should guide test design. Threat-informed evaluation improves relevance. Feedback loops strengthen defensive posture. Analytical alignment enhances coverage. |
| SPR-293 | The [organization] shall employ techniques to limit harm from potential adversaries identifying and targeting the [organization]s supply chain.{SV-SP-4,SV-SP-5,SV-SP-6}{CP-2,PM-30,SA-9,SA-12(5),SC-38,SR-3,SR-3(1),SR-3(2),SR-5(2)} | Adversaries often exploit supplier relationships. Protective measures reduce reconnaissance and manipulation. Supply chain resilience strengthens mission integrity. Proactive defense mitigates systemic exposure. |
| SPR-294 | The [organization] shall use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SA-15(8)} | |
| SPR-295 | The [organization] shall perform and document threat and vulnerability analyses of the as-built system, system components, or system services.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SI-3} | Formal records preserve findings and mitigation strategies. Documentation supports lifecycle traceability. Transparent records enhance oversight. Governance requires evidence. |
| SPR-296 | The [organization] shall conduct an Attack Surface Analysis and reduce attack surfaces to a level that presents a low level of compromise by an attacker.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(6),SA-15(5)} | Reducing exposed interfaces lowers exploitation probability. Quantified surface reduction strengthens resilience. Structured assessment aligns design with mission risk tolerance. Minimization enhances defensive posture. |
| SPR-297 | The [organization] shall require the developer to conduct an attack surface analysis on the spacecraft architecture to identify and reduce attack surfaces to the lowest possible level that still permits the system to meet performance requirements/mission objectives.{SV-MA-6,SV-SP-1}{SA-11(6),SA-15(5)} | Embedding surface reduction into architecture strengthens foundational security. Early analysis prevents costly retrofits. Developer accountability ensures security by design. Integrated evaluation improves mission readiness. |
| SPR-298 | The [organization] shall require the developer to use threat modeling, attack surface analysis, and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable.{SV-MA-6,SV-SP-1}{SA-15(8)} | Threat modeling anticipates adversary tactics. Early design adaptation reduces vulnerability exposure. Learning from similar systems improves efficiency. Proactive analysis reduces downstream risk. |
| SPR-299 | The [organization] shall develop, document, and maintain under configuration control, a current baseline configuration of the spacecrafts.{SV-SP-9,SV-MA-6}{CM-2,CM-3(7),CM-4(2),CM-6,SA-8(30),SA-10} | Configuration control ensures traceability of hardware and software states. Unauthorized changes undermine security posture. Accurate baselines enable recovery and audit. Governance depends on configuration integrity. |
| SPR-300 | The [organization] shall maintain the integrity of the mapping between the master build data (hardware drawings and software/firmware code) describing the current version of hardware, software, and firmware and the on-site master copy of the data for the current version.{SV-SP-4,SV-SP-9}{CM-6,SA-8(21),SA-8(30),SA-10,SA-10(3),SA-10(4),SA-10(5),SI-7(10),SR-4(4)} | Build data linkage ensures reproducibility and traceability. Tampering detection depends on accurate mapping. Integrity of master copies prevents unauthorized modification. Configuration discipline supports resilience. |
| SPR-301 | The [organization] shall develop a security plan for the spacecraft.{SV-MA-6}{PL-2,PL-7,PM-1,SA-8(29),SA-8(30)} | A comprehensive security plan aligns controls with mission objectives. Clear articulation ensures consistent implementation. Planning integrates security into operations. Formal documentation strengthens accountability. |
| 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-303 | The [organization] shall protect the security plan from unauthorized disclosure and modification.{SV-MA-6}{AC-3,PL-2,PL-7} | Exposure of architecture details increases adversary advantage. Protecting documentation reduces reconnaissance risk. Controlled access ensures integrity. Governance must secure sensitive planning artifacts. |
| SPR-304 | The [organization] shall maintain a list of suppliers and potential suppliers used, and the products that they supply to include software.{SV-SP-3,SV-SP-4,SV-SP-11}{CM-10,PL-8(2),PM-30,SA-8(9),SA-8(11)} | Ideally you have diversification with suppliers |
| SPR-305 | The [organization] shall develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including support tamper resistance and provide a level of protection against the introduction of malicious code or hardware.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CM-3(8),CM-7(9),PM-30,SA-8(9),SA-8(11),SA-9,SA-10(3),SA-19,SC-51,SR-4(3),SR-4(4),SR-5(2),SR-11} | Counterfeit hardware may embed malicious implants. Formal policies reduce infiltration risk. Supplier verification strengthens trust. Hardware authenticity is foundational to cybersecurity. |
| SPR-306 | The [organization] shall conduct a supplier review prior to entering into a contractual agreement with a sub [organization] to acquire systems, system components, or system services.{SV-SP-4,SV-SP-6}{PM-30,PM-30(1),RA-3(1),SA-8(9),SA-8(11),SA-9,SA-12(2),SR-5(2),SR-6} | Pre-contract review ensures vendor security posture. Due diligence reduces third-party risk exposure. Structured evaluation strengthens procurement governance. Supplier trust must be verified. |
| SPR-307 | The [organization] shall maintain documentation tracing the strategies, tools, and methods implemented to mitigate supply chain risk .{SV-SP-3,SV-SP-4,SV-AV-7}{PM-30,RA-3(1),SA-12(1),SR-5} | Examples include: (1) Transferring a portion of the risk to the developer or supplier through the use of contract language and incentives; (2) Using contract language that requires the implementation of SCRM throughout the system lifecycle in applicable contracts and other acquisition and assistance instruments (grants, cooperative agreements, Cooperative Research and Development Agreements (CRADAs), and other transactions). Within the DOD some examples include: (a) Language outlined in the Defense Acquisition Guidebook section 13.13. Contracting; (b) Language requiring the use of protected mechanisms to deliver elements and data about elements, processes, and delivery mechanisms; (c) Language that articulates that requirements flow down supply chain tiers to sub-prime suppliers. (3) Incentives for suppliers that: (a) Implement required security safeguards and SCRM best practices; (b) Promote transparency into their organizational processes and security practices; (c) Provide additional vetting of the processes and security practices of subordinate suppliers, critical information system components, and services; and (d) Implement contract to reduce SC risk down the contract stack. (4) Gaining insight into supplier security practices; (5) Using contract language and incentives to enable more robust risk management later in the lifecycle; (6) Using a centralized intermediary or “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary; |
| SPR-308 | The [organization] shall protect against supply chain threats to the system, system components, or system services by employing security safeguards as defined by NIST SP 800-161 Rev.1.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-30,RA-3(1),SA-8(9),SA-8(11),SA-12,SI-3,SR-1} | The chosen supply chain safeguards should demonstrably support a comprehensive, defense-in-breadth information security strategy. Safeguards should include protections for both hardware and software. Program should define their critical components (HW & SW) and identify the supply chain protections, approach/posture/process. |
| SPR-309 | The [organization] shall identify the key system components or capabilities that require isolation through physical or logical means.{SV-AC-6}{AC-3,SC-3,SC-7(13),SC-28(3),SC-32,SC-32(1)} | Fault management and security management capabilities would be classified as mission critical and likely need separated. Additionally, capabilities like TT&C, C&DH, GNC might need separated as well. |
| SPR-310 | The [organization] shall use a certified environment to develop, code and test executable software (firmware or bit-stream) that will be programmed into a one-time programmable FPGA or be programmed into non-volatile memory (NVRAM) that the FPGA executes.{SA-8(9),SA-8(11),SA-12,SA-12(1),SC-51,SI-7(10),SR-1,SR-5} | |
| SPR-311 | The [organization] shall ensure that all ASICs designed, developed, manufactured, packaged, and tested by suppliers with a Defense Microelectronics Activity (DMEA) Trust accreditation.{spacecraft-SP-5} {SV-SP-5}{SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5} | Trusted microelectronics reduce hardware supply chain risk. DMEA accreditation strengthens assurance. Hardware-level compromise prevention protects mission integrity. Secure fabrication underpins secure systems. |
| SPR-312 | If using the Government Microelectronics Assessment for Trust (GOMAT) framework outright, to perform ASIC and FPGA threat/vulnerability risk assessment, the following requirements would apply: {SV-SP-5}{SR-1,SR-5} | • 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened). |
| SPR-313 | The [organization] shall develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of organization-defined systems, system components, or system services.{SV-SP-4,SV-SP-5,SV-SP-6}{SR-2} | Structured SCRM planning identifies lifecycle risks. Comprehensive coverage ensures holistic oversight. Risk planning mitigates systemic exposure. Governance extends beyond deployment. |
| SPR-314 | The [organization] shall protect the supply chain risk management plan from unauthorized disclosure and modification.{SV-SP-4}{SR-2} | Disclosure of SCRM strategy may expose defensive weaknesses. Controlled access preserves operational advantage. Plan integrity prevents tampering. Governance artifacts must be secured. |
| SPR-315 | The [organization] shall review and update the supply chain risk management plan as required, to address threats, organizational, or environmental changes.{SV-SP-4}{SR-2} | Threat landscapes evolve rapidly. Periodic updates maintain relevance. Adaptive management strengthens resilience. Continuous improvement is essential. |
| SPR-316 | The [organization] shall establish a supply chain risk management team to lead and support supply chain risk management activities.{SV-SP-4}{SR-2(1)} | Dedicated oversight ensures coordinated supply chain defense. Defined roles improve accountability. Central leadership streamlines mitigation efforts. Organizational focus strengthens resilience. |
| SPR-317 | The [organization] shall employ [organization]-defined techniques to limit harm from potential adversaries identifying and targeting the Program supply chain.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-3(2),SC-38} | Examples of security safeguards that the organization should consider implementing to limit the harm from potential adversaries targeting the organizational supply chain, are: (1) Using trusted physical delivery mechanisms that do not permit access to the element during delivery (ship via a protected carrier, use cleared/official couriers, or a diplomatic pouch); (2) Using trusted electronic delivery of products and services (require downloading from approved, verification-enhanced sites); (3) Avoiding the purchase of custom configurations, where feasible; (4) Using procurement carve outs (i.e., exclusions to commitments or obligations), where feasible; (5) Using defensive design approaches; (6) Employing system OPSEC principles; (7) Employing a diverse set of suppliers; (8) Employing approved vendor lists with standing reputations in industry; (9) Using a centralized intermediary and “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary Employing inventory management policies and processes; (10) Using flexible agreements during each acquisition and procurement phase so that it is possible to meet emerging needs or requirements to address supply chain risk without requiring complete revision or re-competition of an acquisition or procurement; (11) Using international, national, commercial or government standards to increase potential supply base; (12) Limiting the disclosure of information that can become publicly available; and (13) Minimizing the time between purchase decisions and required delivery. |
| SPR-320 | The [organization] shall develop and document program-specific configuration management policies and procedures for the hardware and software for the spacecraft. {SV-SP-9,SV-MA-6}{CM-1,CM-3,CM-5(6),SA-10,SA-10(3)} | Clear configuration governance prevents unauthorized modification. Policy-backed processes ensure consistency. Lifecycle control supports traceability. Managed change reduces mission risk. |
| SPR-321 | The [organization] shall develop and document spacecraft integrity policies covering both hardware and software. {SV-SP-5,SV-IT-3}{CM-5(6),SA-10(3),SI-1,SI-7(12)} | Integrity policies define expectations for hardware and software protection. Formalized governance ensures consistent enforcement. Clear standards reduce ambiguity. Integrity underpins mission trustworthiness. |
| SPR-322 | The [organization] shall retain at least two previous versions of all spacecraft associated software on the ground with the capability to restore previous version on the spacecraft.{SV-SP-9,SV-SP-4}{CM-2(3),CM-3(7),CM-4(2),SA-10,SA-10(4)} | Maintaining prior software versions enables rapid rollback in the event of faulty or malicious updates. In space systems, recovery options are limited once deployed. Retained versions preserve operational continuity and reduce mission impact. Controlled rollback strengthens resilience against supply chain or update-based compromise. |
| SPR-323 | The [organization] prohibits the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code.{CM-7(8),CM-7(8),CM-10(1),SA-8(9),SA-8(11),SA-10(2),SI-3,SR-4(4)} | |
| SPR-325 | The [organization] shall develop and implement anti-counterfeit policy and procedures, in coordination with the [CIO], that is demonstrably consistent with the anti-counterfeit policy defined by the Program office.{SV-SP-4,SV-SP-11}{SR-11} | Consistent anti-counterfeit policy ensures supply chain integrity across organizational boundaries. Alignment with Program office guidance prevents inconsistent enforcement. Counterfeit components introduce reliability and malicious implant risks. Formal policy strengthens procurement assurance. |
| SPR-327 | The [organization] shall document, monitor, and maintain valid provenance of critical system components and associated data in accordance with the Supply Chain Risk Management Plan.{SV-SP-4,SV-SP-5}{SR-4,SR-4(1),SR-4(2)} | Traceable provenance reduces supply chain opacity and hidden dependency risk. Documentation of origin enables vulnerability tracking and recall response. Monitoring component lineage strengthens trust in deployed hardware and software. Transparency enhances lifecycle accountability. |
| SPR-328 | The [organization] shall ensure any update to on-board software, memory, or stored procedures has met high assurance standards before execution. {SV-SP-9,SV-SP-4}{AC-3(2),CM-3,SA-8(8),SA-8(31),SA-10(2),SR-4(4)} | On-orbit updates carry significant risk if not validated. High assurance standards prevent unauthorized or corrupted uploads from executing. Structured validation protects system integrity. Update governance reduces mission-ending configuration errors. |
| SPR-329 | The [organization] shall perform manual code review of all produced code looking for quality, maintainability, and security flaws.{SV-SP-1}{SA-11(4),SI-3,SI-3(10),SR-4(4)} | Automated tools may miss contextual or logic-based flaws. Manual review improves detection of subtle security weaknesses. Human analysis enhances code quality and maintainability. Combined approaches strengthen overall assurance. |
| SPR-330 | The [organization] shall employ the [organization]-defined approaches for the purchase of the system, system components, or system services from suppliers.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-5} | This could include tailored acquisition strategies, contract tools, and procurement methods. |
| SPR-331 | The [organization] shall test software and firmware updates related to flaw remediation for effectiveness and potential side effects on mission systems in a separate test environment before installation.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-3,CM-3(1),CM-3(2),CM-4(1),CM-4(2),CM-10(1),SA-8(31),SA-11(9),SI-2,SI-3,SI-3(10),SI-7(10),SI-7(12),SR-5(2)} | This requirement is focused on software and firmware flaws. If hardware flaw remediation is required, refine the requirement to make this clear. |
| SPR-332 | The [organization] shall employ [Selection (one or more): independent third-party analysis, Program penetration testing, independent third-party penetration testing] of [Program-defined supply chain elements, processes, and actors] associated with the system, system components, or system services.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-6(1)} | Third-party testing identifies weaknesses across suppliers and processes. Independent review strengthens trust in acquisition channels. Broader testing scope reduces systemic risk. Supply chain validation enhances mission security posture. |
| SPR-335 | The [organization] shall document the spacecraft's security architecture, and how it is established within and is an integrated part of the Program's mission security architecture.{SV-MA-6}{SA-17} | |
| SPR-336 | The [organization] (and Prime Contractor) shall conduct a supplier review prior to entering into a contractual agreement with a contractor (or sub-contractor) to acquire systems, system components, or system services.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-6} | |
| SPR-337 | The [organization] shall ensure that the list of potential system vulnerabilities scanned is updated [prior to a new scan] {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5(2),SI-3} | Outdated vulnerability signatures reduce detection capability. Updating scan definitions ensures coverage against emerging threats. Proactive updates prevent blind spots. Continuous refresh strengthens scanning effectiveness. |
| SPR-343 | The [organization] shall develop and document program-specific access control policies for controlling information flow and leakage on-board the spacecraft.{SV-AC-1,SV-CF-1,SV-CF-3}{AC-1,AC-3,AC-3(3),AC-3(4),AC-3(13)} | Access control policies must reflect mission architecture and threat environment. Formal documentation ensures consistent enforcement. Leakage prevention requires clear governance. Policy clarity supports compliance and auditing. |
| SPR-355 | The [organization] shall implement policies and procedures to support operations security (OPSEC) to protect information about the capabilities and intentions of organizations by identifying, controlling, and protecting information related to the planning and execution of sensitive organizational activities.{SV-CF-3}{SC-38} | Information critical to organizational mission and business functions may include user identities, components in use, suppliers, supply chain processes, functional requirements, security requirements, system design specifications, testing and evaluation protocols, and security control implementation details. |
| SPR-391 | The [organization] shall release updated versions of the mission information systems incorporating security-relevant software and firmware updates, after suitable regression testing, at a frequency no greater than [Program-defined frequency [90 days]].{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-3(2),CM-4(1)} | On-orbit patching/upgrades may be necessary if vulnerabilities are discovered after launch. The system should have the ability to update software post-launch. |
| SPR-392 | The [organization] shall review proposed changes to the spacecraft, assessing both mission and security impacts.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-10,CM-3(2)} | Changes may introduce unintended security regression. Structured review balances mission needs with risk tolerance. Joint mission-security assessment prevents single-domain blind spots. Integrated evaluation supports safe modernization. |
| SPR-393 | The [organization] shall confirm that the operational spacecrafts correspond to the baseline configuration. {SV-SP-9,SV-SP-4}{CM-2,CM-3,CM-3(7),CM-4(2),CM-6,SA-10} | Configuration drift undermines trust and auditability. Confirming alignment ensures deployed assets reflect approved design. Baseline validation supports recovery and compliance. Continuous verification reduces unknown risk. |
| SPR-394 | The [organization] shall implement a two-person rule, or similar dual authorization mechanism, for all changes to the SV configuration, and such actions should only be conducted with documented change control board approval.{SV-AC-4}{CM-3(8)} | Dual authorization reduces insider threat and accidental misconfiguration. Change board approval ensures structured governance. Sensitive changes require accountability. Multi-party validation enhances resilience. |
| SPR-395 | The [organization] shall prohibit the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-7(8)} | Closed binaries from unverified sources limit vulnerability inspection. Source availability supports transparency and review. Prohibiting opaque code reduces hidden malicious logic risk. Supply chain integrity depends on verifiability. |
| SPR-396 | The [organization] shall perform configuration management during system, component, or service during [design; development; implementation; operations].{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-10} | Configuration discipline ensures traceability from design through operations. Lifecycle oversight prevents undocumented changes. Structured management supports rollback and audit. Configuration integrity underpins mission assurance. |
| SPR-397 | The [organization] shall create prioritized list of software weakness classes (e.g., Common Weakness Enumerations) to be used during static code analysis for prioritization of static analysis results.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(1),SA-15(7)} | The prioritized list of CWEs should be created considering operational environment, attack surface, etc. Results from the threat modeling and attack surface analysis should be used as inputs into the CWE prioritization process. There is also a CWSS (https://cwe.mitre.org/cwss/cwss_v1.0.1.html) process that can be used to prioritize CWEs. The prioritized list of CWEs can help with tools selection as well as you select tools based on their ability to detect certain high priority CWEs. |
| SPR-398 | The [organization] shall perform a manual code review of all flight code.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(4)} | Flight code governs mission-critical behavior. Manual review detects subtle logic flaws missed by automation. Human expertise enhances safety assurance. Defense-in-depth requires layered validation. |
| SPR-399 | The [organization] shall define acceptable coding languages to be used by the software developer.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15} | Standardized languages reduce complexity and maintenance burden. Approved languages support secure development practices. Language governance strengthens code quality and review consistency. Reduced heterogeneity improves assurance. |
| SPR-400 | The [organization] shall define acceptable secure coding standards for use by the software developers.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15} | Secure coding standards mitigate common vulnerability patterns. Structured guidance reduces CWE-class weaknesses. Enforcing standards promotes predictable behavior. Governance supports sustainable security hygiene. |
| SPR-401 | The [organization] shall correct reported cybersecurity-related information system flaws.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SI-2} | * Although this requirement is stated to specifically apply to cybersecurity-related flaws, the Program office may choose to broaden it to all SV flaws. * This requirement is allocated to the Program, as it is presumed, they have the greatest knowledge of the components of the system and when identified flaws apply. |
| SPR-402 | The [organization] shall identify, report, and coordinate correction of cybersecurity-related information system flaws.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SI-2} | Centralized reporting ensures timely remediation. Coordinated correction prevents repeated exposure. Documentation strengthens audit traceability. Rapid flaw management reduces exploitation window. |
| SPR-435 | For FPGA pre-silicon artifacts that are developed, coded, and tested by a developer that is not accredited, the [organization] shall be subjected to a development environment and pre-silicon artifacts risk assessment by [organization]. Based on the results of the risk assessment, the [organization] may need to implement protective measures or other processes to ensure the integrity of the FPGA pre-silicon artifacts.{SV-SP-5}{SA-3,SA-3(1),SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5} | DOD-I-5200.44 requires the following: 4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened). |
| SPR-436 | The [organization] shall require the developer of the system, system component, or system services to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)} | Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc. |
| SPR-437 | The [organization] shall enable integrity verification of software and firmware components.{SV-IT-2}{CM-3(5),CM-5(6),CM-10(1),SA-8(9),SA-8(11),SA-8(21),SA-10(1),SI-3,SI-4(24),SI-7,SI-7(10),SI-7(12),SR-4(4)} | * The integrity verification mechanisms may include: ** Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites; ** Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery; ** Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure; ** Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses; ** Implementing cryptographic hash verification; and ** Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing. ** Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites; ** Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery; ** Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure; ** Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses; ** Implementing cryptographic hash verification; and ** Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing. |
| SPR-438 | Any EEEE or mechanical piece parts that cannot be procured from the OCM or their authorized distribution network shall be approved and the government program office notified to prevent and detect counterfeit and fraudulent parts and materials.{SV-SP-5}{SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5} | The Program, working with the contractors, shall identify which ASICs/FPGAs perform or execute an integral part of mission critical functions and if the supplier is accredited “Trusted” by DMEA. If the contractor is not accredited by DMEA, then the Program may apply various of the below ASIC/FPGA assurance requirements to the contractor, and the Program may need to perform a risk assessment of the contractor’s design environment. |
| SPR-439 | For ASICs that are designed, developed, manufactured, packaged, or tested by a supplier that is not DMEA accredited, the ASIC development shall undergo a threat/vulnerability risk assessment. Based on the results of the risk assessment, the [organization] may need to implement protective measures or other processes to ensure the integrity of the ASIC.{SV-SP-5}{SA-8(9),SA-8(11),SA-8(21),SA-12,SA-12(1),SR-1,SR-4(4),SR-5} | DOD-I-5200.44 requires the following: 4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened). |
| SPR-440 | Any EEEE or mechanical piece parts that cannot be procured from the OCM or their authorized franchised distribution network shall be approved by the [organization]’s Parts, Materials and Processes Control Board (PMPCB) as well as the government program office to prevent and detect counterfeit and fraudulent parts and materials.{SV-SP-5}{SR-1,SR-5} | The Program, working with the contractors, shall identify which ASICs/FPGAs perform or execute an integral part of mission critical functions and if the supplier is accredited “Trusted” by DMEA. If the contractor is not accredited by DMEA, then the Program may apply various of the below ASIC/FPGA assurance requirements to the contractor, and the Program may need to perform a risk assessment of the contractor’s design environment. |
| SPR-441 | For ASICs that are designed, developed, manufactured, packaged, or tested by a supplier that is NOT DMEA accredited Trusted, the ASIC development shall undergo a threat/vulnerability risk assessment.The assessment shall use Aerospace security guidance and requirements tailored from TOR-2019-00506 Vol.2, and TOR-2019-02543 ASIC and FPGA Risk Assessment Process and Checklist.Based on the results of the risk assessment, the Program may require the developer to implement protective measures or other processes to ensure the integrity of the ASIC.{SV-SP-5}{SR-1,SR-5} | DOD-I-5200.44 requires the following: 4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened). |
| SPR-442 | For FPGA pre-silicon artifacts that are developed, coded, and tested by a developer that is NOT DMEA accredited Trusted, the contractor/developer shall be subjected to a development environment and pre-silicon artifacts risk assessment by the Program.The assessment shall use Aerospace security guidance and requirements in TOR-2019-00506 Vol.2, and TOR-2019-02543 ASIC and FPGA Risk Assessment Process and Checklist.Based on the results of the risk assessment, the Program may require the developer to implement protective measures or other processes to ensure the integrity of the FPGA pre-silicon artifacts.{SV-SP-5}{SR-1,SR-5} | DOD-I-5200.44 requires the following: 4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened). |
| SPR-443 | The [organization] shall ensure that the contractors/developers have all ASICs designed, developed, manufactured, packaged, and tested by suppliers with a Defense Microelectronics Activity (DMEA) Trust accreditation.{SV-SP-5}{SR-1,SR-5} | |
| SPR-444 | The [organization] shall ensure that the contractors/developers have all EEEE, and mechanical piece parts procured from the Original Component Manufacturer (OCM) or their authorized franchised distribution network.{SV-SP-5}{SR-1,SR-5} | These requirements might only make sense for ASIC/FPGA that are deemed to support mission critical functions. The Program has the responsibility to identify all ASICs and FPGAs that are used in all flight hardware by each hardware element. This list must include all contractor and subcontractor usage of ASICs and FPGAs. |
| SPR-445 | The [organization] shall use a DMEA certified environment to develop, code and test executable software (firmware or bit-stream) that will be programmed into a one-time programmable FPGA or be programmed into non-volatile memory (NVRAM) that the FPGA executes.{SV-SP-5}{SR-1,SR-5} | DOD-I-5200.44 requires the following: 4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened). |
| SPR-448 | The [organization] shall define security requirements/configurations for development environments to prevent the compromise of source code from supply chain or information leakage perspective.{SV-SP-10}{SA-15} | Source code should be classified as Controlled Unclassified Information (CUI) or formally known as Sensitive but Unclassified. Ideally source code would be rated SECRET or higher and stored on classified networks. NIST 800-171 is insufficient when protecting highly sensitive unclassified information and more robust controls from NIST SP 800-53 and CNSSI 1253 should be employed. Greater scrutiny must be applied to all development environments. |
| SPR-449 | The [spacecraft] shall enforce mandatory access control over subjects and objects.{SV-AC-1,SV-AC-4}{AC-3,AC-3(3)} | MAC ensures centrally enforced policy cannot be overridden by subjects. Strong policy binding reduces discretionary abuse. Deterministic enforcement enhances mission protection. Strict separation strengthens confidentiality and integrity. |
| SPR-450 | The [spacecraft] shall prevent flight software and payload applications from modifying access control labels or rules and shall validate label integrity at startup and during policy updates.{SV-AC-1,SV-IT-2}{AC-3(3),AC-3(11).AC-16,SI-7} | Label integrity ensures policy decisions remain trustworthy. Preventing modification protects data classification enforcement. Validation at startup prevents persistent compromise. Policy integrity underpins MAC assurance. |
| SPR-451 | The [spacecraft] shall ingest [organization]-defined revocation updates to onboard access control lists and attribute sets and shall enforce revocation within [Program-defined time] of receipt.{SV-AC-4,SV-AC-3}{AC-3(8)} | Timely revocation prevents continued access by compromised identities. Defined enforcement timelines reduce residual exposure. Structured update ingestion strengthens identity governance. Rapid revocation reduces insider and key compromise risk. |
| SPR-452 | The [spacecraft] shall deny commands, data requests, and connections from revoked identities and shall generate an audit record for each denial.{SV-AC-4,SV-DCO-1}{AC-3,AC-3(8),AU-2,AU-12} | Explicit denial and logging strengthens accountability. Automated enforcement reduces reliance on manual monitoring. Recorded denials support forensic investigation. Policy adherence strengthens defense. |
| SPR-453 | The [spacecraft] shall restrict any override of access control mechanisms to [Program-defined emergency conditions] and shall generate an auditable event for each invocation that includes the time, origin, justification code, affected functions, and exit status.{SV-AC-4}{AC-3,AC-3(10),AU-2,AU-3} | Overrides introduce risk and must be tightly constrained. Auditable invocation ensures accountability. Time-limited emergency use reduces misuse potential. Structured control preserves integrity. |
| SPR-455 | The [spacecraft] shall restrict access to flight software executables, cryptographic material, command dictionaries, and [organization]-defined sensitive payload data to the privileged execution domain and shall deny all other access by default.{SV-AC-1,SV-AC-3,SV-IT-3}{AC-3(11),AC-6} | Flight executables and cryptographic materials are high-value targets. Restricting access reduces exploitation pathways. Default deny enforces least privilege. Segmentation enhances resilience. |
| SPR-456 | The [spacecraft] shall implement OS or hardware enforcement for these restrictions and shall log any attempted access violations.{SV-AC-1,SV-DCO-1}{AC-3,AC-3(11)} | Hardware-enforced policy is harder to bypass than software-only controls. Logging violations supports detection and response. Layered enforcement strengthens assurance. Technical barriers reinforce governance intent. |
| SPR-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-458 | The [spacecraft] shall enforce [organization]-defined domain based routing policies that restrict which subsystems may relay information to one another.{SV-AC-6}{CA-3(7),AC-4} | Domain segmentation prevents unrestricted lateral data movement. Restricting which subsystems may relay information reduces cross-domain compromise risk. Routing policy enforcement supports least privilege and mission isolation. Structured boundaries strengthen resilience. |
| SPR-460 | The [spacecraft] shall record transitive forwarding decisions and rejections in cyber relevant audit data for downlink.{SV-DCO-1}{CA-3(7),AU-3,AU-12} | Audit records of forwarding and rejection decisions enable forensic reconstruction. Visibility into routing logic prevents covert channel abuse. Logged rejections demonstrate enforcement of policy. Downlink visibility strengthens ground oversight. |
| SPR-462 | The [spacecraft] shall support delegation of temporary data storage to [organization]-authorized alternate nodes or spacecraft and shall preserve confidentiality, integrity, and access controls for the delegated data.{SV-CF-1,SV-CF-2,SV-AC-1}{CP-2(6),SC-28,AC-3} | Delegated storage or processing expands trust boundaries. Maintaining CIA protections during delegation prevents exposure. Secure federation supports constellation-based architectures. Controlled delegation strengthens distributed resilience. |
| SPR-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-476 | The [organization] shall identify suppliers of mission-critical or mission-essential items and apply enhanced oversight that includes security practice vetting, contract language mandating secure manufacturing, and periodic compliance audits.{SV-SP-4,SV-SP-5}{PM-30(1),SR-6,SR-3} | Mission-critical suppliers require elevated scrutiny. Contractual language enforces security standards. Periodic audits reduce supply chain risk. Oversight strengthens systemic assurance. |
| SPR-477 | The [organization] shall require independent testing and inspection of mission-critical components prior to integration to verify hardware integrity and cryptographic module assurance.{SV-SP-5,SV-AC-3}{PM-30(1),SR-11} | Third-party validation reduces conflict-of-interest risk. Independent inspection verifies hardware integrity and cryptographic assurance. External attestation strengthens confidence. Verification supports mission-critical trust. |
| SPR-478 | The [organization] shall map supplier failure impact to mission functions and assign risk-based oversight and acceptance criteria.{SV-SP-4,SV-MA-6}{PM-30(1),SR-2,RA-3} | Understanding supplier failure impact informs oversight priority. Risk-based criteria ensure proportional governance. Structured assessment prevents blind spots. Supply chain risk alignment strengthens mission resilience. |
| 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-481 | The [organization] shall define and document data ownership for mission data types across the space platform and link segment, including authority over classification, storage, retention, distribution, cross-domain transfer, and decommissioning.{SV-CF-3}{SA-4(12)} | Clear authority over mission data reduces ambiguity. Defined classification and retention policies prevent mishandling. Ownership governance strengthens accountability. Structured control supports compliance. |
| SPR-483 | The [organization] shall require trusted generation of flight and payload software and configuration baselines in a controlled build environment that enforces signed commits, reproducible builds, cryptographic hashing, and code signing of release artifacts, and shall maintain a configuration-controlled golden image for comparison and rollback.{SV-SP-4,SV-SP-3,SV-SP-9}{SA-10(4)} | Controlled builds prevent unauthorized code injection. Reproducible builds strengthen supply chain transparency. Golden images support rollback and forensic validation. Configuration control strengthens integrity. |
| 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-503 | The [organization] shall validate authenticity and integrity of all flight-designated hardware, firmware, and software upon receipt using program-controlled trust anchors (approved vendor list, golden hash/cert manifest){SV-SP-4,SV-SP-5}{SR-4(3),SR-11,SI-7} | Receipt validation prevents counterfeit or tampered parts integration. Program-controlled trust anchors ensure consistency. Early detection reduces downstream risk. Intake verification strengthens SCRM posture. |
| SPR-504 | The [organization] shall re-validate component identity (serial/lot), firmware measurements (cryptographic hashes), and certificate status immediately prior to installation, writing results to the SCRM/provenance ledger and blocking install on mismatch.{SV-SP-4,SV-SP-5}{SR-4(3),SR-11,SI-7} | Installation-time validation prevents stale or revoked components. Ledger recording strengthens traceability. Blocking on mismatch prevents compromise propagation. Continuous verification enhances assurance. |
| SPR-505 | The [spacecraft] shall cryptographically verify boot images and configurations at power-on and after any update{SV-IT-3,SV-SP-9}{SR-4(3),SI-7,CM-14} | Secure boot prevents execution of unauthorized code. Post-update verification ensures integrity continuity. Root-of-trust enforcement protects mission-critical logic. Deterministic startup strengthens resilience. |
| SPR-506 | The [organization] supplier shall provide a signed pedigree for each critical flight item (COTS/ASIC/FPGA/embedded SW library) including: manufacturing lot/wafer, test results and environmental/rad-hard certs, sub-tier sources, workforce vetting attestation as required, and full chain-of-custody events; the program shall store/track this in the SCRM/provenance ledger.{SV-SP-4,SV-SP-5}{SR-4(4),SR-6} | Signed pedigree documents manufacturing and handling lineage. Chain-of-custody transparency reduces counterfeit risk. Ledger tracking strengthens auditability. Supply chain evidence supports mission trust. |
| SPR-507 | The [organization] shall require independent lab attestations (e.g., rad-hardness, crypto module validation) for mission-essential/crypto-bearing parts; acceptance requires labs from an approved list.{SV-SP-5}{SR-4(4),SR-6} | Third-party validation strengthens assurance of rad-hardness and crypto modules. Approved lab lists reduce conflict of interest. Independent evidence increases confidence. Verification strengthens acceptance criteria. |
| SPR-508 | Within [organization]-defined window (e.g.,30/60/90 days) before integration or stow, the pedigree shall be re-verified and seals/marks inspected to detect substitution{SV-SP-4,SV-SP-5}{SR-4(4),SR-11,PE-16} | Time between receipt and integration creates substitution risk. Re-verification ensures seals, markings, and provenance remain intact. This reduces last-minute supply chain compromise. Periodic pedigree validation strengthens SCRM integrity. |
| SPR-509 | The [organization] shall procure flight items only from an AO-approved vetted supplier whitelist; off-list buys require documented risk acceptance and compensating pedigree/scanning.{SV-SP-4}{SR-4(4),SR-3,SR-5} | Restricting procurement to vetted suppliers reduces counterfeit and tampering risk. Off-list acquisitions require formal risk acceptance, preserving governance. Structured sourcing strengthens trust anchors. Controlled procurement reduces systemic exposure. |
| SPR-515 | The [spacecraft] shall enforce discretionary access on [organization]-defined payload data stores using short‑lived, purpose‑specific grants bound to execution windows or end‑of‑pass, with automatic expiration, audited changes/uses, and integrity checks on permission metadata that survive resets/SEUs.{SV-AC-4,SV-AC-1}{AC-3(4)} | Ephemeral grants reduce persistence risk. Execution-window binding prevents privilege creep. Surviving SEUs ensures metadata integrity. Time-bounded access supports least privilege. |
| SPR-517 | The [organization] shall correlate station/operator session activity with pass schedules and spacecraft mode, alert on off‑schedule access and command families invalid for the current mode, and retain results as audit evidence.{SV-AC-4,SV-AC-1,SV-AV-4}{AC-17,AC-17(1),SI-4,AU-6} | Off-schedule or mode-inconsistent commands signal compromise. Correlation across dimensions strengthens anomaly detection. Audit retention supports post-event review. Context validation strengthens mission assurance. |
| SPR-518 | The [organization] shall require external stations/relays to complete an onboarding certification demonstrating operator/facility vetting, key custody and revocation practices, RF configuration discipline, time synchronization, and adherence to pass scheduling and emergency procedures, with periodic re‑certification.{SV-MA-7,SV-AC-4}{AC-17,AC-20,AC-20(1),SR-6} | Relay and partner stations expand trust boundaries. Certification ensures consistent security practices. Periodic re-validation prevents drift. External governance strengthens link integrity. |
| SPR-521 | The [spacecraft] shall prevent execution of [organization]-defined hazardous procedures when minimal auditing cannot be assured (e.g., verified buffer availability or local shadow log), while allowing essential safing actions; operator feedback shall distinguish “blocked due to no audit” from other rejects.{SV-AC-8,SV-DCO-1}{AC-3,AU-5,AU-5(2)} | Certain operations require audit traceability. Blocking when audit is unavailable prevents blind execution. Essential safing remains permitted. Conditional enforcement strengthens accountability. |
| SPR-528 | The [organization] shall package each flight change (software, bitstreams, configuration tables) with a signed manifest, precondition checks (mode, power/thermal, link), explicit hold/commit points, and resumable procedures across AOS/LOS; the [spacecraft] shall enforce manifest checks prior to activation.{SV-SP-9,SV-IT-2}{CM-3,CM-3(2),SI-7,SA-10} | Manifest enforcement ensures integrity prior to activation. Precondition checks prevent unsafe changes. Resumable logic supports space contact constraints. Structured packaging strengthens update security. |
| SPR-530 | The [spacecraft] shall enable selected maintenance capabilities only within time‑bounded and mode‑bounded windows, audit enable/disable events, auto‑revert on timeout/reset, and expose enabled/disabled capability state in telemetry.{SV-AC-8,SV-AC-4}{CM-7,CM-7(2),SA-8,SA-8(14),AC-3} | Maintenance capabilities expand risk surface. Time-limited activation reduces abuse window. Telemetry exposure ensures oversight. Auto-revert strengthens containment. |
| SPR-531 | The [spacecraft] shall enforce whitelisting for executable images and mission scripts/procedures by ID, hash, or signature, accept only artifacts produced by the mission build pipeline, and constrain interpreters/macros to sandboxed contexts with provenance checks on inputs.{SV-SP-9,SV-SP-4}{CM-7,CM-7(5),CM-7(8),SI-7} | Accepting only pipeline-produced artifacts prevents unauthorized code execution. Hash/signature validation ensures integrity. Sandbox constraints limit interpreter abuse. Provenance enforcement strengthens defense. |
| SPR-533 | The [spacecraft] and [organization] shall adapt identification and authorization based on mission context (e.g., anomaly response, unscheduled contact, safe mode) by tightening factors/keys, narrowing station whitelists, and enforcing geo/time and mode constraints, with telemetry cues and reversion to baseline.{SV-AC-4,SV-AC-1}{IA-1,IA-5,IA-10} | Threat posture varies by mission state. Adaptive controls tighten during anomalies. Telemetry cues ensure transparency. Contextual enforcement supports Zero Trust maturity. |
| SPR-537 | The [organization] shall define event‑driven triggers for rapid risk reassessment (e.g., new images/bitstreams, key rotations, partner‑station onboarding, notable anomalies, vendor advisories) and rehearse fast‑turn evaluations in a twin/flatsat to drive decisions within one or two passes.{SV-SP-6,SV-SP-9}{RA-3,RA-3(1),CA-7} | Triggers ensure timely re-evaluation after impactful events. Flatsat rehearsal validates mitigation feasibility. Rapid cycles align with limited contact windows. Structured agility strengthens mission defense. |
| 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-547 | The [spacecraft] shall support chunked uploads of software/bitstreams/configuration with per‑chunk verification and commit markers, resumable across passes, with atomic activation and rollback if activation checks fail.{SV-SP-9,SV-IT-2}{SI-7,SI-7(15)} | Per-chunk verification prevents partial corruption. Atomic activation avoids inconsistent states. Rollback ensures safe recovery. Structured update logic strengthens resilience. |
| SPR-548 | The [spacecraft] shall retire superseded images, keys, and parameter sets using cryptographic erasure or verified wipe where supported, retain only golden and current versions needed for rollback, and expose an inventory of active/staged artifacts in telemetry.{SV-SP-9}{SI-2(6)} | Cryptographic erasure prevents legacy exploitation. Limiting retained versions reduces attack surface. Telemetry exposure ensures awareness. Controlled lifecycle management strengthens integrity. |