Tamper Protection

Tamper protection encompasses physical and logical controls that detect, deter, and respond to unauthorized modification of mission hardware and software throughout the acquisition, transit, storage, integration, and operational phases of the mission lifecycle. Physical tamper protection requires inspection of hardware at defined custody transfer points to detect evidence of unauthorized access or modification, and requires the use of tamper-evident packaging and sealing mechanisms during shipping and receiving to ensure that any interference with equipment in transit is detectable upon arrival. Logical tamper protection addresses the integrity of software and firmware through layered techniques including code obfuscation, integrity checks that verify software has not been altered from its approved state, and runtime integrity monitoring mechanisms such as self-checking code. Watchdog processes may supplement these controls by detecting abnormal execution or failure to complete expected processing, but do not by themselves verify software integrity. Physical and logical tamper protections are complementary and should be applied together where warranted by system criticality, threat exposure, and lifecycle conditions. Physical access to hardware can enable logical tampering, while failure to verify software integrity can reduce the assurance provided by physical controls.

Sources

https://attack.mitre.org/datasources/DS0013/

https://www.iso.org/standard/56890.html

ID: CM0028

Tier: II

Onboard SV CM

Created: 2022/10/19

Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should address both physical and logical tamper protection as distinct but related design and procedural requirements, with specifications covering tamper-evident packaging standards for shipment and receipt, physical inspection requirements at defined custody transfer points, and the software integrity mechanisms to be implemented in deliverable systems. Contract language should require contractors to document and implement tamper-evident handling and inspection procedures for hardware based on its criticality, custody exposure, and supply-chain risk. Inspection records should document required examinations for signs of tampering at designated receipt or custody-transfer points. Requirements for software tamper protection should specify the techniques to be employed, such as integrity checking, runtime monitoring, and obfuscation where appropriate, and should require that these mechanisms be verified through adversarial testing that attempts to modify software and confirms that the protection mechanisms detect and respond correctly. Flow-down provisions should require that subcontractors and suppliers apply equivalent tamper-evident handling and inspection procedures to components and assemblies before they are delivered to the prime contractor. Evaluation criteria should assess offerors' proposed tamper protection approaches for both hardware and software, their experience implementing runtime integrity monitoring in constrained embedded environments, and their procedures for handling and investigating discovered tampering evidence.

Pre-Operations Developer/Supplier

Physical tamper protection should be specified as a handling and logistics requirement from the earliest procurement planning activities, with tamper-evident sealing, packaging standards, and chain-of-custody documentation requirements defined before hardware begins moving through the supply chain. Inspection procedures at each custody transfer point should be documented, specifying what physical evidence of tampering is to be examined, who is authorized to conduct the inspection, and what actions are required if tampering is detected, including quarantine, forensic preservation, and escalation procedures. Software tamper protection mechanisms should be selected and architected during the system design phase, with the combination of techniques chosen based on the criticality of the software, the threat environment, and the computational constraints of the target platform. Runtime integrity monitoring mechanisms must be designed so that they do not adversely affect mission-critical timing, resource availability, or safety-related processing. The mechanisms, their configuration, and their integrity reference values must be protected from unauthorized modification or disablement. Code obfuscation, where applied, should be treated as a defense-in-depth measure that increases the effort required for adversarial analysis and modification. It does not establish software integrity and should not impede authorized maintenance, debugging, or verification.

Sustainment & Maintenance Government

Operational tamper monitoring requires that software integrity checking and runtime monitoring mechanisms be validated as part of each software update cycle, confirming that updates have not inadvertently disabled or degraded tamper detection capabilities and that the mechanisms correctly reflect the updated software baseline. Alerts generated by runtime integrity monitoring mechanisms should be routed to personnel with authority to investigate and respond, with response procedures defined in advance that distinguish between false positives from benign operational conditions and genuine indicators of software tampering requiring immediate escalation. Physical hardware that has been in uncontrolled or reduced-security environments, such as hardware temporarily located at a third-party facility, a launch site, or a remote ground station, should undergo tamper inspection before being reconnected to mission systems. Any detected evidence of physical or logical tampering should trigger an incident response process that includes forensic preservation of the affected hardware or software, assessment of what information or access the adversary may have gained, and evaluation of whether other components with similar physical or logical access exposure may also have been compromised.

Sustainment & Maintenance Developer/Supplier

Techniques Addressed by Countermeasure

ID		Name	Description
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.
	.03	Hardware Supply Chain	Adversaries alter boards, modules, or programmable logic prior to delivery to create latent access or reliability sabotage. Tactics include inserting hardware Trojans in ASIC/FPGA designs, modifying bitstreams or disabling security fuses, leaving debug interfaces (JTAG/SWD/UART) active, substituting near-spec counterfeits, or embedding parts that fail after specific environmental or temporal conditions (“time-bomb” components). Other avenues target programming stations and “golden” images so entire lots inherit the same weakness. Microcontroller boot configurations, peripheral EEPROMs, and supervisory controllers are common leverage points because small changes there can reshape trust boundaries across the bus. The effect is a platform that behaves nominally through acceptance test yet enables covert control, targeted degradation, or delayed failure once on orbit.
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-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.
	.02	Receiver	Threat actors may target the spacecraft’s secondary (backup) RF receive path, often a differently sourced radio, alternate antenna/feed, or cross-strapped front end that is powered or enabled under specific modes. Threat actors map when the backup comes into play (safing, antenna obscuration, maintenance, link degradation) and what command dictionaries, framing, or authentication it expects. If the backup receiver has distinct waveforms, counters, or vendor defaults, the attacker can inject traffic that is accepted only when that path is active, limiting exposure during nominal ops. Forcing conditions that enable the backup, jamming the primary, exploiting geometry, or waiting for routine tests, creates the window for first execution. The result is a foothold gained through a rarely used RF path, exploiting differences in implementation and operational cadence between primary and standby receive chains.
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-0011		Auxiliary Device Compromise	Adversaries abuse peripherals and removable media that the spacecraft (or its support equipment) ingests during development, I&T, or on-orbit operations. Small satellites and hosted payloads frequently expose standard interfaces, USB, UART, Ethernet, SpaceWire, CAN, or mount removable storage for loading ephemerides, tables, configuration bundles, or firmware. A tainted device can masquerade as a trusted class (mass-storage, CDC/HID) or present crafted files that trigger auto-ingest workflows, file watchers, or maintenance utilities. Malware may be staged by modifying the peripheral’s firmware, seeding the images written by lab formatting tools, or swapping media during handling. Once connected, the device can deliver binaries, scripts, or malformed data products that execute under existing procedures. Because these interactions often occur during hurried timelines (checkouts, rehearsals, contingency maintenance), the initial execution blends with legitimate peripheral use while traversing a path already privileged to reach flight software or controllers.
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-0004		Compromise Boot Memory	The attacker manipulates memory and configuration used in the earliest stages of boot so that their code runs before normal protections and integrity checks take hold. Targets include boot ROM vectors, first-stage/second-stage bootloaders, boot configuration words and strap pins, one-time-programmable (OTP) fuses, non-volatile images in flash/EEPROM, and scratch regions copied into RAM during cold start. Techniques range from replacing or patching boot images to flipping configuration bits that alter trust decisions (e.g., image selection, fallback order, watchdog behavior). Faults can be induced deliberately (timed power/clock/EM glitches) or via crafted update/write sequences that leave a partially programmed but executable state. Once resident, the modification can insert early hooks, disable or short-circuit checks, or select downgraded images; destructive variants corrupt the boot path to induce a persistent reset loop or safeing entry (a denial of service). Because boot logic initializes buses, memory maps, and handler tables, even small changes at this stage cascade, shaping how command handlers load, how keys and counters are initialized, and which peripherals are trusted for subsequent execution.
EX-0005		Exploit Hardware/Firmware Corruption	The adversary achieves execution or effect beneath the software stack, in device firmware, programmable logic, or the hardware itself, either by corrupting that layer or by driving it through interfaces that function exactly as designed. Examples include tampering with firmware images or configuration blobs burned into non-volatile memory; targeting MCU/SoC boot ROM fallbacks; editing FPGA bitstreams or partial-reconfiguration frames; leveraging physical phenomena and timing to flip bits or skip checks; or issuing legitimate low-level device, maintenance, and calibration commands that act directly on hardware without passing through high-level command mediation. Because these actions occur below or alongside the operating system and application FSW, traditional endpoint safeguards see normal interfaces while trust anchors are already altered.
	.01	Design Flaws	Threat actors may exploit inherent properties or errata in the hardware/logic design rather than injecting new code. Levers include undocumented or weakly specified behaviors (scan chains, test modes, debug straps), counter/timer rollovers and wraparound, interrupt storms and priority inversions, MMU/TLB corner cases, DMA engines that can write outside intended buffers, and bus arbitration or clock-domain crossing issues that permit stale or reordered writes. RNGs and crypto accelerators with flawed seeding or side-channel leakage can expose secrets or enable predictable authentication values. In programmable logic, vulnerable state machines, insufficient reset paths, and hazardous partial-reconfiguration regions create opportunities to drive the design into privileged or undefined states. Even reliability features can be turned: hardware timers intended for liveness can be paced to starve control loops; ECC policies can be nudged so correction conceals attacker-induced drift. The common thread is using the platform’s own guarantees, timing, priority, persistence, or fault handling, to cause privileged behavior that the software stack accepts as “by design.”
PER-0001		Memory Compromise	The adversary arranges for malicious content to survive resets and mode changes by targeting memories and execution paths that initialize the system. Candidates include boot ROM handoff vectors, first/second-stage loaders, non-volatile images (flash/EEPROM), “golden” fallback partitions, configuration words/fuses, and RAM regions reconstructed at start-up from stored files or tables. Persistence may also ride auto-run mechanisms, init scripts, procedure engines, stored command sequences, or event hooks that execute on boot, safe-mode entry/exit, time triggers, or receipt of specific telemetry/commands. Variants keep the core payload only in RAM but ensure it is reloaded after every restart by patching copy-on-boot routines, altering file catalogs, or modifying table loaders so the same bytes are restored. The common thread is control of where the spacecraft looks for what to run next, so unauthorized logic is reinstated whenever the system resets or transitions modes.
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.
	.01	Hardware Backdoor	Hardware backdoors leverage properties of the physical design to provide durable, low-visibility reentry. Examples include enabled test/scan chains, manufacturing or boot-strap modes invoked by pins or registers, persistent debug interfaces (JTAG/SWD/UART), undocumented device commands, and logic inserted in FPGA/ASIC designs that activates under specific stimuli. Because these mechanisms sit below or beside flight software, they can grant direct access to buses, memories, or peripheral control even when higher layers appear healthy. Triggers may be electrical (pin states, voltage/clock sequences), protocol-level (special patterns on an instrument link), or environmental/temporal (particular temperature ranges, timing offsets). Once on orbit, such pathways are difficult to remove or reconfigure, allowing the attacker to persist by reusing the same physical entry points whenever conditions are met.
PER-0004		Replace Cryptographic Keys	The adversary cements control by changing the cryptographic material the spacecraft uses to authenticate or protect links and updates. Targets include uplink authentication keys and counters, link-encryption/session keys and key-encryption keys (KEKs), key identifiers/selectors, and algorithm profiles. Using authorized rekey commands or key-loading procedures, often designed for over-the-air use, the attacker installs new values in non-volatile storage and updates selectors so subsequent traffic must use the attacker’s keys to be accepted. Variants desynchronize anti-replay by advancing counters or switching epochs, or strand operators by flipping profiles to a mode for which only the adversary holds parameters. Once replaced, the new material persists across resets and mode changes, turning the spacecraft into a node that recognizes the adversary’s channel while rejecting former controllers.
LM-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.
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.
	.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.
	.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.

Space Threats Addressed by Countermeasure

ID	Description
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-IT-3	Compromise boot memory
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-4	General supply chain interruption or manipulation
SV-SP-5	Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused}

Sample Requirements

SPARTA ID	Requirement	Rationale/Additional Guidance/Notes
SPR-1	The [spacecraft] shall implement a reference monitor mechanism that mediates access between subjects and objects based on a defined set of rules, that is designed and configured to resist tampering or unauthorized alteration, providing a reliable and secure foundation for access control within the information system.{SV-AC-1,SV-AC-4,SV-SP-7}{AC-25}	A reference monitor provides the foundational enforcement point for all access control decisions within the spacecraft. Without a tamper-resistant mediation layer, compromised flight software or malicious code could directly access critical memory, processes, or hardware interfaces. The mechanism must be isolated from modifiable flight software to preserve integrity under adversarial conditions.
SPR-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-53	The [organization] shall employ automated tools that provide notification to ground operators upon discovering discrepancies during integrity verification.{CM-3(5),CM-6,IR-6,IR-6(2),SA-8(21),SC-51,SI-3,SI-4(7),SI-4(12),SI-4(24),SI-7(2)}
SPR-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-62	The [spacecraft] shall enter a cyber-safe mode when conditions that threaten the platform are detected, enters a cyber-safe mode of operation with restrictions as defined based on the cyber-safe mode.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4,IR-4(1),IR-4(3),PE-10,RA-10,SA-8(16),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-13,SI-17}	Cyber-safe mode provides a deterministic fallback posture when compromise or anomalous conditions threaten mission integrity. Restricting non-essential functions reduces attack surface and prevents further propagation of malicious activity. Defined restrictions ensure predictable behavior under cyber stress conditions. This supports survivability and controlled recovery rather than uncontrolled degradation.
SPR-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-79	The [spacecraft] and all ground support systems (including those during development) shall be capable of detecting unauthorized hardware components/connections.{SV-SP-5,SV-SP-4}{CM-7(9)}	Unauthorized hardware introduces supply chain risk, covert backdoors, or malicious implants. Detection across development and operational environments prevents latent compromise from propagating to flight systems. Hardware verification supports trusted system baselines. Physical-layer assurance complements software integrity controls.
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-81	The [spacecraft] shall perform an integrity check of software, firmware, and information at startup or during security- events.{SV-IT-3,SV-SP-7,SV-SP-3}{CM-3(5),SA-8(9),SA-8(11),SA-8(21),SI-3,SI-7(1),SI-7(10),SI-7(12),SI-7(17)}	Startup integrity checks detect boot-level compromise or unauthorized modification. Event-triggered checks provide additional protection when anomalies occur. This limits adversary persistence across reboots. Continuous validation reinforces trusted boot regimes.
SPR-82	The [spacecraft] boot firmware shall validate the boot loader, boot configuration file, and operating system image, in that order, against their respective signatures.{SV-IT-3}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10)}	A signature is ~770 bits long. No requirement is imposed on the storage location of signatures.
SPR-83	The [spacecraft] boot firmware shall verify a trust chain that extends through the hardware root of trust, boot loader, boot configuration file, and operating system image, in that order.{SV-IT-3}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10)}	These three items were chosen because they’re intended to be static values (once properly set up) but are in volatile storage. Also, the Boot ROM can’t be modified, so there’s no reason to check a signature.
SPR-84	The [spacecraft] trusted boot/RoT computing module shall be implemented on radiation tolerant burn-in (non-programmable) equipment.{SV-IT-3,SV-SP-5}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10)}	Root of Trust must be anchored in immutable hardware to prevent software-level compromise. Radiation-tolerant burn-in hardware ensures stability in space environments. Non-programmable components prevent adversarial modification of trust anchors. Hardware-based trust strengthens system-wide assurance.
SPR-85	The [spacecraft] trusted boot/RoT shall be a separate compute engine controlling the trusted computing platform cryptographic processor.{SV-IT-3,SV-SP-7}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10)}	Separating the trust engine from general-purpose compute reduces attack surface. Independent control over cryptographic processors prevents compromised flight software from influencing trust validation. This architectural separation preserves chain-of-trust integrity. Isolation enhances resilience against firmware-level threats.
SPR-86	The [spacecraft] shall perform attestation at each stage of startup and ensure overall trusted boot regime (i.e., root of trust).{SV-IT-3}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10),SI-7(17)}	It is important for the computing module to be able to access a set of functions and commands that it trusts; that is, that it knows to be true. This concept is referred to as root of trust (RoT) and should be included in the spacecraft design. With RoT, a device can always be trusted to operate as expected. RoT functions, such as verifying the device’s own code and configuration, must be implemented in secure hardware (i.e., field programmable gate arrays). By checking the security of each stage of power-up, RoT devices form the first link in a chain of trust that protects the spacecraft
SPR-87	The [spacecraft] shall be configured to provide only essential capabilities.{SV-SP-7,SV-SP-1}{CM-6,CM-7,SA-8(2),SA-8(7),SA-8(13),SA-8(23),SA-8(26),SA-15(5)}	Minimizing enabled functionality reduces attack surface and complexity. Unused services create unnecessary exposure. Essential-only configuration aligns with least functionality principles. This simplifies validation and reduces exploit vectors.
SPR-88	The [spacecraft] shall detect and recover from detected memory errors or transitions to a known cyber-safe state.{SV-IT-4,SV-AV-6}{IR-4,IR-4(1),SA-8(16),SA-8(24),SI-3,SI-4(7),SI-10(6),SI-13,SI-17}	Memory corruption may result from radiation, fault injection, or malicious manipulation. Detection prevents silent data corruption from propagating to mission-critical functions. Recovery mechanisms or safe-state transitions preserve availability. Rapid containment supports mission survivability.
SPR-89	The [spacecraft] shall implement the hardware, firmware, and software anti-tamper mechanisms identified in the Anti-Tamper Plan.{SV-SP-5,SV-SP-4}{SR-9(1),SR-10}	Anti-tamper mechanisms deter reverse engineering, unauthorized modification, and physical compromise. Integrated hardware, firmware, and software protections raise adversary cost. Defined Anti-Tamper Plans ensure consistent implementation across lifecycle phases. Protection must address both physical and cyber attack 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-94	The [spacecraft] shall provide the capability for data connection ports or input/output devices to be disabled or removed prior to spacecraft operations.{SV-AC-5}{SA-9(2),SC-7(14),SC-41,SC-51}	Intent is for external physical data ports to be disabled (logical or physical) while in operational orbit. Port disablement does not necessarily need to be irreversible.
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-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-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-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-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-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-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-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-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-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-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-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-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-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-324	The [organization] shall inspect system components periodically during development to detect tampering (in accordance with the Anti-Tamper Plan).{SV-SP-5,SV-SP-4}{SR-10}	Development environments are prime targets for hardware or firmware manipulation. Regular inspection supports early detection of unauthorized modification. Alignment with the Anti-Tamper Plan ensures structured verification. Early detection prevents compromised components from reaching flight configuration.
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-326	The [organization] shall employ technical means to determine if system components are genuine or have been altered.{SV-SP-5,SV-SP-4}{SR-11(3)}	Organizations may leverage supplier and contractor processes for validating that a system or component is genuine and has not been altered and for replacing a suspect system or component.
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-333	The [organization] shall develop an Anti-Tamper Plan in accordance with DoD directives/instructions on Anti-Tamper guidance for the system, system component, or system service.{SV-SP-5}{SR-9}	Structured anti-tamper planning addresses hardware and firmware manipulation risks. Alignment with DoD guidance ensures consistent implementation. Early planning integrates tamper resistance into design. Proactive measures deter hardware exploitation.
SPR-334	The [organization] shall coordinate the Anti-Tamper Plan with the appropriate organizational entities to ensure correct implementation of tamper protection mechanisms throughout the system lifecycle.{SV-SP-5}{SR-9,SR-9(1)}	Effective anti-tamper requires cross-functional coordination. Alignment prevents gaps between design, manufacturing, and integration. Lifecycle oversight ensures sustained protection. Coordination strengthens enforcement consistency.
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-446	The [organization] shall enable integrity verification of hardware components.{SV-SP-5,SV-SP-4}{SA-10(3),SA-8(21),SA-10(3),SC-51}	* 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-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-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-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-510	The [organization] integrator shall perform anti-counterfeit scanning at: (1) incoming receipt, (2) pre-integration, and (3) pre-flight (or pre-stow); retain imagery and traces as ATO evidence.{SV-SP-5}{SR-11(3)}	Scanning at receipt, pre-integration, and pre-flight minimizes insertion windows. Retained imagery supports ATO evidence and forensic traceability. Multi-stage validation reduces counterfeit dwell time. Layered inspection strengthens assurance.
SPR-511	The [organization] shall quarantine anti-counterfeit anomalies, block integration until disposition, open an incident record, notify SCRM lead/AO, and require supplier corrective action/lot containment as applicable.{SV-SP-4,SV-MA-5}{SR-11(3),IR-6}	Immediate quarantine prevents contaminated integration. Formal incident tracking ensures accountability. Supplier corrective actions reduce recurrence risk. Structured containment strengthens resilience.
SPR-512	The [organization] shall maintain calibration of anti-counterfeit scanning tools and competency records for operators; calibration certs and training logs become part of the compliance package.{SV-SP-5}{SR-11(3)}	Tool calibration ensures detection reliability. Competency tracking strengthens operator assurance. Compliance documentation supports audit readiness. Precision supports integrity validation.
SPR-516	The [organization] shall define,and the [spacecraft] shall enforce,guardrails for any unauthenticated discovery beacons (if used), limiting content to non‑sensitive signals that cannot enable timing/key inference, preventing state change via those paths, narrowing content in safe mode, and validating behavior in simulators/flatsats.{SV-CF-2,SV-IT-1}{AC-4,AC-14}	Discovery mechanisms can leak sensitive timing or state information. Guardrails restrict beacon content to non-sensitive data. Controlled discovery reduces inference risk.
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-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-539	The [spacecraft] shall ensure security‑critical functions (command authentication, key handling, secure boot) share minimal infrastructure with noncritical services by using separate processing domains or buses where feasible and strict message filtering across boundaries.{SV-MA-7,SV-SP-9}{SC-3,,AC-4,SA-8(11)}	Isolation reduces compromise propagation. Minimal shared infrastructure limits attack surface. Strict message filtering enforces boundaries. Architectural separation strengthens resilience.
SPR-541	The [spacecraft] shall provide a trusted path for sensitive actions (e.g., key management, image activation) with strengthened authentication/integrity checks, narrow interfaces, and explicit telemetry cues (trusted‑path active, preconditions satisfied); operations shall confirm trusted‑path use before proceeding.{SV-AC-1,SV-SP-9}{SA-8(13),SC-11,SC-12}	Narrow interfaces reduce attack vectors. Explicit trusted-path indicators prevent misuse. Strengthened authentication protects critical operations. Procedural confirmation ensures compliance.

Tamper Protection

Sources

Pre-Operations Government

Pre-Operations Developer/Supplier

Sustainment & Maintenance Government

Sustainment & Maintenance Developer/Supplier

NIST Rev5 Controls

D3FEND Techniques

D3FEND Artifacts

ISO 27001

NASA Best Practice Guide

ESA Space Shield Mitigation

Related MITRE EMB3D Mitigations

Related CSF 2.0

Related BSI Security Measures

Techniques Addressed by Countermeasure

Space Threats Addressed by Countermeasure

Sample Requirements