SPARTA requirements translate space-specific adversary Tactics, Techniques, and Procedures (TTPs) into engineering-grade requirements suitable for space vehicles (SV), acquisition, and mission assurance. Developed from space-specific threat analysis, security engineering principles, and established best practices, these requirements are mapped to NIST SP 800-53 Rev. 5 controls to demonstrate alignment with current federal control language while preserving traceability from adversary behavior to system design outcomes. Each requirement is categorized as technical or procedural using formal requirements engineering principles consistent with INCOSE, NASA, and U.S. Space Force guidance, ensuring clear “shall” language, unambiguous intent, and conceptual verifiability.
Technical requirements define verifiable SV or software behavior, while procedural requirements define governance, processes, documentation, or programmatic controls necessary to sustain mission security. Technical subcategories include Technical Requirements, which are product-focused “shall” statements expressing a necessary and testable outcome; Design Constraints, which intentionally restrict implementation choices such as specific algorithms or mechanisms; Test Requirements / Validation Criteria, which define acceptance conditions or verification methods; and ICD / Standard Content, which captures interface or protocol detail intended for formal standards or interface control documents rather than enterprise-level requirements.
Procedural subcategories include Policy / Governance, defining enterprise authority or oversight; Process / Procedure, describing required team activities; Documentation Requirements, mandating specific artifacts or plans; Standards / ICD Development, directing the development or maintenance of formal standards; and Concept of Operations (ConOps) content, which describes operational usage and is intentionally separated from product behavior requirements.
Unlike generic IT security controls, SPARTA Requirements are tailored for deterministic, resource-constrained, safety-critical space systems. They support threat-informed engineering, acquisition-ready contract language, control tailoring, and continuous monitoring by explicitly linking SV behavior and governance controls to adversary techniques. The table below provides the full set of requirements, including traceability to NIST Rev. 5 controls, enabling filtering, allocation, and integration into program baselines and verification plans.
Click here to download all SPARTA Requirements
| SPARTA ID | Top Category | Subcategory | Requirement | Notes | NIST 800-53 Rev 5 Controls |
|---|---|---|---|---|---|
| SPR-1 | Technical | Technical Requirement | 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. | 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. | AC-25 |
| SPR-2 | Technical | Design Constraint | The [spacecraft] shall ensure that sensitive information can only be accessed by personnel with appropriate roles and an explicit need for such information to perform their duties. | Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations. | AC-3(11) CM-12 |
| SPR-3 | Technical | Technical Requirement | 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. | 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. | 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) |
| SPR-4 | Technical | Design Constraint | The [spacecraft] security implementation shall ensure that information should not be allowed to flow between partitioned applications unless explicitly permitted by the system. | 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. | 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 |
| SPR-5 | Procedural | Policy / Governance | The [organization] shall state that information should not be allowed to flow between partitioned applications unless explicitly permitted by the Program's security policy. | Technical enforcement must be anchored in formal policy to ensure consistency across development, integration, and operations. Codifying partition isolation requirements prevents mission creep and ad hoc exceptions that weaken domain separation. This establishes traceability between architecture design and security governance. It also ensures subcontractors and integrators apply consistent constraints. | AC-4 AC-4(6) |
| SPR-6 | Technical | Design Constraint | The [spacecraft] shall utilize automated mechanisms to protect sensitive information and detect and alert when sensitive information is accessed without satisfying defined criteria. | Manual monitoring is insufficient in time-sensitive, communication-limited spacecraft environments. Automated detection of unauthorized access enables rapid identification of insider misuse, malicious code execution, or policy violations. This supports onboard intrusion detection and timely ground awareness. The mechanism should differentiate anomaly from normal operational variance. | CM-12(1) |
| SPR-7 | Procedural | Documentation Requirement | 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]. | 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. | 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) |
| SPR-8 | Procedural | Process / Procedure | The [organization] shall ensure that the allocated security safeguards operate in a coordinated and mutually reinforcing manner. | 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. | CA-7(5) PL-7 PL-8(1) SA-8(19) |
| SPR-9 | Procedural | Process / Procedure | 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. | 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. | 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) |
| SPR-10 | Technical | Technical Requirement | The [spacecraft] shall protect authenticator content from unauthorized disclosure and modification. | 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. | AC-17(6) CM-3(6) IA-5 IA-5(6) RA-5(4) SA-8(18) SA-8(19) SC-28(3) |
| SPR-11 | Technical | Technical Requirement | The [spacecraft] encryption key handling shall be handled outside of the onboard software and protected using cryptography. | 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. | AC-17(6) CM-3(6) SA-8(19) SA-9(6) SC-8(1) SC-12 SC-28(1) SC-28(3) |
| SPR-12 | Technical | Technical Requirement | The [spacecraft] encryption keys shall be restricted so that the onboard software is not able to access the information for key readout. | 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. | AC-17(6) CM-3(6) SA-8(19) SA-9(6) SC-8(1) SC-12 SC-28(3) |
| SPR-13 | Technical | Design Constraint | The [spacecraft] encryption keys shall be restricted so that they cannot be read via any telecommands. | 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. | AC-17(6) CM-3(6) SA-8(19) SA-9(6) SC-8(1) SC-12 SC-28(3) |
| SPR-14 | Technical | Technical Requirement | The [spacecraft] shall authenticate the ground station (and all commands) and other spacecraft before establishing remote connections using bidirectional authentication that is cryptographically based. | 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. | 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) |
| SPR-15 | Technical | Technical Requirement | 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. | 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. | 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) |
| SPR-16 | Technical | Design Constraint | 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. | 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. | AC-3 PM-32 SA-8(2) SA-8(5) SA-8(6) SA-8(19) SC-4 SI-3 |
| SPR-17 | Technical | Technical Requirement | The [spacecraft] shall protect the confidentiality and integrity of all information at rest using cryptography. | * The intent as written is for all transmitted traffic to be protected. This includes internal to internal communications and especially outside of the boundary. | AC-3 SA-8(19) SC-28 SC-28(1) SI-7(6) |
| SPR-18 | Technical | Interface Control (ICD) / Standard | 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. | * 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. | AC-3 SA-8(19) SC-8 SC-8(1) SC-8(2) SC-16 SC-16(1) SC-40 |
| SPR-19 | Technical | Technical Requirement | The [spacecraft] shall encrypt all telemetry on downlink regardless of operating mode to protect current state of spacecraft. | 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. | AC-3(10) RA-5(4) SA-8(18) SA-8(19) SC-8 SC-8(1) SC-13 |
| SPR-20 | Technical | Technical Requirement | 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. | 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. | AC-3(10) SA-8(18) SA-8(19) SC-16(2) SC-16(3) SC-40 SC-40(4) |
| SPR-21 | Technical | Technical Requirement | 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. | 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. | AC-3(3) AC-3(4) AC-4(14) IA-9 SA-8(19) SC-16 SI-10 |
| SPR-22 | Technical | Technical Requirement | The [spacecraft] shall implement boundary protections to separate bus, communications, and payload components supporting their respective functions. | 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. | 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) |
| SPR-23 | Technical | Design Constraint | The [spacecraft] shall isolate mission critical functionality from non-mission critical functionality. | 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. | 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) |
| SPR-24 | Technical | Technical Requirement | The [spacecraft] data within partitioned applications shall not be read or modified by other applications/partitions. | 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. | AC-3(3) AC-3(4) SA-8(19) SC-2(2) SC-4 SC-6 SC-32 |
| SPR-25 | Technical | Design Constraint | 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. | 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. | 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 |
| SPR-26 | Technical | Design Constraint | 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. | 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. | AC-4(2) IA-9 SA-8(19) SC-8(1) SC-16(3) |
| SPR-27 | Technical | Technical Requirement | The [spacecraft] shall define the security functions and security-relevant information for which the system must protect from unauthorized access. | 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. | AC-6(1) SA-8(19) SC-7(13) SC-16 |
| SPR-28 | Deprecated | Deprecated | 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. | 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. | 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 |
| SPR-29 | Deprecated | Deprecated | 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 | Deprecated | Deprecated | The [spacecraft] shall fail to a known secure state for failures during initialization, and aborts preserving information necessary to return to operations in failure. | CP-10(6) CP-13 SA-8(16) SA-8(19) SA-8(24) SC-24 SI-13 SI-17 | |
| SPR-31 | Technical | Technical Requirement | 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). | 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. | CP-13 SA-8(19) SA-8(24) SC-7(18) SI-13 SI-13(4) |
| SPR-32 | Deprecated | Deprecated | The [spacecraft] shall provide or support the capability for recovery and reconstitution to a known state after a disruption, compromise, or failure. | 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 | Technical | Design Constraint | 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. | 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). | 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) |
| SPR-34 | Deprecated | Deprecated | 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 | Deprecated | Deprecated | 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 | Technical | Technical Requirement | The [spacecraft] shall operate securely in off-nominal power conditions, including loss of power and spurious power transients. | 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. | PE-11 PE-11(1) SA-8(16) SA-8(19) SI-13 SI-17 |
| SPR-37 | Technical | Interface Control (ICD) / Standard | 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. | 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. | PE-14 PE-19 PE-19(1) RA-5(4) SA-8(18) SA-8(19) SC-8(1) |
| SPR-38 | Technical | Technical Requirement | The [spacecraft] shall be designed so that it protects itself from information leakage due to electromagnetic signals emanations. | 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. | PE-19 PE-19(1) RA-5(4) SA-8(19) |
| SPR-39 | Technical | Design Constraint | The [spacecraft] shall prevent unauthorized and unintended information transfer via shared system resources. | 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. | PM-32 SA-8(2) SA-8(5) SA-8(6) SA-8(19) SC-2(2) SC-4 |
| SPR-40 | Technical | Design Constraint | The [spacecraft] shall only use communication protocols that support encryption within the mission. | 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. | SA-4(9) SA-8(18) SA-8(19) SC-40(4) |
| SPR-41 | Technical | Design Constraint | The [spacecraft] shall maintain a separate execution domain for each executing process. | 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. | SA-8(14) SA-8(19) SC-2(2) SC-7(21) SC-39 SI-3 |
| SPR-42 | Technical | Technical Requirement | The [spacecraft] flight software shall not be able to tamper with the security policy or its enforcement mechanisms. | 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. | SA-8(16) SA-8(19) SC-3 SC-7(13) |
| SPR-43 | Deprecated | Deprecated | The [spacecraft] shall initialize the platform to a known safe state. | SA-8(19) SA-8(23) SA-8(24) SI-17 | |
| SPR-44 | Technical | Interface Control (ICD) / Standard | The [spacecraft] shall maintain the confidentiality and integrity of information during preparation for transmission and during reception in accordance with [organization] provided encryption matrix. | * 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. | SA-8(19) SC-8 SC-8(1) SC-8(2) SC-8(3) |
| SPR-45 | Technical | Technical Requirement | 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. | 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. | SA-8(19) SC-8(1) SC-40 SC-40(1) |
| SPR-46 | Technical | Technical Requirement | The [spacecraft] shall monitor [Program‑defined telemetry points] for malicious commanding attempts and alert ground operators upon detection. | Telemetry-based detection enables identification of anomalous command patterns, replay attempts, and injection attacks. Early detection allows rapid containment before mission impact escalates. Onboard monitoring is critical when ground latency limits intervention. This supports proactive defense. | AC-17 AC-17(1) AC-17(10) AU-3(1) RA-10 SC-7 SC-16 SC-16(2) SC-16(3) SI-3(8) SI-4 SI-4(1) SI-4(13) SI-4(24) SI-4(25) SI-10(6) |
| SPR-47 | Technical | Technical Requirement | The [spacecraft] shall implement relay and replay-resistant authentication mechanisms for establishing a remote connection. | Replay attacks can reuse valid command packets to manipulate spacecraft behavior. Freshness checks, nonces, and sequence enforcement prevent reuse of captured transmissions. Relay resistance mitigates man-in-the-middle exploitation. This protects command integrity over RF links. | AC-3 IA-2(8) IA-2(9) SA-8(18) SC-8(1) SC-16(1) SC-16(2) SC-23(3) SC-40(4) |
| SPR-48 | Technical | Technical Requirement | The [spacecraft] shall implement cryptographic mechanisms to protect the integrity of audit information and audit tools. | Audit logs are essential for attribution and forensic analysis. If adversaries can modify audit data, detection and recovery become unreliable. Cryptographic integrity protections preserve evidentiary value. | AU-9(3) RA-10 SC-8(1) SI-3 SI-3(10) SI-4(24) |
| SPR-49 | Deprecated | Deprecated | The [spacecraft] shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with CNSSP 12 and applicable federal laws, Executive Orders, directives, policies, regulations, and standards. | IA-7 SC-8(1) SC-13 SI-12 | |
| SPR-50 | Technical | Technical Requirement | The [spacecraft] shall implement cryptographic mechanisms to protect the confidentiality and integrity of information during transmission unless otherwise protected by approved physical safeguards. | Unprotected transmission exposes telemetry, commands, and state information to interception or manipulation. Cryptographic protections ensure authenticity and confidentiality across all communication paths. Physical safeguards alone are insufficient in contested environments. | SC-8 SC-8(1) SC-8(4) SI-7(6) |
| SPR-51 | Technical | Technical Requirement | The [spacecraft] shall implement cryptographic mechanisms to protect message externals unless otherwise protected by alternative physical safeguards. | Message externals (headers, routing data, metadata, protocol identifiers) can reveal operational state, enable traffic analysis, or be manipulated to redirect or replay communications. Cryptographic protection prevents adversaries from exploiting metadata to infer spacecraft posture or inject malicious traffic. Even if payload content is encrypted, unprotected externals can enable protocol exploitation or session hijacking. Physical safeguards alone are insufficient in contested RF environments. | SC-8(3) |
| SPR-52 | Technical | Design Constraint | The [spacecraft] shall limit the generation and storage of sensitive/critical mission or system information. Generation shall be done on-demand where possible, and the information shall be deleted immediately when no longer needed. | Reducing the amount and lifetime of sensitive data directly reduces attack surface and exfiltration risk. On-demand generation limits exposure windows and minimizes residual data available for compromise. Immediate deletion prevents recovery via memory scraping, shared resource reuse, or post-compromise forensic harvesting by an adversary. Data minimization is a foundational secure-by-design principle in resource-constrained spacecraft. | SI-21 |
| SPR-53 | Deprecated | Deprecated | 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 | Technical | Technical Requirement | The [spacecraft] shall retain the capability to update/upgrade operating systems while on-orbit. | 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. | SA-4(5) SA-8(8) SA-8(31) SA-10(2) SI-3 |
| SPR-55 | Technical | Technical Requirement | The [spacecraft] shall provide cyber threat status to the ground segment for the Defensive Cyber Operations team, per the governing specification. | The future space enterprises will include full-time Cyber Defense teams supporting space mission systems. Their work is currently focused on the ground segment but may eventually require specific data from the space segment for their successful operation. This requirement is a placeholder to ensure that any DCO-related requirements are taken into consideration for this document. | IR-5 PM-16 PM-16(1) RA-3(3) RA-10 SI-4 SI-4(1) SI-4(24) SI-7(7) |
| SPR-56 | Technical | Technical Requirement | The [spacecraft] shall provide automated onboard mechanisms that integrate audit review, analysis, and reporting processes to support mission processes for investigation and response to suspicious activities to determine the attack class in the event of a cyber attack. | * Identifying the class (e.g., exfiltration, Trojans, etc.), nature, or effect of cyberattack (e.g., exfiltration, subverted control, or mission interruption) is necessary to determine the type of response. The first order of identification may be to determine whether the event is an attack or a non-threat event (anomaly). The objective requirement would be to predict the impact of the detected signature. * Unexpected conditions can include RF lockups, loss of lock, failure to acquire an expected contact and unexpected reports of acquisition, unusual AGC and ACS control excursions, unforeseen actuator enabling's or actions, thermal stresses, power aberrations, failure to authenticate, software or counter resets, etc. Mitigation might include additional TMONs, more detailed AGC and PLL thresholds to alert operators, auto-capturing state snapshot images in memory when unexpected conditions occur, signal spectra measurements, and expanded default diagnostic telemetry modes to help in identifying and resolving anomalous conditions. | AU-6(1) IR-4 IR-4(1) IR-4(12) IR-4(13) PM-16(1) RA-10 SA-8(21) SA-8(22) SC-5(3) SI-3 SI-3(10) SI-4(7) SI-4(24) SI-7(7) |
| SPR-57 | Technical | Technical Requirement | The [spacecraft] shall monitor and collect all onboard cyber- data (from multiple system components), including identification of potential attacks and information about the attack for subsequent analysis. | The spacecraft will monitor and collect data that provides accountability of activity occurring onboard the spacecraft. Due to resource limitations on the spacecraft, analysis must be performed to determine which data is critical for retention and which can be filtered. Full system coverage of data and actions is desired as an objective; it will likely be impractical due to the resource limitations. “Cyber-relevant data” refers to all data and actions deemed necessary to support accountability and awareness of onboard cyber activities for the mission. This would include data that may indicate abnormal activities, critical configuration parameters, transmissions on onboard networks, command logging, or other such data items. This set of data items should be identified early in the system requirements and design phase. Cyber-relevant data should support the ability to assess whether abnormal events are unintended anomalies or actual cyber threats. Actual cyber threats may rarely or never occur, but non-threat anomalies occur regularly. The ability to filter out cyber threats for non-cyber threats in relevant time would provide a needed capability. Examples could include successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels). | AC-6(9) AC-20 AC-20(1) AU-2 AU-12 IR-4 IR-4(1) RA-10 SI-3 SI-3(10) SI-4 SI-4(1) SI-4(2) SI-4(7) SI-4(24) |
| SPR-58 | Technical | Technical Requirement | The [spacecraft] shall generate cyber related audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, and the outcome of the event. For privileged or hazardous commands, the audit record shall include the approver identifiers and the command identifier. | Detailed audit records are essential for attribution, anomaly detection, and post-incident forensic reconstruction. Capturing what occurred, when, where, and by whom enables rapid differentiation between system fault and adversarial activity. Including approver identifiers for privileged or hazardous commands strengthens accountability and insider threat mitigation. Without complete audit context, recovery and containment decisions may be delayed or misinformed. | AU-3 AU-3(1) AU-12 IR-4 IR-4(1) RA-10 SI-3 SI-3(10) SI-4(7) SI-4(24) |
| SPR-59 | Technical | Design Constraint | The [spacecraft] shall attribute cyber attacks and identify unauthorized use of the platform by downlinking onboard cyber information to the mission ground station within [Program‑defined time ≤ 3 minutes]. | Rapid transmission of cyber-relevant telemetry supports near-real-time ground-based fusion and correlation with enterprise security events. Delayed reporting increases risk of adversary persistence or mission degradation. Early attribution enables containment actions before cascading effects occur. Defined timeliness ensures detection capability aligns with operational tempo. | AU-4(1) IR-4 IR-4(1) IR-4(12) IR-4(13) RA-10 SA-8(22) SI-3 SI-3(10) SI-4 SI-4(5) SI-4(7) SI-4(12) SI-4(24) |
| SPR-60 | Technical | Technical Requirement | The [spacecraft] shall integrate cyber related detection and responses with existing fault management capabilities to ensure tight integration between traditional fault management and cyber intrusion detection and prevention. | The onboard IPS system should be integrated into the existing onboard spacecraft fault management system (FMS) because the FMS has its own fault detection and response system built in. SV corrective behavior is usually limited to automated fault responses and ground commanded recovery actions. Intrusion prevention and response methods will inform resilient cybersecurity design. These methods enable detected threat activity to trigger defensive responses and resilient SV recovery. | AU-6(4) IR-4 IR-4(1) RA-10 SA-8(21) SA-8(26) SC-3(4) SI-3 SI-3(10) SI-4(7) SI-4(13) SI-4(16) SI-4(24) SI-4(25) SI-7(7) SI-13 |
| SPR-61 | Technical | Technical Requirement | The [spacecraft] shall protect information obtained from logging/intrusion-monitoring from unauthorized access, modification, and deletion. | Monitoring data is a high-value target for attackers seeking to evade detection or erase traces of compromise. Protecting log integrity preserves evidentiary value and detection continuity. Unauthorized modification or deletion could mask malicious behavior or delay response. Cryptographic protection and access controls ensure monitoring mechanisms cannot be silently disabled. | AU-9 AU-9(3) RA-10 SI-4(7) SI-4(24) |
| SPR-62 | Technical | Technical Requirement | 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. | 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. | 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 |
| SPR-63 | Technical | Design Constraint | The [spacecraft] shall be able to locate the onboard origin of a cyber attack and alert ground operators within [Program‑defined time ≤ 3 minutes]. | The origin of any attack onboard the vehicle should be identifiable to support mitigation. At the very least, attacks from critical element (safety-critical or higher-attack surface) components should be locatable quickly so that timely action can occur. | IR-4 IR-4(1) IR-4(12) IR-4(13) RA-10 SA-8(22) SI-3 SI-3(10) SI-4 SI-4(1) SI-4(7) SI-4(12) SI-4(16) SI-4(24) |
| SPR-64 | Technical | Technical Requirement | The [spacecraft] shall detect and deny unauthorized outgoing communications posing a threat to the spacecraft. | Outbound communications may indicate data exfiltration, covert channels, or compromised subsystem behavior. Monitoring and blocking unauthorized egress prevents leakage of mission data or cryptographic material. Many attacks rely on command-and-control or data extraction channels; egress control disrupts this persistence mechanism. Outbound traffic should be as tightly controlled as inbound command paths. | IR-4 IR-4(1) RA-5(4) RA-10 SC-7(9) SC-7(10) SI-4 SI-4(1) SI-4(4) SI-4(7) SI-4(11) SI-4(13) SI-4(24) SI-4(25) |
| SPR-65 | Technical | Technical Requirement | The [spacecraft] shall select and execute safe countermeasures against cyber attacks prior to entering cyber-safe mode. | These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker exquisitely—with or without ground aiding. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system." These countermeasures are likely executed prior to entering into a cyber-safe mode. | IR-4 RA-10 SA-8(21) SA-8(24) SI-4(7) SI-17 |
| SPR-66 | Technical | Technical Requirement | The [spacecraft] shall be designed and configured so that encrypted communications traffic and data is visible to on-board security monitoring tools. | Encryption must not blind onboard intrusion detection capabilities. Security tools require access to sufficient context (pre-encryption or post-decryption inspection points) to detect malicious patterns. Without visibility, encrypted channels become covert channels. Proper architectural placement ensures both confidentiality and detectability are preserved. | RA-10 SA-8(21) SI-3 SI-3(10) SI-4 SI-4(1) SI-4(10) SI-4(13) SI-4(24) SI-4(25) |
| SPR-67 | Technical | Technical Requirement | The [spacecraft] shall be designed and configured so that spacecraft memory can be monitored by the on-board intrusion detection/prevention capability. | Many spacecraft attacks target memory corruption, firmware modification, or unauthorized process injection. Monitoring memory state enables detection of tampering, abnormal writes, or execution anomalies. Memory visibility supports early detection of wiper malware or boot-level compromise. This is essential for protecting deterministic flight software environments. | RA-10 SA-8(21) SI-3 SI-3(10) SI-4 SI-4(1) SI-4(24) SI-16 |
| SPR-68 | Technical | Technical Requirement | The [spacecraft] shall have on-board intrusion detection/prevention system that monitors the mission critical components or systems. | The mission critical components or systems could be GNC/Attitude Control, C&DH, TT&C, Fault Management. | RA-10 SC-7 SI-3 SI-3(8) SI-4 SI-4(1) SI-4(7) SI-4(13) SI-4(24) SI-4(25) SI-10(6) |
| SPR-69 | Technical | Technical Requirement | The [spacecraft] shall alert in the event of the audit/logging processing failures. | Failure of logging mechanisms may signal active tampering or resource exhaustion attacks. Immediate alerting ensures loss of visibility does not go unnoticed. Silent failure of audit systems creates blind spots exploitable by adversaries. Monitoring the monitors is critical to resilient detection. | AU-5 AU-5(1) AU-5(2) SI-3 SI-4 SI-4(1) SI-4(7) SI-4(12) SI-4(24) |
| SPR-70 | Technical | Technical Requirement | The [spacecraft] shall provide an alert immediately to [at a minimum the mission director, administrators, and security officers] when the following failure events occur: [minimally but not limited to: auditing software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity reaching 95%, 99%, and 100%] of allocated capacity, including security component failover events; alerts shall include component identity, time, and fault reason. | Intent is to have human on the ground be alerted to failures. This can be decomposed to SV to generate telemetry and to Ground to alert. | AU-5 AU-5(1) AU-5(2) SI-4 SI-4(1) SI-4(7) SI-4(12) SI-4(24) SI-7(7) |
| SPR-71 | Technical | Technical Requirement | The [spacecraft] shall provide the capability of a cyber “black-box” to capture necessary data for cyber forensics of threat signatures and anomaly resolution when cyber attacks are detected. The [spacecraft] shall automatically route audit events to the alternate audit logging capability upon primary audit failure and shall resynchronize the alternate store to the primary upon recovery. | Similar concept of a "black box" on an aircraft where all critical information is stored for post forensic analysis. Black box can be used to record CPU utilization, GNC physical parameters, audit records, memory contents, TT&C data points, etc. The timeframe is dependent upon implementation but needs to meet the intent of the requirement. For example, 30 days may suffice. | AU-5(5) AU-9(2) AU-9(3) AU-12 IR-4(12) IR-4(13) IR-5(1) SI-3 SI-3(10) SI-4 SI-4(1) SI-4(7) SI-4(24) SI-7(7) |
| SPR-72 | Technical | Technical Requirement | The [spacecraft] shall automatically notify ground operators when onboard integrity verification detects discrepancies. | Integrity check failures may indicate unauthorized modification, corruption, or hardware faults induced by malicious activity. Automatic notification ensures ground teams can rapidly assess risk and initiate recovery procedures. Delay in reporting increases mission impact. Transparency between onboard detection and ground response is essential for coordinated defense. | CM-3(5) SA-8(21) SI-3 SI-4(7) SI-4(12) SI-4(24) SI-7(2) SI-7(12) |
| SPR-73 | Technical | Technical Requirement | The [spacecraft], upon detection of a potential integrity violation, shall provide the capability to [audit the event and alert ground operators]. | One example would be for bad commands where the system would reject the command and not increment the Vehicle Command Counter (VCC) and include the information in telemetry. | CM-3(5) SA-8(21) SI-3 SI-4(7) SI-4(12) SI-4(24) SI-7(8) |
| SPR-74 | Procedural | Process / Procedure | The [organization] shall define the security safeguards that are to be automatically employed when integrity violations are discovered. | Predefined safeguards ensure consistent and timely response to detected integrity violations. Ad hoc response increases uncertainty and recovery time. Automated actions may include isolation, reconstitution from gold images, or transition to cyber-safe mode. Defined response paths improve resilience and reduce operator burden during crisis. | CP-2 SA-8(21) SI-3 SI-4(7) SI-4(12) SI-7(5) SI-7(8) |
| SPR-75 | Procedural | Standards / ICD Development | 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. | The secure communication protocol should include "strong" authenticated encryption characteristics. | SA-4(9) |
| SPR-76 | Technical | Design Constraint | The [spacecraft] shall only use [organization]-defined communication protocols within the mission. | 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. | SA-4(9) |
| SPR-77 | Technical | Interface Control (ICD) / Standard | The [spacecraft] shall employ the principle of least privilege, allowing only authorized accesses processes which are necessary to accomplish assigned tasks in accordance with system functions. | Least privilege limits damage from compromised processes or insider misuse. Processes receive only the minimum access necessary for assigned functions. This reduces lateral movement and privilege escalation pathways. In deterministic spacecraft systems, privilege boundaries must be tightly defined and enforced. | AC-3 AC-6 AC-6(9) CA-9 CM-5 CM-5(5) CM-5(6) SA-8(2) SA-8(5) SA-8(6) SA-8(14) SA-8(23) SA-17(7) SC-2 SC-7(29) SC-32 SC-32(1) SI-3 |
| SPR-78 | Technical | Technical Requirement | The [spacecraft] shall provide independent mission/cyber critical threads such that any one credible event will not corrupt another mission/cyber critical thread. | Segregating mission-critical and cyber-critical execution paths prevents a single failure or compromise from corrupting other critical functions. Thread independence supports fault containment and resilience under attack. This ensures availability of essential functions even during partial compromise. Isolation strengthens both safety and cybersecurity. | SC-3 SC-32 SC-32(1) SI-3 SI-13 |
| SPR-79 | Technical | Technical Requirement | The [spacecraft] and all ground support systems (including those during development) shall be capable of detecting unauthorized hardware components/connections. | 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. | CM-7(9) |
| SPR-80 | Technical | Technical Requirement | The [spacecraft] shall execute procedures for ensuring that security-relevant hardware, software, and firmware updates uploaded are exactly as specified by the gold copies. | 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. | 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) |
| SPR-81 | Technical | Technical Requirement | The [spacecraft] shall perform an integrity check of software, firmware, and information at startup or during security- events. | 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. | 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) |
| SPR-82 | Technical | Technical Requirement | The [spacecraft] boot firmware shall validate the boot loader, boot configuration file, and operating system image, in that order, against their respective signatures. | A signature is ~770 bits long. No requirement is imposed on the storage location of signatures. | SA-8(10) SA-8(11) SA-8(12) SI-7(9) SI-7(10) |
| SPR-83 | Technical | Technical Requirement | 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. | 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. | SA-8(10) SA-8(11) SA-8(12) SI-7(9) SI-7(10) |
| SPR-84 | Technical | Technical Requirement | The [spacecraft] trusted boot/RoT computing module shall be implemented on radiation tolerant burn-in (non-programmable) equipment. | 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. | SA-8(10) SA-8(11) SA-8(12) SI-7(9) SI-7(10) |
| SPR-85 | Technical | Technical Requirement | The [spacecraft] trusted boot/RoT shall be a separate compute engine controlling the trusted computing platform cryptographic processor. | 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. | SA-8(10) SA-8(11) SA-8(12) SI-7(9) SI-7(10) |
| SPR-86 | Technical | Technical Requirement | The [spacecraft] shall perform attestation at each stage of startup and ensure overall trusted boot regime (i.e., root of trust). | 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 | SA-8(10) SA-8(11) SA-8(12) SI-7(9) SI-7(10) SI-7(17) |
| SPR-87 | Technical | Technical Requirement | The [spacecraft] shall be configured to provide only essential capabilities. | 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. | CM-6 CM-7 SA-8(2) SA-8(7) SA-8(13) SA-8(23) SA-8(26) SA-15(5) |
| SPR-88 | Technical | Technical Requirement | The [spacecraft] shall detect and recover from detected memory errors or transitions to a known cyber-safe state. | 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. | IR-4 IR-4(1) SA-8(16) SA-8(24) SI-3 SI-4(7) SI-10(6) SI-13 SI-17 |
| SPR-89 | Technical | Technical Requirement | The [spacecraft] shall implement the hardware, firmware, and software anti-tamper mechanisms identified in the Anti-Tamper Plan. | 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. | SR-9(1) SR-10 |
| SPR-90 | Technical | Technical Requirement | 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. | 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. | SA-8(21) SI-7(1) SI-7(10) SR-4(4) |
| SPR-91 | Technical | Technical Requirement | The [spacecraft] shall prevent the installation of Flight Software without verification that the component has been digitally signed. | 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. | 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) |
| SPR-92 | Technical | Technical Requirement | The [spacecraft] shall verify the correct operation of security- software and hardware mechanisms. | Security controls that fail silently create false confidence and blind spots. Continuous or periodic verification ensures cryptographic modules, access controls, logging mechanisms, and monitoring functions remain operational. Attackers often attempt to disable protections prior to executing malicious actions. Independent health checks preserve detection and enforcement reliability. | SA-8(21) SI-3 SI-6 |
| SPR-93 | Technical | Technical Requirement | 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. | 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). | 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) |
| SPR-94 | Technical | Technical Requirement | The [spacecraft] shall provide the capability for data connection ports or input/output devices to be disabled or removed prior to spacecraft operations. | 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. | SA-9(2) SC-7(14) SC-41 SC-51 |
| SPR-95 | Technical | Technical Requirement | The [spacecraft] shall enforce an attribute-based access control policy over subjects and objects as defined in AC-3(3). | Attribute-based access control (ABAC) enables dynamic, context-aware enforcement beyond static role assignments. This reduces privilege abuse and insider misuse by incorporating mission state, location, and environmental factors into decisions. ABAC supports least privilege while enabling operational flexibility. Proper enforcement limits lateral movement and unauthorized data access. | AC-3(13) |
| SPR-96 | Deprecated | Deprecated | The [spacecraft] shall uniquely identify and authenticate the ground station and other spacecraft before establishing a remote connection. | AC-3 AC-17 AC-17(10) AC-20 IA-3 IA-4 SA-8(18) SI-3(9) | |
| SPR-97 | Technical | Technical Requirement | All [spacecraft] commands which have unrecoverable consequence must have dual authentication prior to command execution. The [spacecraft] shall verify two independent cryptographic approvals prior to execution and shall generate an audit record binding both approver identifiers to the command identifier, time, and outcome. | Commands with irreversible impact require heightened assurance to prevent catastrophic mission loss. Dual independent cryptographic approvals mitigate insider threat, key compromise, and single-point credential abuse. Binding approver identifiers to the audit trail strengthens accountability and deterrence. This reduces the probability of unauthorized hazardous command execution. | AU-9(5) IA-3 IA-4 IA-10 PE-3 PM-12 SA-8(15) SA-8(21) SC-16(2) SC-16(3) SI-3(8) SI-3(9) SI-4(13) SI-4(25) SI-7(12) SI-10(6) SI-13 |
| SPR-98 | Technical | Technical Requirement | The [spacecraft] shall have a method to ensure the integrity of which have unrecoverable consequence and validate their authenticity before execution. | Hazardous commands must be cryptographically protected and validated prior to execution. Integrity and authenticity checks prevent replay, modification, or injection of destructive instructions. Without validation, RF interception or command path compromise could result in mission-ending actions. This ensures critical commands are both authorized and unaltered. | AU-9(5) IA-3 IA-4 IA-10 PE-3 PM-12 SA-8(15) SA-8(21) SC-16(2) SC-16(3) SI-3(8) SI-3(9) SI-4(13) SI-4(25) SI-7(12) SI-10(6) SI-13 |
| SPR-99 | Deprecated | Deprecated | The [spacecraft] shall recover from cyber-safe mode to mission operations within 20 minutes. | Upon conclusion of addressing the threat, the system should be capable of recovering from the minimal survival mode back into a mission-ready state within defined timelines. The intent is to define the timelines and the capability to return back to mission operations. | CP-2(3) CP-2(5) IR-4 SA-8(24) |
| SPR-100 | Deprecated | Deprecated | The [spacecraft] shall monitor [Program defined telemetry points] for malicious commanding attempts. | Source from AEROSPACE REPORT NO. TOR-2019-02178 Vehicle Command Counter (VCC) - Counts received valid commands Rejected Command Counter - Counts received invalid commands Command Receiver On/Off Mode - Indicates times command receiver is accepting commands Command Receivers Received Signal Strength - Analog measure of the amount of received RF energy at the receive frequency Command Receiver Lock Modes - Indicates when command receiver has achieved lock on command signal Telemetry Downlink Modes - Indicates when the satellite’s telemetry was transmitting Cryptographic Modes - Indicates the operating modes of the various encrypted links Received Commands - Log of all commands received and executed by the satellite System Clock - Master onboard clock GPS Ephemeris - Indicates satellite location derived from GPS Signals | SC-7 AU-3(1) AC-17(1) |
| SPR-101 | Deprecated | Deprecated | The [spacecraft] shall require multi-factor authorization for all updates to the task scheduling functionality within the spacecraft. | 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). | AC-3(2) |
| SPR-102 | Deprecated | Deprecated | The [spacecraft] shall require multi-factor authorization for new and updates to on-board stored command sequences. | 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). | AC-3(2) |
| SPR-103 | Technical | Technical Requirement | The [spacecraft] software subsystems shall provide non-identical methods, or functionally independent methods, for commanding a mission critical function when the software is the sole control of that function. | When software is sole controller of a critical function, redundant and functionally independent command paths reduce systemic risk. A single vulnerability should not allow full compromise of a hazardous control. Diverse mechanisms increase resilience against common-mode failures. This supports both safety and cybersecurity assurance. | AC-3(2) |
| SPR-104 | Technical | Technical Requirement | The [spacecraft] software subsystems shall provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard. | Disabling fault tolerance creates a high-risk operational state. Requiring two independent and unique commands reduces likelihood of accidental or malicious deactivation. This prevents a single compromised control path from undermining redundancy. Hazard mitigation systems must not be easily bypassed. | AC-3(2) |
| SPR-105 | Deprecated | Deprecated | The [spacecraft] shall provide two independent and unique command messages to deactivate a fault tolerant capability for a critical or catastrophic hazard. | AC-3(2) PE-10 SA-8(15) | |
| SPR-106 | Deprecated | Deprecated | The [spacecraft] shall provide non-identical methods, or functionally independent methods, for commanding a mission critical function when the software is the sole control of that function. | AC-3(2) SI-3(8) SI-13 | |
| SPR-107 | Technical | Technical Requirement | The [spacecraft] shall have multiple uplink paths | Redundant uplink paths preserve command capability during jamming, interference, or subsystem failure. Availability is a core mission assurance objective. Diverse communication channels reduce single-point failure risk. This enhances resiliency in contested RF environments. | CP-8 CP-11 SA-8(18) SC-5 SC-47 |
| SPR-108 | Procedural | Process / Procedure | The [organization] shall define the resources to be allocated to protect the availability of system resources. | Availability protections require deliberate allocation of compute, power, bandwidth, and monitoring capacity. Without predefined resource allocation, defensive measures may compete with mission operations. Planning ensures resilience mechanisms do not degrade core functionality. This supports continuity during denial-of-service conditions. | CP-2(2) SC-6 |
| SPR-109 | Technical | Technical Requirement | The [spacecraft] shall be constructed with electromagnetic shielding to protect electronic components from damage to the degree deemed acceptable. Verification for EMP/HANE shall be distinct from EMSEC/TEMPEST, anti‑jam/anti‑spoof, and EMI/EPM protections. | EMP and HANE events can induce systemic failures independent of cyber exploitation. Shielding protects electronics from catastrophic damage and fault-induced vulnerabilities. Distinguishing EMP/HANE from EMSEC and anti-jam ensures correct threat modeling and verification. Physical resilience complements cyber defenses. | PE-9 PE-14 PE-18 PE-21 |
| SPR-110 | Technical | Design Constraint | The [spacecraft] shall be able to identify threats within the operational environment and maneuver to avoid physical contact or utilize shielding to mitigate electromagnetic attacks. | Spacecraft must assess proximity threats and electromagnetic hazards within operational context. Maneuvering or shielding reduces exposure to physical tampering or hostile emitters. Active threat avoidance strengthens survivability. Environmental awareness enhances resilience beyond passive protection. | PE-6(2) |
| SPR-111 | Technical | Technical Requirement | The [spacecraft] shall implement concealment techniques to obscure sensitive information (e.g., locations, identifiers, interfaces, binaries) while maintaining the integrity, confidentiality, and availability of the actual information. | Obscuring sensitive identifiers, interfaces, and binaries reduces reconnaissance value to adversaries. Concealment increases attack cost and complexity without degrading mission function. This mitigates reverse engineering and exploitation of known interfaces. Security through obscurity alone is insufficient, but layered concealment enhances defense-in-depth. | SC-30 |
| SPR-112 | Technical | Technical Requirement | The [spacecraft] shall implement concealment and misdirection techniques to obscure the presence and characteristics of specific system components. | Misdirection techniques complicate adversary targeting and reconnaissance. Obscuring component presence or characteristics reduces exploitation efficiency. This may include decoys or deceptive telemetry patterns. Such measures support active defense and uncertainty generation. | SC-30(5) |
| SPR-113 | Technical | Technical Requirement | The [spacecraft] shall implement protections against external and internal communications from jamming attempts; verification for anti‑jam shall be distinct from EMI/EPM, EMP/HANE hardness, and anti‑spoof protections. | Jamming disrupts availability and can mask other malicious activities. Dedicated anti-jam mechanisms preserve command and telemetry continuity. Distinguishing from EMI/EPM and anti-spoof ensures comprehensive RF threat coverage. Availability protections must be validated independently. | SC-5 SC-40 SC-40(1) |
| SPR-114 | Technical | Technical Requirement | The [spacecraft] shall protect external and internal communications from jamming and spoofing attempts; verification for anti‑spoof shall be distinct from EMI/EPM and EMP/HANE hardness. | Can be aided via the Crosslink, S-Band, and L-Band subsystems | SC-5 SC-40 SC-40(1) |
| SPR-115 | Procedural | Process / Procedure | The [organization] shall describe (a) the separation between RED and BLACK cables, (b) the filtering on RED power lines, (c) the grounding criteria for the RED safety grounds, (d) and the approach for dielectric separators on any potential fortuitous conductors, and shall provide quantitative separation distances, filter specifications, grounding resistance criteria, and dielectric separator material properties. | Physical separation of classified (RED) and unclassified (BLACK) signal paths prevents compromising emanations. Defined separation distances, filtering, and grounding reduce leakage risk. Quantitative criteria ensure repeatable and verifiable implementation. This protects against unintended signal coupling and data leakage. | PE-19 PE-19(1) |
| SPR-116 | Technical | Technical Requirement | The [organization] shall ensure reused TT&C software has adequate uniqueness for command decoders/dictionaries so that commands are received by only the intended satellite. | The goal is to eliminate risk that compromise of one command database does not affect a different one due to reuse. The intent is to ensure that one SV can not process the commands from another SV. Given the crypto setup with keys and VCC needing to match, this requirement may be inherently met as a result of using type-1 cryptography. The intent is not to recreate entire command dictionaries but have enough uniqueness in place that it prevents a SV from receiving a rogue command. As long as there is some uniqueness at the receiving end of the commands, that is adequate. | AC-17(10) SC-16(3) SI-3(9) |
| SPR-117 | Technical | Technical Requirement | The [spacecraft] shall provide the capability to restrict command lock based on geographic location of ground stations. | This could be performed using command lockout based upon when the spacecraft is over selected regions. This should be configurable so that when conflicts arise, the Program can update. The goal is so the spacecraft won't accept a command when the spacecraft determines it is in a certain region. | AC-2(11) IA-10 SI-4(13) SI-4(25) |
| SPR-118 | Deprecated | Deprecated | The [spacecraft] shall maintain the ability to encrypt & authenticate communications when conditions require automated access control mechanisms be overridden (e.g.no crypto-bypass mode). | AC-3(10) | |
| SPR-119 | Technical | Interface Control (ICD) / Standard | The [spacecraft] shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards: [NSA- certified or approved cryptography for protection of classified information, FIPS-validated cryptography for the provision of hashing]. | Use of NSA-certified or FIPS-validated cryptography ensures compliance with federal mandates and high-assurance algorithms. Standardized implementations reduce algorithmic weaknesses. Alignment with policy ensures interoperability and trustworthiness. Proper certification mitigates cryptographic implementation flaws. | IA-7 SC-13 |
| SPR-120 | Technical | Technical Requirement | The [spacecraft] shall terminate the connection associated with a communications session at the end of the session or after 3 minutes of inactivity. | Persistent sessions increase exposure to hijacking and replay attacks. Automatic termination limits session lifetime and reduces unauthorized reuse. Idle timeout reduces attack surface in unattended conditions. Explicit closure supports session state integrity. | AC-12 SA-8(18) SC-10 SC-23(1) SC-23(3) SI-14 SI-14(3) |
| SPR-121 | Technical | Design Constraint | The [organiztion] shall maintain the ability to establish communication with the spacecraft in the event of an anomaly to the primary receive path. | Receiver communication can be established after an anomaly with such capabilities as multiple receive apertures, redundant paths within receivers, redundant receivers, omni apertures, fallback default command modes, and lower bit rates for contingency commanding, as examples | CP-8 SA-8(18) SC-47 |
| SPR-122 | Technical | Design Constraint | The [spacecraft] shall produce, control, and distribute symmetric cryptographic keys using NSA Certified or Approved key management technology and processes per CNSSP 12. Private cryptographic keys shall be generated, stored, and rotated under [organization] control only and shall not be exposed to external service providers. | Centralized and approved key management prevents unauthorized key generation or rotation. Protecting private keys from external service providers reduces supply chain risk. Controlled lifecycle management supports confidentiality and integrity. Strong governance reduces key compromise likelihood. | AC-17(6) CM-3(6) SA-9(6) SC-12 SC-12(1) SC-12(2) SC-12(3) |
| SPR-123 | Procedural | Documentation Requirement | The [organization] shall use NIST Approved for symmetric key management for Unclassified systems; NSA Approved or stronger symmetric key management technology for Classified systems. | FIPS-complaint technology used by the Program shall include (but is not limited to) cryptographic key generation algorithms or key distribution techniques that are either a) specified in a FIPS, or b) adopted in a FIPS and specified either in an appendix to the FIPS or in a document referenced by the FIPS. NSA-approved technology used for symmetric key management by the Program shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. | SC-12 SC-12(1) SC-12(2) |
| SPR-124 | Procedural | Process / Procedure | The [organization] shall use NSA approved key management technology and processes.NSA-approved technology used for asymmetric key management by The [organization] shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. | Asymmetric keys underpin authentication and trust chains. Approved algorithms and processes ensure robustness against cryptanalytic attack. Formal evaluation criteria provide confidence in implementation strength. This protects digital signatures and secure exchange mechanisms. | SC-12 SC-12(1) SC-12(3) |
| SPR-125 | Technical | Technical Requirement | The [spacecraft] shall produce, control, and distribute asymmetric cryptographic keys. Private cryptographic keys shall be generated, stored, and rotated under [organization] control only and shall not be exposed to external service providers. | In most cased the Program will leverage NSA-approved key management technology and processes. | SC-12 SC-12(1) SC-12(3) |
| SPR-126 | Deprecated | Deprecated | The [spacecraft] shall protect the confidentiality and integrity of the [all information] using cryptography while it is at rest. | * Information at rest refers to the state of information when it is located on storage devices as specific components of information systems. This is often referred to as data-at-rest encryption. | SC-28 SC-28(1) SI-7(6) |
| SPR-127 | Technical | Technical Requirement | The [spacecraft] shall be configured to deny communications by default and only permit authorized communications based on approved exceptions, establishing a default‑deny baseline with permitted flows whitelisted. | Deny-by-default limits attack surface by permitting only explicitly authorized flows. Whitelisting prevents unexpected communications and covert channels. This reduces exploitation opportunities. Deterministic communication baselines simplify monitoring and anomaly detection. | SC-7(5) AC-4(2) |
| SPR-128 | Technical | Technical Requirement | The [spacecraft] shall accept hazardous commands only when prerequisite checks are satisfied. | Precondition validation ensures hazardous commands are executed only under safe system states. This prevents execution under anomalous or compromised conditions. Independent verification reduces false activation risk. Safety and cyber controls must be integrated. | AC-17(4) SI-10 SI-10(6) |
| SPR-129 | Technical | Design Constraint | The [spacecraft] shall restrict the use of information inputs to spacecraft and designated ground stations as defined in the applicable ICDs. | Limiting inputs to approved spacecraft and ground stations reduces spoofing and injection risk. ICD-defined boundaries prevent rogue sources from influencing control systems. This constrains trust relationships. Controlled input surfaces reduce attack vectors. | AC-20 SC-23 SI-10 SI-10(5) SI-10(6) |
| SPR-130 | Technical | Technical Requirement | The [spacecraft] shall discriminate between valid and invalid input into the software and rejects invalid input. | Input validation prevents buffer overflows, injection, and parser exploitation. Rejecting malformed or unexpected data reduces denial-of-service and corruption risks. Deterministic validation improves resilience. Robust input handling is fundamental to secure software. | SC-16(2) SI-3(8) SI-10 SI-10(3) SI-10(6) |
| SPR-131 | Technical | Technical Requirement | The [spacecraft] shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission. | Command sequencing enforces operational logic and safety interlocks. Out-of-sequence commands may bypass safeguards. Sequence enforcement prevents replay and control manipulation. This preserves control flow integrity. | SC-16(2) SI-4(13) SI-4(25) SI-10 SI-10(6) SI-13 |
| SPR-132 | Deprecated | Deprecated | The [spacecraft] software subsystems shall accept [Program defined hazardous] commands only when prerequisite checks are satisfied. | SI-10 | |
| SPR-133 | Deprecated | Deprecated | The [spacecraft] software subsystems shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission. | SI-10 | |
| SPR-134 | Deprecated | Deprecated | The [spacecraft] software subsystems shall perform prerequisite checks for the execution of hazardous commands. | SI-10 | |
| SPR-135 | Procedural | Process / Procedure | The [organization] shall ensure that all viable commands are known to the mission and SV "owner. | This is a concern for bus re-use. It is possible that the manufacturer left previously coded commands in their syntax rather than starting from a clean slate. This leaves potential backdoors and other functionality the mission does not know about. | SI-10 SI-10(3) |
| SPR-136 | Procedural | Process / Procedure | The [organization] shall perform analysis of critical (backdoor) commands that could adversely affect mission success if used maliciously. | Heritage and commercial products often have many residual operational (e.g., hardware commands) and test capabilities that are unidentified or unknown to the end user, perhaps because they were not expressly stated mission requirements. These would never be tested and their effects unknown, and hence, could be used maliciously. Test commands not needed for flight should be deleted from the flight database. | SI-10 SI-10(3) |
| SPR-137 | Technical | Design Constraint | The [spacecraft] shall only use or include [organization]-defined critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted. | The intent is protect against misuse of critical commands. On potential scenario is where you could use accounts with different privileges, could require an additional passphrase or require entry into a different state or append an additional footer to a critical command. There is room for design flexibility here that can still satisfy this requirement. | SI-10 SI-10(3) |
| SPR-138 | Deprecated | Deprecated | The [spacecraft] software subsystems shall discriminate between valid and invalid input into the software and rejects invalid input. | SI-10 SI-10(3) | |
| SPR-139 | Deprecated | Deprecated | The [spacecraft] software subsystems shall properly handle spurious input and missing data. | SI-10 SI-10(3) | |
| SPR-140 | Technical | Technical Requirement | The [spacecraft] shall properly handle spurious input and missing data. | Spurious or missing data may indicate attack or fault conditions. Robust handling prevents cascading failures. Defensive programming ensures safe defaults and fallback states. This reduces exploitability of abnormal input conditions. | SI-10 SI-10(3) SI-10(6) |
| SPR-141 | Deprecated | Deprecated | The [spacecraft] shall perform prerequisite checks for the execution of hazardous commands. | SI-10 SI-10(6) SI-13 | |
| SPR-142 | Deprecated | Deprecated | The [spacecraft] shall only use or include critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted. | SI-3(8) SI-10 SI-10(3) | |
| SPR-143 | Technical | Technical Requirement | The [spacecraft] software subsystems shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit or perform a hazardous action. | Independent parameter validation ensures command legitimacy from a secondary data source. This reduces risk of single-variable manipulation. Functional independence increases resilience. Hazardous actions require layered confirmation. | SI-10(3) |
| SPR-144 | Technical | Technical Requirement | The [spacecraft] shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit, or perform a hazardous action. | Redundant validation mechanisms ensure hazardous transitions cannot occur through single-point compromise. Independent parameters strengthen control integrity. This reduces exploit paths for inhibit removal. Critical operations demand dual validation logic. | SI-10(3) SI-10(6) SI-13 |
| SPR-145 | Technical | Technical Requirement | The [spacecraft] mission/cyber critical commands shall be "complex" or diverse from other commands so that a single bit flip could not transform a benign command into a hazardous command. | Complex command encoding reduces risk of single-bit errors causing hazardous action. Diversity prevents accidental transformation into destructive instructions. This protects against radiation-induced bit flips and malicious bit manipulation. Safety and cyber resiliency intersect here. | SI-10(5) |
| SPR-146 | Technical | Technical Requirement | The [spacecraft] shall provide at least one independent command for each operator-initiated action used to shutdown a function leading to or reducing the control of a hazard. | Independent shutdown commands ensure operators retain control during anomalous conditions. Redundant control paths reduce systemic failure risk. This supports safe recovery from hazardous states. Separation enhances mission survivability. | SI-10(5) |
| SPR-147 | Deprecated | Deprecated | The [spacecraft] software subsystems shall provide at least one independent command for each operator-initiated action used to shut down a function leading to or reducing the control of a hazard. | SI-10(5) | |
| SPR-148 | Deprecated | Deprecated | The [spacecraft] shall protect the confidentiality and integrity of all transmitted information. | * The intent as written is for all transmitted traffic to be protected. This includes internal to internal communications and especially outside of the boundary. | SC-8 |
| SPR-149 | Technical | Technical Requirement | The [spacecraft] shall perform an integrity check of [Program-defined software, firmware, configuration parameters, and tables] at startup; at [Program-defined transitional states or security-relevant events] and shall verify integrity on receipt and prior to activation of any uploaded package. | Transitional states often introduce vulnerability windows. Integrity checks at these moments detect tampering before activation. Pre-activation validation prevents malicious update deployment. This reinforces chain-of-trust enforcement. | SI-7(1) |
| SPR-150 | Procedural | Process / Procedure | The [organization] shall employ automated tools that provide notification to [Program-defined personnel] upon discovering discrepancies during integrity verification. | Automated alerts ensure discrepancies are not overlooked. Timely notification enables rapid incident response. Automation reduces operator delay. Clear escalation paths strengthen containment. | SI-7(2) |
| SPR-151 | Technical | Technical Requirement | The [spacecraft] shall automatically [Selection (one or more):restarts the FSW/processor, performs side swap, audits failure; implements Program-defined security safeguards] when integrity violations are discovered. | Immediate system response prevents continued exploitation after detection. Restart, side swap, or safeguard activation restores known-good state. Automated actions reduce dwell time. Rapid containment is essential in communication-limited environments. | SI-7(8) |
| SPR-152 | Technical | Design Constraint | The [spacecraft] shall use automated mechanisms to maintain and validate baseline configuration to ensure the [spacecraft] is up-to-date, complete, accurate, and readily available. | This could be command trigger from Ground or elsewhere. The point here is that the self-test is executed onboard the spacecraft via onboard HW/SW self-test mechanisms and its result is reported to the Ground | CM-2(2) CM-3(5) CM-3(7) CM-6 SA-8(8) |
| SPR-153 | Technical | Technical Requirement | The [spacecraft] operating system, if COTS or FOSS, shall be selected from a [organization]-defined acceptance list. | Selecting OS from approved list reduces exposure to unvetted vulnerabilities. Controlled selection supports maintainability and patch governance. This mitigates risk from insecure or unsupported platforms. Trusted baselines simplify compliance verification. | CM-7(8) CM-7(5) |
| SPR-154 | Technical | Technical Requirement | The [spacecraft] shall be capable of removing flight software after updated versions have been installed. | Removing outdated software prevents reactivation of vulnerable versions. This reduces persistence opportunities for adversaries. Maintaining minimal installed versions reduces attack surface. Clean update lifecycle supports system hygiene. | SA-8(8) SI-2(6) |
| SPR-155 | Procedural | Process / Procedure | The [organization] shall ensure that software planned for reuse meets the fit, form, and function, and security as a component within the new application. | Reused components may introduce hidden vulnerabilities. Validation ensures compatibility and security alignment with new mission context. Prior approval does not guarantee safe reuse. Rigorous assessment prevents latent risk inheritance. | CM-7(5) |
| SPR-156 | Technical | Technical Requirement | The [spacecraft] shall enforce access restrictions associated with changes to the spacecraft. | Configuration changes may introduce vulnerabilities. Restricting and auditing change access preserves baseline integrity. Controlled modification reduces insider threat. Change governance supports mission assurance. | CM-5 |
| SPR-157 | Technical | Technical Requirement | The [spacecraft] shall explicitly indicate when a communication session has been terminated. | Clear indication of session termination prevents ambiguity in communication state. This reduces session hijacking risk. Operators must know when secure state has ended. Transparency strengthens trust. | AC-12(2) |
| SPR-158 | Technical | Technical Requirement | The [spacecraft] shall provide a user-initiated (i.e., ground terminal) logout capability for communications sessions. | Manual logout supports explicit session control. This prevents lingering authenticated sessions. User agency reduces misuse risk. Proper session closure mitigates replay attacks. | AC-12(1) |
| SPR-159 | Technical | Technical Requirement | The [spacecraft] shall be capable of distinguishing critical versus non-critical commands. | Critical commands will vary across missions and systems but commonly include commands resulting in maneuvering of the spacecraft or modifying on-board configurations/software. | AC-17(4) |
| SPR-160 | Technical | Technical Requirement | The [spacecraft] shall enforce access controls to restrict and monitor critical commands. | Critical commands will vary across missions and systems but commonly include commands resulting in maneuvering of the spacecraft or modifying on-board configurations/software. | AC-17(4) |
| SPR-161 | Technical | Technical Requirement | The [spacecraft] shall log and monitor critical activities to detect and respond to unauthorized or malicious activities. | Critical commands will vary across missions and systems but commonly include commands resulting in maneuvering of the spacecraft or modifying on-board configurations/software. | AC-6(9) AC-17(4) |
| SPR-162 | Technical | Design Constraint | The [spacecraft] shall use [directional or beamforming] antennas in normal ops to reduce the likelihood that unintended receivers will be able to intercept signals. | Directional transmission reduces unintended signal interception. Lower RF footprint decreases exposure to passive eavesdropping. This complements cryptographic protections. Physical-layer minimization enhances confidentiality. | AC-18(5) |
| SPR-163 | Technical | Design Constraint | The [spacecraft] shall employ monitoring mechanisms to detect and respond to unauthorized or excessive use of external systems, safeguarding the organization's information and ensuring the integrity, confidentiality, and availability of its resources.Monitoring shall be performed on crosslink communications as well as space to ground communications (including direct to user tactical downlinks such as utilized in real-time imagery acquisition). | Monitoring detects anomalous bandwidth use, potential exfiltration, or misuse. Crosslinks are lateral movement pathways between spacecraft. Oversight protects enterprise integrity. Visibility supports coordinated response. | AC-20 AC-20(1) |
| SPR-164 | Technical | Design Constraint | The [spacecraft] shall implement access control mechanisms to ensure that individuals with privileged access only utilize their privileges as necessary to perform their official duties. | Privileged users must operate within defined boundaries. Monitoring and constraint reduce insider misuse. Privilege minimization lowers damage potential. Accountability deters abuse. | AC-6(9) |
| SPR-165 | Technical | Technical Requirement | The [spacecraft] shall generate audit records to capture changes made to audit record generation configurations by authorized users. | Authorized users, including administrators, shall be identified, and the system shall record relevant information such as the user identity, date, time, and nature of changes made to the audit record generation settings. | AU-12(3) |
| SPR-166 | Technical | Technical Requirement | The [spacecraft] shall provide the capability to modify the set of audited events (e.g., cyber-relevant data). | Flexibility allows adaptation to evolving threats. Adjustable audit scope ensures relevant telemetry is captured. This supports threat-driven monitoring strategies. Controlled modification preserves operational balance. | AU-12(3) AU-14 |
| SPR-167 | Technical | Interface Control (ICD) / Standard | The [spacecraft] shall be configured to allocate audit record storage capacity in accordance with 1 week audit record storage requirements. | Defined storage capacity prevents premature log overwriting. Retention ensures forensic reconstruction capability. Adequate capacity supports delayed downlink scenarios. Storage planning enhances accountability. | AU-4 AU-5 AU-5(1) AU-5(2) |
| SPR-168 | Technical | Technical Requirement | The [spacecraft] shall downlink relevant audit log data to ground systems frequently enough to avoid any situation where audit storage capacity is exceeded. | The frequency of offloading this data depends on the amount of data being audited/logged and will vary across missions/systems. | AU-4(1) |
| SPR-169 | Deprecated | Deprecated | The [spacecraft] shall attribute cyberattacks and identify unauthorized use of the spacecraft by downlinking onboard cyber information to the mission ground station within [mission-appropriate timelines minutes]. | Requirement is to support offboard attribution by enabling the fusion of spacecraft cyber data with ground-based cyber data. This would provide end-to-end accountability of commands, data, and other data that can be used to determine the origin of attack from the ground system. Data should be provided within time constraints relevant for the particular mission and its given operational mode. Analysis should be performed to identify the specific timeliness requirements for a mission, which may vary depending on mission mode, operational status, availability of communications resources, and other factors. The specific data required should be identified, as well. | AU-4(1) SI-4(5) |
| SPR-170 | Technical | Technical Requirement | The [spacecraft] shall alert in the event of the [organization]-defined audit/logging processing failures. | Audit failure may indicate tampering or resource exhaustion. Immediate alert prevents silent loss of visibility. Detection continuity is essential for defense. Monitoring integrity must be assured. | AU-5 |
| SPR-171 | Technical | Design Constraint | The [spacecraft] shall routinely report audit log storage utilization along with traditional health and status data during pre-determined passes. | Monitoring storage usage prevents overflow conditions. Predictable reporting supports proactive resource management. Integration with health telemetry ensures visibility. Log retention reliability must be maintained. | AU-5(1) |
| SPR-172 | Technical | Interface Control (ICD) / Standard | The [organization] shall integrate terrestrial system audit log analysis as part of the standard anomaly resolution process to correlate any anomalous behavior in the terrestrial systems that correspond to anomalous behavior in the spacecraft. | Correlation across ground and space segments improves attribution accuracy. End-to-end visibility detects pivoting attacks. Integration strengthens anomaly resolution. Enterprise/Whole mission fusion enhances threat awareness. | AU-6(1) IR-5(1) |
| SPR-173 | Technical | Technical Requirement | The [spacecraft] shall record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT). | Standardized time enables cross-system correlation. Accurate timestamps are critical for forensic analysis. UTC/GMT alignment ensures interoperability. Consistent timekeeping supports coordinated response. | AU-8 |
| SPR-174 | Technical | Technical Requirement | The [spacecraft] shall record time stamps for audit records that provide a granularity of one Z-count (1.5 sec). | Fine granularity improves event reconstruction accuracy. Short time resolution enables sequencing analysis. Precise timestamps strengthen evidentiary value. Temporal precision aids detection logic. | AU-8 |
| SPR-175 | Technical | Design Constraint | The [spacecraft] shall use internal system clocks to generate time stamps for audit records. | Using internal trusted clocks prevents manipulation via external time signals. Independent time generation strengthens integrity. This reduces risk of adversary-induced timeline distortion. Trusted time underpins reliable auditing. | AU-8 |
| SPR-176 | Technical | Interface Control (ICD) / Standard | The [spacecraft] shall establish, manage, and monitor internal connections between system components in accordance with organization-defined security policies and procedures. | Internal connections for spacecraft may include certain subsystems and payloads that communicate across a common bus. | CA-9 |
| SPR-177 | Technical | Technical Requirement | The [spacecraft] shall automatically generate audit records of the configuration management access enforcement actions. | Recording enforcement actions provides accountability for access control decisions. This enables detection of policy violations or privilege misuse. Audit visibility strengthens governance. Security controls must themselves be auditable. | CM-5(1) |
| SPR-178 | Technical | Technical Requirement | The [spacecraft] shall limit changes to system components and system-related information during operations. | Uncontrolled changes during operations introduce instability and increase exploitation risk. Restricting modifications reduces insider threat and unauthorized configuration drift. Operational stability is critical in space systems where rollback may be impossible. Controlled change windows preserve mission integrity. | CM-5(5) |
| SPR-179 | Technical | Technical Requirement | The [spacecraft] shall be configured to restrict software execution to only the software/processes that are explicitly authorized and necessary for operational purposes. | Allowlisting executable processes prevents unauthorized or malicious code execution. This reduces attack surface and blocks persistence mechanisms. Spacecraft compute resources are constrained, making minimal execution environments safer and more predictable. Only mission-essential binaries should be permitted. | CM-7(2) |
| SPR-180 | Technical | Technical Requirement | The [spacecraft] shall enforce least functionality principles to prevent the execution of unauthorized software. | Limiting enabled services and functions reduces exploitable entry points. Unused capabilities create unnecessary risk without mission benefit. Least functionality supports deterministic system behavior. Reduced complexity improves resilience and monitoring accuracy. | CM-7(2) |
| SPR-181 | Technical | Technical Requirement | The [spacecraft] shall employ advanced analytics capabilities within the IDS/IPS to address dynamic never-before-seen attacks using machine learning/adaptive technologies along with signature-based attacks. Models shall be trained and tuned using mission telemetry profiles to support predictive detection. | Signature-based detection addresses known threats, while adaptive analytics detect novel or evolving behaviors. Spacecraft telemetry provides rich baseline data for predictive anomaly detection. Machine learning enhances early detection of zero-day or previously unseen tactics. Combining both approaches strengthens defense against advanced adversaries. | RA-3(4) |
| SPR-182 | Technical | Technical Requirement | The [spacecraft] shall generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries. | Error outputs must enable corrective action without exposing system internals. Detailed diagnostic data may aid adversarial reconnaissance. Sanitized messages protect confidentiality while supporting recovery. Controlled verbosity reduces exploitation opportunities. | RA-5(4) SI-4(12) SI-11 |
| SPR-183 | Technical | Technical Requirement | The [spacecraft] shall reveal error messages only to operations personnel monitoring the telemetry. | Limiting error visibility prevents information leakage to unauthorized entities. Adversaries often probe systems to extract internal states via fault responses. Controlled telemetry channels ensure only trusted operators receive diagnostic information. This preserves operational awareness without expanding exposure. | RA-5(4) SI-4(12) SI-11 |
| SPR-184 | Technical | Technical Requirement | The [spacecraft] software subsystems shall provide independent mission/cyber critical threads such that any one credible event will not corrupt another mission/cyber critical thread. | Thread isolation prevents cascading failures from a single compromised execution path. Functional independence enhances resilience against exploitation and fault propagation. Critical functions must not share dependencies that create systemic vulnerabilities. Isolation supports containment and recovery. | SC-3 |
| SPR-185 | Technical | Technical Requirement | The [spacecraft] shall synchronize the internal system clocks for each processor to the authoritative time source when the time difference is greater than the FSW-defined interval. | Accurate timekeeping ensures reliable logging, command sequencing, and cryptographic validation. Time drift may enable replay attacks or audit misalignment. Automatic synchronization preserves integrity of security controls. Reliable time is foundational for forensics and coordinated response. | AU-8(1) SC-45 SC-45(1) SC-45(2) |
| SPR-186 | Technical | Technical Requirement | The [spacecraft] shall have fault-tolerant authoritative time sourcing for the platform's clock. | * Adopt voting schemes (triple modular redundancy) that include inputs from backup sources. Consider providing a second reference frame against which short-term changes or interferences can be compared. * Atomic clocks, crystal oscillators and/or GPS receivers are often used as time sources. GPS should not be used as the only source due to spoofing/jamming concerns. | AU-8(2) SC-45 SC-45(1) SC-45(2) SI-13 |
| SPR-187 | Technical | Interface Control (ICD) / Standard | If Spacewire is utilized, the [spacecraft] shall adhere to [organization]-defined time synchronization standard/protocol to synchronize time across a Spacewire network with an accuracy around 1 microsecond. | Example for time synchronization is Time Distribution Protocol (http://spacewire.esa.int/WG/Spacewire/SpW-WG-Mtg17-Proceedings/Documents/ISC_2011%20CCSDS%20Time%20Distribution%20over%20SpaceWire.pdf & https://amstel.estec.esa.int/tecedm/ipcores/time_sync_protocol.pdf). These activities by ESA are looking to perform standardization of a time distribution protocol, synchronization, and handling of latency, jitter, and drift | SC-45 SC-45(1) SC-45(2) |
| SPR-188 | Procedural | Process / Procedure | The [organization] shall ensure synchronization of system clocks within and between systems and system components.. | Mission-wide synchronization ensures consistent event correlation across space and ground systems. Disparate clocks undermine incident reconstruction. Centralized time governance strengthens anomaly detection. Coordinated timing reduces ambiguity in distributed architectures. | SC-45 SC-45(1) SC-45(2) |
| SPR-189 | Technical | Technical Requirement | The [spacecraft] shall internally monitor PNT performance so that changes or interruptions in the navigation or timing are flagged. | Positioning, navigation, and timing disruptions may indicate spoofing or jamming. Continuous monitoring detects deviations early. Reliable PNT is critical for spacecraft control and cryptographic timing. Awareness mitigates navigation-based exploitation. | AU-8(1) SC-45(1) |
| SPR-190 | Technical | Technical Requirement | The [spacecraft] shall incorporate backup sources for navigation and timing. | Redundant timing sources reduce reliance on potentially compromised signals. Backup mechanisms preserve availability under spoofing or denial conditions. Diverse timing inputs enhance mission continuity. Resilience requires redundancy. | AU-8(1) SC-45(1) SC-45(2) |
| SPR-191 | Technical | Technical Requirement | The [spacecraft] shall internally monitor GPS performance so that changes or interruptions in the navigation or timing are flagged. | GPS anomalies may signal interference or manipulation. Detection enables transition to alternate sources. Real-time monitoring supports defensive maneuvering. Navigation assurance is a safety and cyber imperative. | SC-45(1) |
| SPR-192 | Technical | Technical Requirement | The [spacecraft] shall implement denial-of-service protection mechanisms that restrict the ability of the spacecraft to be used in an attack against other systems. | Examples include: - Traffic Analysis and Filtering: The [spacecraft] shall deploy traffic analysis and filtering mechanisms to detect and mitigate denial-of-service attacks, preventing malicious or excessive traffic from impacting the availability of the spacecraft or any of its sub-components. - Rate Limiting: The [spacecraft] shall implement rate limiting controls to restrict the rate of incoming and outgoing network traffic, preventing the system from being used to launch or amplify denial-of-service attacks. - Resource Allocation: The [spacecraft] shall establish and enforce resource allocation policies to ensure that system resources are fairly and appropriately distributed, minimizing the impact of denial-of-service attacks. - Anomaly Detection: The [spacecraft] shall employ anomaly detection mechanisms to identify unusual patterns of behavior indicative of denial-of-service attacks and take appropriate action to mitigate such attacks. | SC-5(1) |
| SPR-193 | Technical | Technical Requirement | The [spacecraft] shall implement denial-of-service protection measures for managing capacity, bandwidth, and redundancy within the spacecraft to limit the effects of flooding attacks. | Flooding or resource exhaustion can degrade mission operations. Capacity management and redundancy prevent single-channel overload. Traffic shaping and prioritization preserve critical functions. Availability must be actively defended. | SC-5(2) |
| SPR-194 | Technical | Technical Requirement | The [spacecraft] shall physically isolate security tools, mechanisms, and support components used for boundary protection within the spacecraft. | Boundary protection mechanisms must be protected from tampering. Physical isolation reduces risk of compromise via shared buses or payload interfaces. Defensive systems require integrity to remain trustworthy. Separation reinforces defense-in-depth. | SC-7(13) |
| SPR-195 | Technical | Technical Requirement | The [spacecraft] shall audit the communications characteristics (signals, frequencies, etc.) associated with denied communications. | Recording denied communications supports detection of probing and reconnaissance. Signal analysis may reveal adversary tactics or spoofing attempts. Visibility strengthens attribution and tuning of defenses. Denied attempts provide intelligence value. | SC-7(9) |
| SPR-196 | Technical | Design Constraint | The [spacecraft] fault management solution shall utilize memory uncorrectable bit error detection information in a strategy to autonomously minimize the adverse effects of uncorrectable bit errors within the spacecraft. | Radiation-induced errors may mimic malicious tampering. Integrating memory fault data into autonomous mitigation reduces impact. Rapid isolation prevents corrupted logic propagation. Cyber and radiation resilience must be coordinated. | SI-16 |
| SPR-197 | Technical | Technical Requirement | The [spacecraft] Interrupt Service Routine (ISR) shall have the ability to simultaneously update check-bits for [organization]-defined memory addresses. | Real-time integrity updates ensure memory protection during high-speed operations. ISR-based validation minimizes exposure windows. Immediate correction enhances reliability. Hardware-software coordination improves robustness. | SI-16 |
| SPR-198 | Technical | Technical Requirement | The [spacecraft] shall integrate EDAC scheme with fault management and cyber-protection mechanisms to respond to the detection of uncorrectable multi-bit errors, other than time-delayed monitoring of EDAC telemetry by the mission operators on the ground. | Uncorrectable errors may indicate attack or environmental damage. Automated response prevents reliance on delayed ground analysis. Integrated protection accelerates containment. Cybersecurity must leverage hardware integrity signals. | SI-16 |
| SPR-199 | Technical | Design Constraint | The [spacecraft] shall use Error Detection and Correcting (EDAC) memory. | Error detection and correction protects against radiation-induced corruption. Single-bit correction prevents latent system faults. Memory integrity is foundational to secure execution. Hardware reliability directly supports cybersecurity. | SI-16 |
| SPR-200 | Technical | Design Constraint | The [spacecraft] shall utilize an EDAC scheme to routinely check for bit errors in the stored data on board the spacecraft, correct the single-bit errors, and identify the memory addresses of data with uncorrectable multi-bit errors of at least order two, if not higher order in some cases. | Periodic checks detect accumulating degradation. Identifying affected addresses allows isolation of corrupted regions. Early detection prevents escalation into systemic failure. This supports predictive maintenance and anomaly detection. | SI-16 |
| SPR-201 | Technical | Technical Requirement | The [spacecraft] shall monitor all inbound/outbound communications to detect unusual or unauthorized behavior and respond appropriately (disregard command, deny connection, etc.) | Continuous traffic inspection detects unauthorized behavior. Both inbound and outbound flows may signal compromise. Real-time response reduces dwell time. Visibility across communication paths is essential in contested environments. | SI-4(4) |
| SPR-202 | Procedural | Process / Procedure | The [organization] shall define the security safeguards to be employed to protect the availability of system resources. | Explicit availability planning ensures defensive resources are provisioned. Clear safeguards prevent ad hoc reactions during incidents. Structured resilience planning supports mission assurance. Availability is often a primary operational objective. | SC-6 SI-17 |
| SPR-203 | Technical | Technical Requirement | The [spacecraft] shall have failure tolerance on sensors used by software to make mission-critical decisions. | Sensor compromise or failure must not directly lead to hazardous action. Redundancy and validation ensure trustworthy inputs. Independent verification reduces risk of manipulation. Critical decisions require reliable sensing. | SI-13 SI-17 |
| SPR-204 | Technical | Technical Requirement | The [spacecraft] cyber-safe mode software/configuration shall be stored onboard the spacecraft in memory with hardware-based controls and shall not be modifiable. | Cyber-safe mode is using a fail-secure mentality where if there is a malfunction that the spacecraft goes into a fail-secure state where cyber protections like authentication and encryption are still employed (instead of bypassed) and the spacecraft can be restored by authorized commands. The cyber-safe mode should be stored in a high integrity location of the on-board SV so that it cannot be modified by attackers. | SI-17 |
| SPR-205 | Technical | Technical Requirement | The [spacecraft] shall safely transition between all predefined, known states. | Deterministic transitions prevent undefined or unstable states. Controlled state management limits exploitation windows. Safety logic must anticipate abnormal conditions. Predictable behavior enhances resilience. | SI-17 |
| SPR-206 | Technical | Technical Requirement | The [spacecraft] software subsystems shall detect and recover/transition from detected memory errors to a known cyber-safe state. | Memory corruption can degrade or hijack execution. Automated detection and transition to safe state prevents escalation. Recovery mechanisms reduce persistent compromise risk. Resilience requires automatic containment. | SI-17 |
| SPR-207 | Technical | Technical Requirement | The [spacecraft] software subsystems shall initialize the spacecraft to a known safe state. | Startup is a vulnerable period for tampering. Initialization ensures clean baseline before operations begin. Safe defaults prevent unauthorized persistence. Boot integrity establishes trust. | SI-17 |
| SPR-208 | Technical | Technical Requirement | The [spacecraft] software subsystems shall operate securely in off-nominal power conditions, including loss of power and spurious power transients. | Power instability may disrupt security controls. Robust design prevents exploit via induced power anomalies. Controlled behavior during transients preserves integrity. Cyber resilience must consider physical fault conditions. | SI-17 |
| SPR-209 | Technical | Technical Requirement | The [spacecraft] software subsystems shall perform an orderly, controlled system shutdown to a known cyber-safe state upon receipt of a termination command or condition. | Graceful shutdown prevents data corruption and incomplete processes. Controlled transitions reduce recovery complexity. Secure shutdown blocks adversary exploitation during failure states. Predictable termination supports resilience. | SI-17 |
| SPR-210 | Technical | Technical Requirement | The [spacecraft] software subsystems shall recover to a known cyber-safe state when an anomaly is detected. | Anomaly-triggered containment reduces attacker dwell time. Safe fallback states preserve mission viability. Autonomous response is essential given communication latency. Rapid isolation prevents lateral spread. | SI-17 |
| SPR-211 | Technical | Technical Requirement | The [spacecraft] software subsystems shall safely transition between all predefined, known states. | Safe and deterministic state transitions prevent undefined behavior that could be exploited during abnormal or adversarial conditions. Many cyber and fault-based attacks attempt to force systems into unexpected transitional states where validation checks may be bypassed. By ensuring transitions only occur along predefined, verified paths, the spacecraft reduces opportunities for logic corruption or hazardous command execution. Controlled state management strengthens both safety assurance and cybersecurity resilience. | SI-17 |
| SPR-212 | Technical | Technical Requirement | The [spacecraft] shall be capable of shutting off specific subsystems or payloads to isolate malicious activity or protect the platform. | Isolation limits impact of compromised components. Segmentation prevents systemic compromise. Controlled shutdown preserves overall platform health. Modular containment strengthens survivability. | PE-10 |
| SPR-213 | Technical | Technical Requirement | The [spacecraft] boot firmware shall enter a recovery routine upon failing to verify signed data in the trust chain, and not execute or trust that signed data. | No other requirements are imposed on the recovery routine besides not using the failed data. Unverifiable data isn’t trusted and shouldn’t be run. | SI-7(9) SI-7(10) |
| SPR-214 | Technical | Interface Control (ICD) / Standard | The [spacecraft] root of trust shall be an ECDSA NIST P-384 public key. | Strong elliptic curve cryptography ensures robust digital signature validation. P-384 provides long-term cryptographic assurance. Root of trust underpins secure boot and update integrity. High-strength algorithms mitigate future cryptanalytic advances. | SI-7(9) SI-7(10) |
| SPR-215 | Technical | Technical Requirement | The [spacecraft] root of trust shall be loadable only once, post-purchase. | Preventing post-deployment modification protects foundational trust anchors. Immutable RoT blocks adversary replacement of cryptographic keys. Hardware-level assurance strengthens supply chain defense. Trust must not be alterable in orbit. | SI-7(9) SI-7(10) |
| SPR-216 | Technical | Technical Requirement | The [spacecraft] secure boot mechanism shall be Commercial National Security Algorithm Suite (CNSA) compliant. | No certification process is required (or exists). The CNSA is easy to meet, only restricts algorithm choice, and aids ease-of-use for government customers. | SI-7(9) SI-7(10) |
| SPR-217 | Technical | Technical Requirement | The [spacecraft] shall allocate enough boot ROM memory for secure boot firmware execution. | Secure boot requires protected execution space. Sufficient ROM ensures immutable verification routines. Resource planning prevents insecure fallback mechanisms. Boot memory is critical to chain-of-trust integrity. | SI-7(9) SI-7(10) |
| SPR-218 | Technical | Technical Requirement | The [spacecraft] shall allocate enough SRAM memory for secure boot firmware execution. | Volatile secure execution space prevents tampering persistence. SRAM allocation supports cryptographic operations. Adequate memory prevents degraded security routines. Secure boot must not be resource constrained. | SI-7(9) SI-7(10) |
| SPR-219 | Technical | Interface Control (ICD) / Standard | The [spacecraft] shall support the algorithmic construct of Elliptic Curve Digital Signature Algorithm (ECDSA) NIST P-384 + SHA-38 or equivalent strength. | Timing data may suggest cryptographic accelerators are unnecessary. This construct was chosen because (a) it’s in the CNSA suite and (b) it doesn’t require secret values to be stored | SI-7(9) SI-7(10) |
| SPR-220 | Deprecated | Deprecated | The [spacecraft] hardware root of trust shall be an ECDSA NIST P-384 public key. | No requirement is imposed on uniqueness. | SI-7(9) |
| SPR-221 | Deprecated | Deprecated | The [spacecraft] hardware root of trust shall be loadable only once, post-purchase. | No requirement is imposed on preventing hardware readout. The public key belongs to the customer, not the manufacturer, so it must be loaded after purchase. Also, if it can be overwritten, there’s no reason to trust it. | SI-7(9) |
| SPR-222 | Deprecated | Deprecated | The [spacecraft] shall implement trusted boot/RoT as a separate compute engine controlling the trusted computing platform cryptographic processor. | Isolation of RoT prevents compromise via main processor exploitation. Dedicated engine strengthens integrity of signature validation. Separation reduces attack surface. Hardware trust boundaries enhance assurance. | SI-7(9) |
| SPR-223 | Deprecated | Deprecated | The [spacecraft] shall implement trusted boot/RoT computing module on radiation tolerant burn-in (non-programmable) equipment. | Space radiation may corrupt trust logic. Radiation-hardened modules ensure continued secure boot enforcement. Environmental resilience preserves cryptographic integrity. Hardware trust must survive mission conditions. | SI-7(9) |
| SPR-224 | Deprecated | Deprecated | The [spacecraft] protects the availability of resources by allocating resources based on priority and/or quota. | SC-6 | |
| SPR-225 | Technical | Technical Requirement | The [spacecraft] shall protect the availability of resources by allocating [organization]-defined resources based on [priority and/or quota]. | In particular, this control is required for all space platform buses to ensure execution of high priority functions; it is particularly important when there are multiple payloads sharing a bus providing communications and other services, where bus resources must be prioritized based on mission. | SC-6 |
| SPR-226 | Technical | Technical Requirement | The [spacecraft] shall implement dynamic isolation and segregation mechanisms for boundary protection to enhance its security by isolating components when necessary (e.g.compromised/malicious payload). | Ability to isolate compromised components reduces lateral spread. Dynamic segmentation enhances resilience in active attack scenarios. Isolation supports autonomous containment. Modular protection improves survivability. | SC-7(20) |
| SPR-227 | Procedural | Process / Procedure | The [organization] shall identify all locations (including ground and contractor systems) that store or process sensitive system information. | Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations. | AC-3(11) CM-12 |
| SPR-228 | Procedural | Documentation Requirement | The [organization] shall identify sensitive mission data (e.g.CPI) and document the specific on-board components on which the information is processed and stored. | Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations. | AC-3(11) CM-12 |
| SPR-229 | Procedural | Documentation Requirement | The [organization] shall protect documentation and Controlled Unclassified Information (CUI) as required, in accordance with the risk management strategy. | Documentation may reveal architecture details exploitable by adversaries. Proper handling prevents leakage. Protection of CUI supports regulatory compliance. Information governance complements technical controls. | 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 |
| SPR-230 | Procedural | Documentation Requirement | 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. | * 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. | 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 |
| SPR-231 | Procedural | Documentation Requirement | The [organization] shall distribute documentation to only personnel with defined roles and a need to know. | Least privilege and need to know should be employed with the protection of all documentation. Documentation can contain sensitive information that can aid in vulnerability discovery, detection, and exploitation. For example, command dictionaries for ground and space systems should be handles with extreme care. Additionally, design documents for missions contain many key elements that if compromised could aid in an attacker successfully exploiting the system. | CM-12 CP-2 SA-5 SA-10 |
| SPR-232 | Procedural | Process / Procedure | 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. | 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. | 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 |
| SPR-233 | Technical | Technical Requirement | The [organization] shall identify the applicable physical and environmental protection policies covering the development environment and spacecraft hardware. | Development environments must be protected from tampering. Physical controls prevent hardware supply chain compromise. Policy clarity ensures consistent safeguards. Secure development underpins secure deployment. | PE-1 PE-14 SA-3 SA-3(1) SA-10(3) |
| SPR-234 | Technical | Technical Requirement | The [organization] shall develop and document program-specific identification and authentication policies for accessing the development environment and spacecraft. | Strong authentication prevents unauthorized development access. Development compromise can introduce malicious code. Documented policies ensure consistent enforcement. Identity governance supports supply chain integrity. | AC-3 AC-14 IA-1 SA-3 SA-3(1) |
| SPR-235 | Procedural | Documentation Requirement | 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. | 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. | AC-3 SA-3 SA-3(1) SA-15 |
| SPR-236 | Procedural | Concept of Operations (ConOps) | The [organization] shall implement a verifiable flaw remediation process into the developmental and operational configuration management process. | 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. | CA-2 CA-5 SA-3 SA-3(1) SA-11 SI-3 SI-3(10) |
| SPR-237 | Procedural | Process / Procedure | 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. | Abuse-case testing reveals design weaknesses before deployment. Red-teaming strengthens defensive posture. Proactive validation reduces operational risk. Testing must simulate realistic threat scenarios. | 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) |
| SPR-238 | Procedural | Process / Procedure | 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]. | 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. | SA-3 SA-4(3) |
| SPR-239 | Procedural | Concept of Operations (ConOps) | The [organization] shall approve, document, and control the use of operational data in preproduction environments (i.e., development, I&T, etc.). | Operational data in test environments increases exposure risk. Controlled handling prevents unintended leakage. Proper governance reduces insider and supply chain risk. Sensitive data must be protected at all lifecycle stages. | SA-3(2) |
| SPR-240 | Procedural | Concept of Operations (ConOps) | The [organization] shall categorize/classify preproduction environments (i.e., development, I&T, etc.) at the same level as any operational data in use within the environment and protect the system consistent with its categorization/classification. | Development systems often become attack vectors. Equal classification ensures consistent safeguards. Protection must reflect data sensitivity. Weak dev security undermines operational integrity. | SA-3(2) |
| SPR-241 | Procedural | Process / Procedure | The [organization] shall require the developer of the system, system component, or system services to identify organizational data that will be processed or stored on non-organizational systems. | Awareness of data location prevents uncontrolled exposure. Third-party systems may lack equivalent security. Explicit identification enables mitigation. Data governance strengthens risk management. | SA-4(12) |
| SPR-242 | Procedural | Process / Procedure | The [organization] shall require the developer of the system, system component, or system services to remove all organizational data from contractor system(s) when no longer needed for development purposes or whenever instructed by the organization. | Residual data increases breach impact. Timely removal reduces exposure. Lifecycle data hygiene is critical. Controlled offboarding prevents persistence of sensitive information. | SA-4(12) SI-21 |
| SPR-243 | Procedural | Documentation Requirement | The [organization] shall protect documentation and Essential Elements of Information (EEI) as required, in accordance with the risk management strategy. | Essential Elements of Information (EEI): | SA-5 |
| SPR-244 | Procedural | Standards / ICD Development | 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. | Standardized secure protocols reduce interoperability risk. Alignment with federal standards ensures validated cryptography. Defined protocols prevent ad hoc insecure implementations. Governance strengthens communication assurance. | 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 |
| SPR-245 | Procedural | Process / Procedure | The [organization] shall define processes and procedures to be followed when integrity verification tools detect unauthorized changes to software, firmware, and information. | Predefined response procedures reduce reaction time. Clear escalation paths improve containment. Consistent handling prevents confusion during incidents. Preparedness strengthens resilience. | 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) |
| SPR-246 | Deprecated | Deprecated | 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-247 | Procedural | Documentation Requirement | The [organization] shall develop policies and procedures to ensure proper care is taken when disposing of sensitive data, documentation, or system components throughout the entire mission lifecycle. | Improper disposal may expose system details. Lifecycle security includes end-of-life handling. Secure destruction prevents reconstruction or reverse engineering. Governance extends beyond operations. | SR-12 |
| SPR-248 | Deprecated | Deprecated | The [organization] shall employ Operations Security (OPSEC) safeguards to protect supply chain-related information for the system, system components, or system services. | Supply chain information can reveal vulnerabilities. OPSEC reduces adversary intelligence gathering. Controlled disclosure minimizes targeting risk. Information discipline strengthens strategic defense. | CP-2(8) PM-30 SA-12(9) SC-38 SR-7 |
| SPR-249 | Procedural | Process / Procedure | The [organization] shall employ [Program-defined Operations Security (OPSEC) safeguards] to protect supply chain-related information for the system, system components, or system services. | 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. | CP-2(8) PM-30 SA-12(9) SC-38 SR-7 |
| SPR-250 | Procedural | Process / Procedure | The [organization] shall verify that the scope of security testing/evaluation provides complete coverage of required security controls (to include abuse cases and penetration testing) at the depth of testing defined in the test documents. | * The frequency of testing should be driven by Program completion events and updates. * Examples of approaches are static analyses, dynamic analyses, binary analysis, or a hybrid of the three approaches | CA-2 CA-8 RA-5(3) SA-11(5) SA-11(7) |
| SPR-251 | Procedural | Documentation Requirement | The [organization] shall maintain evidence of the execution of the security assessment plan and the results of the security testing/evaluation. | 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. | CA-2 CA-8 SA-11 |
| SPR-252 | Procedural | Process / Procedure | 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. | 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. | CA-2 CA-8 SA-11 SA-11(5) |
| SPR-253 | Technical | Technical Requirement | The [organization] shall coordinate penetration testing on mission critical spacecraft components (hardware and/or software). | 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. | CA-8 CA-8(1) CP-4(5) |
| SPR-254 | Procedural | Process / Procedure | 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). | 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. | CA-8 CM-10(1) RA-3(1) SA-11(5) SA-11(8) SA-11(9) SI-3 SI-7(10) |
| SPR-255 | Procedural | Process / Procedure | 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. | 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. | 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) |
| SPR-256 | Procedural | Process / Procedure | 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. | 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. | CA-8(1) SA-9 SA-11(5) SR-5(2) |
| SPR-257 | Technical | Technical Requirement | The [organization] shall analyze changes to the spacecraft to determine potential security impacts prior to change implementation. | Changes to spacecraft configuration may introduce unintended vulnerabilities. Pre-implementation impact analysis prevents security regression. Structured review ensures modifications align with risk tolerance. Change control supports mission assurance. | CM-4 CM-3 CM-3(2) CM-3(7) CM-4(2) SA-10 |
| SPR-258 | Procedural | Process / Procedure | The [organization] shall test the contingency plan, with special consideration for space operations, to determine the effectiveness of the plan and readiness to execute the plan. | Contingency plans must be validated under realistic mission conditions. Testing confirms feasibility during communication latency or constrained power states. Exercises reveal gaps in readiness. Preparedness reduces recovery time during incidents. | CP-4 |
| SPR-259 | Procedural | Documentation Requirement | The [organization] shall develop an incident response and forensics plan that covers the spacecrafts. | A structured response plan enables coordinated containment and recovery. Forensics planning ensures evidence preservation. Defined procedures reduce confusion during crisis. Incident readiness enhances resilience. | CP-2 IR-1 IR-3 IR-3(2) IR-4(12) IR-4(13) IR-8 SA-15(10) SI-4(24) |
| SPR-260 | Technical | Technical Requirement | The [organization] shall test the incident response capabilities of the spacecraft to determine the effectiveness of the plan and readiness to execute the plan. | Practical exercises validate plan effectiveness. Testing ensures spacecraft systems can support containment, telemetry capture, and recovery actions. Simulation reduces uncertainty during real events. Readiness must be demonstrated, not assumed. | IR-3 |
| SPR-261 | Procedural | Documentation Requirement | The [organization] shall coordinate testing of the incident response plan with organizational elements responsible for related plans. | Cyber incidents span mission, enterprise, and supplier boundaries. Coordinated exercises ensure interoperability and shared understanding. Integrated testing reduces response friction. Cross-organizational alignment improves containment. | IR-3(2) |
| SPR-262 | Procedural | Process / Procedure | The [organization] includes security awareness training on recognizing and reporting potential indicators of insider threat. | Authorized users present significant risk vectors. Awareness training improves detection of anomalous behavior. Early reporting reduces insider dwell time. Human vigilance complements technical controls. | AT-2(2) IR-4(6) IR-6 IR-6(2) PM-16 |
| SPR-263 | Procedural | Process / Procedure | The [organization] shall provide training to its personnel on how to identify and respond to malicious code indicators to include but not limited to indicators of potentially malicious code in flight software, indicators from development machine’s anti-virus/anti-malware software of potential malicious code, and to recognize suspicious communications and anomalous behavior in [organization] information systems. | Personnel must recognize signs of compromised flight or development systems. Early detection prevents propagation into mission assets. Training strengthens defense across lifecycle stages. Awareness reduces supply chain exposure. | AT-3(4) IR-6 IR-6(2) SI-4(24) |
| SPR-264 | Procedural | Process / Procedure | The [organization] shall report counterfeit information system components to [organization] officials. | 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. | IR-6 IR-6(2) PM-30 SA-19 SR-11 |
| SPR-265 | Procedural | Process / Procedure | 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. | Rapid reporting of vulnerable components enables proactive remediation. Awareness of newly disclosed flaws prevents exploitation. Coordination ensures mission-wide response. Visibility reduces systemic risk. | IR-6 IR-6(2) SI-2 SI-3 SI-4(12) SR-4(4) |
| SPR-266 | Procedural | Process / Procedure | The [organization] shall determine the vulnerabilities/weaknesses that require remediation, and coordinate the timeline for that remediation, in accordance with the analysis of the vulnerability scan report, the mission assessment of risk, and mission needs. | Not all vulnerabilities carry equal mission impact. Risk-informed prioritization ensures critical flaws are addressed first. Coordinated timelines balance mission needs with security posture. Structured remediation strengthens governance. | CA-5 CM-3 RA-5 RA-7 SI-3 SI-3(10) |
| SPR-267 | Procedural | Process / Procedure | The [organization] shall perform software component analysis (a.k.a.origin analysis) for developed or acquired software. | 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. | CM-10 CM-10(1) RA-3(1) RA-5 SA-15(7) SI-3 SI-3(10) SR-4(4) |
| SPR-268 | Procedural | Process / Procedure | The [organization] shall share information obtained from the vulnerability scanning process and security control assessments with [Program-defined personnel or roles] to help eliminate similar vulnerabilities in other systems (i.e., systemic weaknesses or deficiencies). | Sharing scan results prevents repeated weaknesses across systems. Enterprise/Mission visibility reduces systemic vulnerabilities. Collaborative learning enhances resilience. Cross-program transparency strengthens collective defense. | RA-5 |
| SPR-269 | Procedural | Process / Procedure | The [organization] shall ensure that the vulnerability scanning tools (e.g., static analysis and/or component analysis tools) used include the capability to readily update the list of potential information system vulnerabilities to be scanned. | Threat landscapes evolve rapidly. Regular tool updates ensure detection coverage remains current. Outdated signatures create blind spots. Continuous improvement sustains effectiveness. | RA-5 RA-5(1) RA-5(3) SI-3 |
| SPR-270 | Procedural | Process / Procedure | The [organization] shall perform vulnerability analysis and risk assessment of all systems and software. The analysis shall include results from hardware‑in‑the‑loop vulnerability scanning of flight software, firmware, and link‑segment interfaces. | Integrated hardware-in-the-loop testing identifies operationally relevant weaknesses. Combined software, firmware, and interface scanning provides holistic coverage. Risk assessment ensures mitigation aligns with mission priorities. End-to-end analysis strengthens assurance. | RA-5 RA-5(3) SA-15(7) SI-3 |
| SPR-271 | Procedural | Process / Procedure | The [organization] shall ensure that vulnerability scanning tools and techniques are employed that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: (1) Enumerating platforms, custom software flaws, and improper configurations; (2) Formatting checklists and test procedures; and (3) Measuring vulnerability impact. Scanning shall cover flight software, firmware, and link‑segment interfaces in hardware‑in‑the‑loop environments. | Component/Origin scanning looks for open-source libraries/software that may be included into the baseline and looks for known vulnerabilities and open-source license violations. | RA-5 RA-5(3) SI-3 |
| SPR-272 | Technical | Technical Requirement | The [organization] shall perform static binary analysis of all firmware that is utilized on the spacecraft. | 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. | RA-5 SA-10 SA-11 SI-7(10) |
| SPR-273 | Procedural | Process / Procedure | The [organization] shall perform static source code analysis for all available source code looking for [[organization]-defined Top CWE List] weaknesses using complimentary set of static code analysis tools (i.e.more than one). | Static analysis detects coding weaknesses before execution. Using multiple tools increases detection coverage. Alignment with defined CWE priorities ensures focus on high-risk flaws. Early detection reduces downstream remediation cost. | RA-5 SA-11(1) SA-15(7) |
| SPR-274 | Procedural | Process / Procedure | The [organization] shall analyze vulnerability/weakness scan reports and results from security control assessments. | Scan results require expert interpretation to avoid false positives or overlooked risks. Structured analysis ensures meaningful remediation. Correlating findings with mission context refines prioritization. Review strengthens governance. | RA-5 SI-3 |
| SPR-275 | Procedural | Process / Procedure | The [organization] shall have automated means to evaluate adherence to coding standards. | Manual review cannot scale across the code base; you must have a way to scale in order to confirm your coding standards are being met. The intent is for automated means to ensure code adheres to a coding standard. | SA-15 SA-15(7) RA-5 |
| SPR-276 | Deprecated | Deprecated | The [organization] shall perform component analysis (a.k.a.origin analysis) for developed or acquired software. | SA-15(7) RA-5 | |
| SPR-277 | Procedural | Process / Procedure | In coordination with [organization], the [organization] shall prioritize and remediate flaws identified during security testing/evaluation. | Timely remediation reduces exploitation window. Coordination ensures mission continuity during patching. Documented prioritization demonstrates due diligence. Structured response enhances accountability. | CA-2 CA-5 SA-11 SI-3 SI-3(10) |
| SPR-278 | Procedural | Process / Procedure | The [organization] shall correct flaws identified during security testing/evaluation. | Flaws that impact the mission objectives should be prioritized. | SA-11 |
| SPR-279 | Procedural | Process / Procedure | The [organization] shall perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Program-defined depth and coverage]. | The depth needs to include functional testing as well as negative/abuse testing. | SA-11 |
| SPR-280 | Procedural | Process / Procedure | 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. | 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. | SA-4(5) |
| SPR-281 | Procedural | Process / Procedure | The [organization] shall have an Insider Threat Program to aid in the detection and prevention of people with authorized access to perform malicious activities. | Formal insider programs provide monitoring, reporting, and mitigation mechanisms. Behavioral analysis strengthens early detection. Structured governance reduces insider impact. Policy-backed programs improve deterrence. | AT-2(2) IR-4(6) IR-4(7) PM-12 PM-16 |
| SPR-282 | Procedural | Process / Procedure | 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. | * 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. | PM-16 PM-30 RA-2 RA-3(1) RA-3(2) RA-7 SA-9 SA-12(8) SR-5(2) |
| SPR-283 | Procedural | Process / Procedure | 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. | 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. | PM-16 PM-30(1) RA-3(1) SA-9 SA-12 SR-1 |
| SPR-284 | Procedural | Process / Procedure | The [organization] shall use all-source intelligence analysis on threats to mission critical capabilities and/or system components to inform risk management decisions. | Intelligence-informed risk management anticipates adversary capabilities. External threat awareness improves proactive defense. Integration into decision-making strengthens resilience. Threat-informed design reduces reactive posture. | PM-16 RA-3(2) RA-3(3) RA-7 RA-9 SA-12(8) SA-15(8) |
| SPR-285 | Procedural | Process / Procedure | The [organization] risk assessment shall include the full end to end communication pathway (i.e., round trip) to include any crosslink communications. | Full pathway analysis prevents overlooking intermediate segments. Crosslinks may introduce lateral risk exposure. Round-trip evaluation strengthens confidentiality and integrity assurance. Holistic view reduces blind spots. | AC-20 AC-20(1) AC-20(3) RA-3 SA-8(18) |
| SPR-286 | Procedural | Process / Procedure | The [organization] shall conduct an assessment of risk prior to each milestone review [SRR\PDR\CDR], including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the platform and the information it processes, stores, or transmits. | Major design decisions must reflect updated threat posture. Pre-milestone risk review prevents costly redesign. Structured evaluation supports informed governance. Early risk integration enhances mission confidence. | RA-2 RA-3 SA-8(25) |
| SPR-287 | Deprecated | Deprecated | The [organization] shall document risk assessment results in [risk assessment report]. | Formal documentation preserves rationale for decisions. Traceability enables future reassessment. Written records support compliance. Documentation strengthens transparency. | RA-3 |
| SPR-288 | Procedural | Policy / Governance | The [organization] shall review risk assessment results [At least annually if not otherwise defined in formal organizational policy]. | Periodic review ensures evolving threats are considered. Regular reassessment prevents stagnation. Continuous evaluation supports adaptive defense. Governance must be iterative. | RA-3 |
| SPR-289 | Procedural | Policy / Governance | The [organization] shall update the risk assessment [At least annually if not otherwise defined in formal institutional policy] or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the spacecraft. | System modifications alter risk posture. Immediate reassessment ensures continued compliance. Responsive review strengthens mission assurance. Risk management must be dynamic. | RA-3 |
| SPR-290 | Procedural | Documentation Requirement | The [organization] shall document risk assessment results in risk assessment report upon completion of each risk assessment. | Formal documentation preserves rationale for decisions. Traceability enables future reassessment. Written records support compliance. Documentation strengthens transparency. | RA-3 RA-7 |
| SPR-291 | Procedural | Process / Procedure | The [organization] shall use the threat and vulnerability analyses of the as-built system, system components, or system services to inform and direct subsequent testing/evaluation of the as-built system, component, or service. | Security analysis should guide test design. Threat-informed evaluation improves relevance. Feedback loops strengthen defensive posture. Analytical alignment enhances coverage. | RA-3(3) SA-11(2) SA-15(8) SI-3 |
| SPR-292 | Procedural | Process / Procedure | The [organization] shall ensure that role-based security-related training is provided to personnel with assigned security roles and responsibilities: (i) before authorizing access to the system or performing assigned duties; (ii) when required by system changes; and (iii) at least annually thereafter. | Personnel must understand role-specific responsibilities. Tailored training reduces misuse. Continuous reinforcement maintains awareness. Human factors are central to defense. | AT-3 CP-2 |
| SPR-293 | Procedural | Process / Procedure | The [organization] shall employ techniques to limit harm from potential adversaries identifying and targeting the [organization]s supply chain. | Adversaries often exploit supplier relationships. Protective measures reduce reconnaissance and manipulation. Supply chain resilience strengthens mission integrity. Proactive defense mitigates systemic exposure. | CP-2 PM-30 SA-9 SA-12(5) SC-38 SR-3 SR-3(1) SR-3(2) SR-5(2) |
| SPR-294 | Deprecated | Deprecated | The [organization] shall use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. | SA-11(2) SA-15(8) | |
| SPR-295 | Procedural | Process / Procedure | The [organization] shall perform and document threat and vulnerability analyses of the as-built system, system components, or system services. | Formal records preserve findings and mitigation strategies. Documentation supports lifecycle traceability. Transparent records enhance oversight. Governance requires evidence. | SA-11(2) SI-3 |
| SPR-296 | Procedural | Process / Procedure | The [organization] shall conduct an Attack Surface Analysis and reduce attack surfaces to a level that presents a low level of compromise by an attacker. | Reducing exposed interfaces lowers exploitation probability. Quantified surface reduction strengthens resilience. Structured assessment aligns design with mission risk tolerance. Minimization enhances defensive posture. | SA-11(6) SA-15(5) |
| SPR-297 | Technical | Technical Requirement | The [organization] shall require the developer to conduct an attack surface analysis on the spacecraft architecture to identify and reduce attack surfaces to the lowest possible level that still permits the system to meet performance requirements/mission objectives. | Embedding surface reduction into architecture strengthens foundational security. Early analysis prevents costly retrofits. Developer accountability ensures security by design. Integrated evaluation improves mission readiness. | SA-11(6) SA-15(5) |
| SPR-298 | Procedural | Process / Procedure | The [organization] shall require the developer to use threat modeling, attack surface analysis, and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. | Threat modeling anticipates adversary tactics. Early design adaptation reduces vulnerability exposure. Learning from similar systems improves efficiency. Proactive analysis reduces downstream risk. | SA-15(8) |
| SPR-299 | Procedural | Documentation Requirement | The [organization] shall develop, document, and maintain under configuration control, a current baseline configuration of the spacecrafts. | Configuration control ensures traceability of hardware and software states. Unauthorized changes undermine security posture. Accurate baselines enable recovery and audit. Governance depends on configuration integrity. | CM-2 CM-3(7) CM-4(2) CM-6 SA-8(30) SA-10 |
| SPR-300 | Procedural | Process / Procedure | 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. | Build data linkage ensures reproducibility and traceability. Tampering detection depends on accurate mapping. Integrity of master copies prevents unauthorized modification. Configuration discipline supports resilience. | 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) |
| SPR-301 | Procedural | Process / Procedure | The [organization] shall develop a security plan for the spacecraft. | A comprehensive security plan aligns controls with mission objectives. Clear articulation ensures consistent implementation. Planning integrates security into operations. Formal documentation strengthens accountability. | PL-2 PL-7 PM-1 SA-8(29) SA-8(30) |
| SPR-302 | Procedural | Documentation Requirement | 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. | Architecture documentation provides structural clarity. Integration into enterprise mission security ensures alignment. Clear documentation reduces misinterpretation. Transparency strengthens lifecycle governance. | PL-7 SA-8(7) SA-8(13) SA-8(29) SA-8(30) SA-17 |
| SPR-303 | Procedural | Documentation Requirement | The [organization] shall protect the security plan from unauthorized disclosure and modification. | Exposure of architecture details increases adversary advantage. Protecting documentation reduces reconnaissance risk. Controlled access ensures integrity. Governance must secure sensitive planning artifacts. | AC-3 PL-2 PL-7 |
| SPR-304 | Procedural | Process / Procedure | The [organization] shall maintain a list of suppliers and potential suppliers used, and the products that they supply to include software. | Ideally you have diversification with suppliers | CM-10 PL-8(2) PM-30 SA-8(9) SA-8(11) |
| SPR-305 | Procedural | Policy / Governance | 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. | Counterfeit hardware may embed malicious implants. Formal policies reduce infiltration risk. Supplier verification strengthens trust. Hardware authenticity is foundational to cybersecurity. | 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 |
| SPR-306 | Procedural | Process / Procedure | 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. | Pre-contract review ensures vendor security posture. Due diligence reduces third-party risk exposure. Structured evaluation strengthens procurement governance. Supplier trust must be verified. | PM-30 PM-30(1) RA-3(1) SA-8(9) SA-8(11) SA-9 SA-12(2) SR-5(2) SR-6 |
| SPR-307 | Procedural | Documentation Requirement | The [organization] shall maintain documentation tracing the strategies, tools, and methods implemented to mitigate supply chain risk . | 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; | PM-30 RA-3(1) SA-12(1) SR-5 |
| SPR-308 | Procedural | Documentation Requirement | 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. | 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. | PM-30 RA-3(1) SA-8(9) SA-8(11) SA-12 SI-3 SR-1 |
| SPR-309 | Procedural | Process / Procedure | The [organization] shall identify the key system components or capabilities that require isolation through physical or logical means. | Fault management and security management capabilities would be classified as mission critical and likely need separated. Additionally, capabilities like TT&C, C&DH, GNC might need separated as well. | AC-3 SC-3 SC-7(13) SC-28(3) SC-32 SC-32(1) |
| SPR-310 | Deprecated | Deprecated | 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 | Technical | Design Constraint | 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} | Trusted microelectronics reduce hardware supply chain risk. DMEA accreditation strengthens assurance. Hardware-level compromise prevention protects mission integrity. Secure fabrication underpins secure systems. | SA-8(9) SA-8(11) SA-12 SA-12(1) SR-1 SR-5 |
| SPR-312 | Procedural | Process / Procedure | 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: | • 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). | SR-1 SR-5 |
| SPR-313 | Procedural | Documentation Requirement | 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. | Structured SCRM planning identifies lifecycle risks. Comprehensive coverage ensures holistic oversight. Risk planning mitigates systemic exposure. Governance extends beyond deployment. | SR-2 |
| SPR-314 | Procedural | Documentation Requirement | The [organization] shall protect the supply chain risk management plan from unauthorized disclosure and modification. | Disclosure of SCRM strategy may expose defensive weaknesses. Controlled access preserves operational advantage. Plan integrity prevents tampering. Governance artifacts must be secured. | SR-2 |
| SPR-315 | Procedural | Process / Procedure | The [organization] shall review and update the supply chain risk management plan as required, to address threats, organizational, or environmental changes. | Threat landscapes evolve rapidly. Periodic updates maintain relevance. Adaptive management strengthens resilience. Continuous improvement is essential. | SR-2 |
| SPR-316 | Procedural | Process / Procedure | The [organization] shall establish a supply chain risk management team to lead and support supply chain risk management activities. | Dedicated oversight ensures coordinated supply chain defense. Defined roles improve accountability. Central leadership streamlines mitigation efforts. Organizational focus strengthens resilience. | SR-2(1) |
| SPR-317 | Procedural | Process / Procedure | The [organization] shall employ [organization]-defined techniques to limit harm from potential adversaries identifying and targeting the Program supply chain. | Examples of security safeguards that the organization should consider implementing to limit the harm from potential adversaries targeting the organizational supply chain, are: (1) Using trusted physical delivery mechanisms that do not permit access to the element during delivery (ship via a protected carrier, use cleared/official couriers, or a diplomatic pouch); (2) Using trusted electronic delivery of products and services (require downloading from approved, verification-enhanced sites); (3) Avoiding the purchase of custom configurations, where feasible; (4) Using procurement carve outs (i.e., exclusions to commitments or obligations), where feasible; (5) Using defensive design approaches; (6) Employing system OPSEC principles; (7) Employing a diverse set of suppliers; (8) Employing approved vendor lists with standing reputations in industry; (9) Using a centralized intermediary and “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary Employing inventory management policies and processes; (10) Using flexible agreements during each acquisition and procurement phase so that it is possible to meet emerging needs or requirements to address supply chain risk without requiring complete revision or re-competition of an acquisition or procurement; (11) Using international, national, commercial or government standards to increase potential supply base; (12) Limiting the disclosure of information that can become publicly available; and (13) Minimizing the time between purchase decisions and required delivery. | SR-3(2) SC-38 |
| SPR-318 | Procedural | Process / Procedure | The [organization] shall ensure that the controls included in prime contracts are also included in the contracts of subcontractors. | Security gaps in subcontractors create systemic vulnerabilities. Flow-down requirements enforce consistent standards. Contractual alignment strengthens supply chain assurance. Uniform governance reduces weak links. | SR-3(3) |
| SPR-319 | Procedural | Process / Procedure | The [organization] shall ensure adequate supplies of critical system components. | Examples include: using multiple suppliers throughout the supply chain for critical components, stockpiling spare components to ensure operation during mission-critical times, and the identification of functionally identical or similar components that may be used, if necessary. | SR-5(1) |
| SPR-320 | Procedural | Process / Procedure | The [organization] shall develop and document program-specific configuration management policies and procedures for the hardware and software for the spacecraft. | Clear configuration governance prevents unauthorized modification. Policy-backed processes ensure consistency. Lifecycle control supports traceability. Managed change reduces mission risk. | CM-1 CM-3 CM-5(6) SA-10 SA-10(3) |
| SPR-321 | Procedural | Process / Procedure | The [organization] shall develop and document spacecraft integrity policies covering both hardware and software. | Integrity policies define expectations for hardware and software protection. Formalized governance ensures consistent enforcement. Clear standards reduce ambiguity. Integrity underpins mission trustworthiness. | CM-5(6) SA-10(3) SI-1 SI-7(12) |
| SPR-322 | Technical | Technical Requirement | 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. | 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. | CM-2(3) CM-3(7) CM-4(2) SA-10 SA-10(4) |
| SPR-323 | Deprecated | Deprecated | 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 | Procedural | Documentation Requirement | The [organization] shall inspect system components periodically during development to detect tampering (in accordance with the Anti-Tamper Plan). | 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. | SR-10 |
| SPR-325 | Deprecated | Deprecated | 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. | 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. | SR-11 |
| SPR-326 | Procedural | Process / Procedure | The [organization] shall employ technical means to determine if system components are genuine or have been altered. | 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. | SR-11(3) |
| SPR-327 | Procedural | Standards / ICD Development | The [organization] shall document, monitor, and maintain valid provenance of critical system components and associated data in accordance with the Supply Chain Risk Management Plan. | Traceable provenance reduces supply chain opacity and hidden dependency risk. Documentation of origin enables vulnerability tracking and recall response. Monitoring component lineage strengthens trust in deployed hardware and software. Transparency enhances lifecycle accountability. | SR-4 SR-4(1) SR-4(2) |
| SPR-328 | Procedural | Process / Procedure | The [organization] shall ensure any update to on-board software, memory, or stored procedures has met high assurance standards before execution. | 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. | AC-3(2) CM-3 SA-8(8) SA-8(31) SA-10(2) SR-4(4) |
| SPR-329 | Procedural | Process / Procedure | The [organization] shall perform manual code review of all produced code looking for quality, maintainability, and security flaws. | 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. | SA-11(4) SI-3 SI-3(10) SR-4(4) |
| SPR-330 | Procedural | Process / Procedure | The [organization] shall employ the [organization]-defined approaches for the purchase of the system, system components, or system services from suppliers. | This could include tailored acquisition strategies, contract tools, and procurement methods. | SR-5 |
| SPR-331 | Procedural | Process / Procedure | 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. | This requirement is focused on software and firmware flaws. If hardware flaw remediation is required, refine the requirement to make this clear. | 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) |
| SPR-332 | Procedural | Process / Procedure | 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. | 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. | SR-6(1) |
| SPR-333 | Procedural | Standards / ICD Development | 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. | 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. | SR-9 |
| SPR-334 | Procedural | Documentation Requirement | 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. | Effective anti-tamper requires cross-functional coordination. Alignment prevents gaps between design, manufacturing, and integration. Lifecycle oversight ensures sustained protection. Coordination strengthens enforcement consistency. | SR-9 SR-9(1) |
| SPR-335 | Deprecated | Deprecated | The [organization] shall document the spacecraft's security architecture, and how it is established within and is an integrated part of the Program's mission security architecture. | SA-17 | |
| SPR-336 | Deprecated | Deprecated | The [organization] (and Prime Contractor) shall conduct a supplier review prior to entering into a contractual agreement with a contractor (or sub-contractor) to acquire systems, system components, or system services. | SR-6 | |
| SPR-337 | Procedural | Process / Procedure | The [organization] shall ensure that the list of potential system vulnerabilities scanned is updated [prior to a new scan] | Outdated vulnerability signatures reduce detection capability. Updating scan definitions ensures coverage against emerging threats. Proactive updates prevent blind spots. Continuous refresh strengthens scanning effectiveness. | RA-5(2) SI-3 |
| SPR-338 | Procedural | Process / Procedure | The [organization] shall define the frequency for providing refresher security awareness training to all information system users (including managers, senior executives, and [organization]s). | Regular reinforcement maintains security awareness. Training frequency should reflect mission risk and evolving threat landscape. Structured scheduling ensures consistency. Ongoing education supports defense readiness. | AT-2 |
| SPR-339 | Procedural | Process / Procedure | The [organization] shall ensure that basic security awareness training is provided to all information system users (including managers, senior executives, and [organization]s) as part of initial training for new users, when required by information system changes, and at frequency defined by the [organization]. | Baseline awareness reduces human error and insider risk. Training at onboarding and after system changes ensures up-to-date knowledge. All user levels require awareness, including executives. Human factors remain a core defense layer. | AT-2 |
| SPR-340 | Procedural | Process / Procedure | The [organization] shall determine the mission-specific role security training based on the assigned roles and responsibilities of individuals and the specific security requirements of [organization] and the systems to which personnel have authorized access. | Different roles carry different risk exposure. Tailored training ensures personnel understand mission-specific responsibilities. Context-driven education strengthens compliance. Role clarity reduces misuse risk. | AT-3 |
| SPR-341 | Procedural | Documentation Requirement | The [organization] shall coordinate contingency plan development, and testing of the plan, with organizational elements responsible for related plans. | Integrated contingency planning ensures no isolated failure points. Coordination with related plans improves operational continuity. Structured collaboration strengthens recovery effectiveness. Unified preparation reduces confusion during crisis. | CP-2(1) CP-4(1) |
| SPR-342 | Procedural | Process / Procedure | The [organization] shall test the plan for the transfer of essential functions to alternate processing sites for both the ground and space segment assets to familiarize personnel with the process and to evaluate the ability of the site to continue those functions. | Transfer testing validates ability to sustain operations during disruption. Ground and space segment continuity must be demonstrated. Exercises expose integration gaps. Preparedness supports mission survivability. | CP-4(2) |
| SPR-343 | Technical | Process / Procedure | The [organization] shall develop and document program-specific access control policies for controlling information flow and leakage on-board the spacecraft. | Access control policies must reflect mission architecture and threat environment. Formal documentation ensures consistent enforcement. Leakage prevention requires clear governance. Policy clarity supports compliance and auditing. | AC-1 AC-3 AC-3(3) AC-3(4) AC-3(13) |
| SPR-344 | Deprecated | Deprecated | The [organization] shall have Insider Threat Program to aid in the prevention of people with authorized access to perform malicious activities. | Note: These are not spacecraft requirements but important to call out but likely are covered under other requirements by the customer. | PM-12 AT-2(2) IR-4(7) |
| SPR-345 | Procedural | Process / Procedure | The [organization] shall update the inventory of spacecraft components as an integral part of component installations, removals, and spacecraft updates. | Accurate inventory enables vulnerability tracking and incident response. Lifecycle updates prevent undocumented changes. Asset visibility strengthens security management. Configuration awareness reduces blind spots. | CM-8(1) CA-7 CM-2 CM-3 |
| SPR-346 | Procedural | Process / Procedure | The [organization] shall implement, as part of an A&A process, a Continuous Monitoring Program (CMP) that evaluates the effectiveness of security control implementations on a recurring pre-defined basis. | Ongoing evaluation detects drift in control effectiveness. Continuous monitoring strengthens adaptive defense. Recurring review identifies degradation early. Proactive oversight enhances resilience. | CA-7 PM-31 |
| SPR-347 | Procedural | Process / Procedure | The [organization] shall establish a cross-discipline insider threat incident response & handling team. | Complex insider risks require multi-domain coordination. Cross-functional teams improve detection and response. Unified oversight strengthens accountability. Structured programs deter malicious behavior. | PM-12 |
| SPR-348 | Procedural | Documentation Requirement | The [organization] shall establish policy and procedures to prevent unauthorized personnel from masquerading as personnel with valid access to areas where commanding of the spacecraft is possible. | Unauthorized impersonation risks mission compromise. Physical and logical controls prevent access misuse. Clear policy deters credential abuse. Identity assurance is essential for command authority. | PM-12 |
| SPR-349 | Procedural | Process / Procedure | The [organization] shall establish and maintain a comprehensive program for testing, training, and monitoring to ensure the effectiveness of security controls and incident response capabilities. | Integrated programs ensure controls remain effective. Continuous validation supports adaptive security posture. Combined testing and training reduce complacency. Holistic oversight strengthens mission readiness. | PM-14 |
| SPR-350 | Procedural | Process / Procedure | The [organization] shall screen all personnel supporting management and development to ensure they meet the appropriate ADP/IT level designation requirements IAW DoD 5200.2-R prior to authorizing access to the information or system. | Personnel vetting reduces insider risk exposure. Compliance with DoD screening standards ensures appropriate trust levels. Credentialed access must align with sensitivity. Governance strengthens workforce integrity. | PS-3 |
| SPR-351 | Deprecated | Deprecated | The [organization], upon termination of individual employment, disables information system access within [TBD minutes] of termination. | Prompt access revocation reduces residual insider risk. Delay creates opportunity for misuse. Defined timelines ensure enforceable standards. Termination governance protects system integrity. | PS-4 |
| SPR-352 | Procedural | Process / Procedure | The [organization] shall maintain records of termination/revocation of any authenticators/credentials. | Recordkeeping ensures accountability and traceability. Historical data supports audits and investigations. Documentation strengthens governance oversight. Proper revocation tracking reduces risk of reinstatement errors. | PS-4 |
| SPR-353 | Procedural | Process / Procedure | The [organization] shall, upon termination of individual employment, terminates/revokes any authenticators/credentials associated with the individual. | Immediate revocation prevents credential reuse. Deprovisioning reduces exposure window. Controlled offboarding supports lifecycle security. Identity lifecycle management is critical. | PS-4 |
| SPR-354 | Procedural | Process / Procedure | The [organization], upon termination of individual employment, disables information system access within 3 minutes of termination. | Immediate revocation reduces exposure window. Controlled offboarding supports lifecycle security. Reducing system access helps prevent abuse. | PS-4 |
| SPR-355 | Procedural | Process / Procedure | The [organization] shall implement policies and procedures to support operations security (OPSEC) to protect information about the capabilities and intentions of organizations by identifying, controlling, and protecting information related to the planning and execution of sensitive organizational activities. | Information critical to organizational mission and business functions may include user identities, components in use, suppliers, supply chain processes, functional requirements, security requirements, system design specifications, testing and evaluation protocols, and security control implementation details. | SC-38 |
| SPR-356 | Procedural | Process / Procedure | The [organization] shall have a two-man rule to achieve a high level of security for systems with command level access to the spacecraft.(Under this rule all access and actions require the presence of two authorized people at all times.) | Note: These are not spacecraft requirements but important to call out but likely are covered under other requirements by the customer. | PE-3 |
| SPR-357 | Deprecated | Deprecated | The [organization] defines the security safeguards to be employed to protect the availability of system resources. | CP-2(2) SC-6 SI-13 SI-17 | |
| SPR-358 | Procedural | Concept of Operations (ConOps) | The [organization] shall plan for the transfer of essential ground-segment functions to alternate processing/storage site(s) (e.g.secondary ground terminal) with minimal or no loss of operational continuity until the primary ground terminal is fully restored (if the architecture supports it). | Redundant ground infrastructure enhances availability. Preplanning reduces disruption during outage. Distributed architecture strengthens resilience. Continuity planning supports mission assurance. | CP-2(6) |
| SPR-359 | Procedural | Concept of Operations (ConOps) | The [organization] shall plan for the transfer of essential space-segment functions to alternate processing platforms (e.g.proliferated/distributed constellations) with minimal or no loss of operational continuity until the primary node is fully restored (if the architecture supports it). | Proliferated or distributed space assets reduce single-node risk. Functional transfer ensures mission continuity. Planning anticipates hostile or environmental disruptions. Resilient architectures improve survivability. | CP-2(6) |
| SPR-360 | Procedural | Documentation Requirement | The [organization] shall coordinate contingency plan development and associated activities with external service providers to ensure that contingency requirements can be satisfied. | External dependencies must align with mission continuity plans. Coordination reduces contractual gaps. Shared understanding strengthens recovery capability. Integrated planning supports operational resilience. | CP-2(7) |
| SPR-361 | Technical | Technical Requirement | The [organization] shall maintain 24/7 space situational awareness for potential collision with space debris that could come in contact with the spacecraft. | Collision risk threatens mission availability. Continuous monitoring enables avoidance maneuvers. Situational awareness reduces physical hazard risk. Space domain awareness supports survivability. | PE-20 |
| SPR-362 | Procedural | Process / Procedure | The [organization] shall develop policies and procedures to establish sufficient space domain awareness to avoid potential collisions or hostile proximity operations.This includes establishing relationships with relevant organizations needed for data sharing. | Formal policies ensure structured collision avoidance and hostile proximity response. Data sharing strengthens predictive capabilities. Governance supports coordinated action. Preparedness mitigates orbital hazards. | PE-6 PE-6(1) PE-6(4) PE-18 PE-20 RA-6 SC-7(14) |
| SPR-363 | Procedural | Process / Procedure | The [organization] shall monitor physical access to all facilities where the system or system components reside throughout development, integration, testing, and launch to detect and respond to physical security incidents in coordination with the organizational incident response capability using automated intrusion recognition and predefined responses. | Physical compromise may introduce hardware implants or configuration changes. Monitoring detects unauthorized entry. Integration with IR capability enables rapid response. Physical security underpins cyber integrity. | PE-6 PE-6(1) PE-6(4) PE-18 PE-20 SC-7(14) |
| SPR-364 | Procedural | Process / Procedure | The [organization] shall identify, develop, and document the applicable program security awareness and training policies. | Formal policy establishes training expectations. Documentation ensures consistency across lifecycle. Governance supports measurable compliance. Structured awareness enhances human resilience. | AT-1 |
| SPR-365 | Procedural | Policy / Governance | The [organization] shall develop and maintain Audit and Accountability policy that specifies, at a minimum: the methods and procedures for auditing on-board events; the processes for capturing, recording, and reviewing audit logs; the criteria for audit event selection, frequency of audits, and data retention; the responsibilities for audit management and review. | Clear audit policy defines expectations for logging and review. Structured retention ensures forensic capability. Defined criteria strengthen monitoring consistency. Accountability deters misuse. | AU-1 |
| SPR-366 | Procedural | Process / Procedure | The [organization] shall identify the applicable audit and accountability policies that cover the information on the spacecraft. | Ensuring policy applicability prevents coverage gaps. Alignment ensures consistent governance. Comprehensive audit scope strengthens detection capability. Policy clarity supports enforcement. | AU-1 |
| SPR-367 | Procedural | Documentation Requirement | The [organization] shall develop and document program-specific security assessment and authorization policies and procedures. | Structured A&A policies formalize evaluation processes. Defined methodologies ensure consistent risk evaluation. Clear authorization boundaries prevent ambiguity. Governance strengthens mission trust. | CA-1 |
| SPR-368 | Procedural | Process / Procedure | The [organization] shall have policies that clearly describe the processes and methodologies for conducting security assessments, obtaining authorizations, and performing continuous monitoring activities. | Explicit procedural guidance reduces inconsistency. Defined methodologies improve repeatability. Continuous monitoring integrates assessment into operations. Governance ensures sustained oversight. | CA-1 |
| SPR-369 | Procedural | Documentation Requirement | The [organization] shall develop and document program-specific contingency planning policies to cover the development environment as well as the spacecraft. | Formal contingency governance ensures lifecycle coverage. Development and operational environments both require resilience planning. Documentation supports coordinated response. Policy-backed preparation strengthens continuity. | CP-1 |
| SPR-370 | Deprecated | Deprecated | The [organization] shall develop and document program-specific incident response policies for the spacecraft. | IR-1 | |
| SPR-371 | Procedural | Documentation Requirement | The [organization] shall develop, document, and implement an incident response policy specifically tailored for its space operations that outlines procedures for detecting, reporting, responding to, and recovering from security incidents affecting the spacecraft. | Space-specific IR procedures account for latency and limited intervention. Tailored guidance ensures effective containment. Structured recovery planning reduces mission impact. Specialized policies enhance readiness. | IR-1 |
| SPR-372 | Procedural | Documentation Requirement | The [organization] shall develop and document program-specific system maintenance policies for performing maintenance on the spacecraft hardware (pre-launch) and software (post-launch). | Maintenance must preserve system integrity. Defined policies prevent unauthorized modification. Lifecycle control supports traceability. Maintenance governance strengthens resilience. | MA-1 |
| SPR-373 | Procedural | Documentation Requirement | The [organization] shall develop and document program-specific risk assessment policies. | Formal risk governance ensures consistent evaluation. Documented methodology enhances transparency. Periodic reassessment maintains relevance. Risk management underpins mission assurance. | RA-1 |
| SPR-374 | Procedural | Documentation Requirement | The [organization] shall develop and maintain an overarching document that details policies and procedures regarding system and services acquisition. | Acquisition governance ensures security requirements flow into procurement. Structured oversight reduces supply chain risk. Comprehensive documentation supports compliance. Early integration improves lifecycle protection.F377 | SA-1 |
| SPR-375 | Procedural | Standards / ICD Development | The [organization] shall develop and document program-specific system and communications protection policies in accordance with CNSSP 12. | Alignment with CNSSP 12 ensures compliance with national security requirements. Standardized communications protection strengthens cryptographic assurance. Program-specific tailoring ensures relevance. Policy integration strengthens governance. | SC-1 |
| SPR-376 | Procedural | Process / Procedure | The [organization] shall implement an A&A process that establishes the extent to which a particular design and implementation meet a set of specified security requirements defined by the organization, government guidelines, and federal mandates. | Structured authorization ensures design compliance prior to deployment. Formal assessment reduces oversight gaps. Defined requirements provide measurable criteria. Governance supports mission confidence. | CA-2 |
| SPR-377 | Procedural | Process / Procedure | The [organization] shall conduct control assessments of the information system using independent assessors. | Independent assessors shall be individuals or entities external to the operational chain of command and not involved in the development, implementation, or operations of the system under assessment. | CA-2(1) |
| SPR-378 | Procedural | Process / Procedure | The [organization] shall establish and maintain processes to manage and oversee independent assessors, including their qualifications, roles, and responsibilities. | Independent assessors shall be individuals or entities external to the operational chain of command and not involved in the development, implementation, or operations of the system under assessment. | CA-2(1) CA-7(1) |
| SPR-379 | Procedural | Process / Procedure | The [organization] shall conduct specialized assessments that are specifically tailored for space systems or space missions more generally, as opposed to traditional terrestrial IT systems. | Space missions require threat models distinct from terrestrial IT. Tailored assessments address unique operational constraints. Specialized evaluation improves relevance. Mission-specific review strengthens assurance. | CA-2(2) |
| SPR-380 | Procedural | Process / Procedure | The [organization] shall maintain an up-to-date Plan of Action and Milestones (POA&M) that identifies, assesses, prioritizes, and documents specific actions to be taken to correct deficiencies in the spacecraft's security posture. | A living POA&M tracks remediation progress. Structured prioritization reduces overlooked deficiencies. Documentation ensures accountability. Transparent tracking strengthens governance. | CA-5 |
| SPR-381 | Procedural | Process / Procedure | The [organization] shall designate an authorizing official for the system. | These officials must be federal employees, and are responsible for reviewing the security authorization package, assessing the risks, and making the decision to authorize system operation. They shall ensure compliance with relevant organizational policies and standards and are accountable for the decision to accept the risks associated with operating the system. The authorizing officials must be empowered with the authority to oversee and enforce the implementation and maintenance of security controls in accordance with organizational requirements and applicable regulations. | CA-6 |
| SPR-382 | Procedural | Documentation Requirement | The [organization] shall categorize the system and information it processes in accordance with FIPS 199. | Impact categorization guides control selection. Formal classification ensures proportional protection. Defined impact levels strengthen risk alignment. Compliance supports federal mandate adherence. | RA-2 |
| SPR-383 | Procedural | Process / Procedure | The [organization] shall employ independent assessors or assessment teams to monitor the effectiveness of security controls in the system on an ongoing basis. | Independent review enhances objectivity. Ongoing evaluation detects control degradation. Separation strengthens trust. Independent oversight improves mission resilience. | CA-7(1) |
| SPR-384 | Procedural | Process / Procedure | The [organization] shall modify control implementations, the frequency of continuous monitoring activities, and the types of activities used in the continuous monitoring process based on trend analysis of empirical data. | Empirical data informs adaptive defense. Trend-driven adjustments prevent static control stagnation. Continuous refinement strengthens posture. Data-driven governance enhances effectiveness. | CA-7(3) |
| SPR-385 | Procedural | Process / Procedure | The [organization] shall monitor, as part of the continuous monitoring strategy, the following: implementation of risk response measures; effectiveness of the risk response implementation; configuration changes that may impact security | Monitoring risk response implementation ensures corrective actions are effective. Tracking configuration changes prevents drift. Continuous oversight reduces exposure window. Structured feedback loops strengthen resilience. | CA-7(4) |
| SPR-386 | Procedural | Process / Procedure | The [organization] shall implement automated mechanisms to assist in the execution and implementation of the Continuous Monitoring Program (CMP). | Automation ensures continuous monitoring activities are consistent, repeatable, and not dependent on manual effort. Space systems generate large volumes of telemetry that require automated analysis to detect trends and anomalies. Automation reduces human error and accelerates response timelines. This strengthens adaptive security posture over the mission lifecycle. | CA-7(6) |
| SPR-387 | Procedural | Policy / Governance | The [organization] shall define policy and procedures to ensure that the developed or delivered systems do not embed unencrypted static authenticators in applications, access scripts, configuration files, nor store unencrypted static authenticators on function keys. | Hard-coded or static authenticators create high-value targets for reverse engineering and credential reuse. Preventing embedded unencrypted credentials reduces insider and supply chain exploitation risk. Credential hygiene is critical in long-lived space missions. Eliminating static secrets strengthens identity assurance. | IA-5(7) |
| SPR-388 | Procedural | Process / Procedure | The [organization] shall produce, control, and distribute asymmetric cryptographic keys (where applicable) using NSA Certified or Approved key management technology and processes per CNSSP 12. | Using NSA-certified key management ensures cryptographic integrity and compliance with federal mandates. Proper generation, distribution, and control reduce key compromise risk. High-assurance key lifecycle management underpins command authentication and secure updates. Governance over keys preserves mission trust. | SC-12(3) |
| SPR-389 | Procedural | Process / Procedure | The [organization] shall perform analysis of critical backdoor commands that could adversely affect mission success if used maliciously. | Backdoor or maintenance commands may bypass safeguards if misused. Analysis identifies high-impact commands requiring additional controls. Understanding abuse potential reduces catastrophic misuse. Preventive governance strengthens operational assurance. | SI-10 SI-10(3) |
| SPR-390 | Procedural | Process / Procedure | The [organization] shall ensure that cryptographic mechanisms, including authentication schemes and command dictionaries, are under strict configuration management. | Cryptographic algorithms, keys, and command dictionaries are foundational trust elements. Strict configuration control prevents unauthorized changes that could weaken security. Version tracking supports forensic reconstruction. Governance ensures cryptographic integrity across lifecycle phases. | CM-3(6) |
| SPR-391 | Procedural | Process / Procedure | The [organization] shall release updated versions of the mission information systems incorporating security-relevant software and firmware updates, after suitable regression testing, at a frequency no greater than [Program-defined frequency [90 days]]. | On-orbit patching/upgrades may be necessary if vulnerabilities are discovered after launch. The system should have the ability to update software post-launch. | CM-3(2) CM-4(1) |
| SPR-392 | Technical | Process / Procedure | The [organization] shall review proposed changes to the spacecraft, assessing both mission and security impacts. | Changes may introduce unintended security regression. Structured review balances mission needs with risk tolerance. Joint mission-security assessment prevents single-domain blind spots. Integrated evaluation supports safe modernization. | SA-10 CM-3(2) |
| SPR-393 | Procedural | Concept of Operations (ConOps) | The [organization] shall confirm that the operational spacecrafts correspond to the baseline configuration. | Configuration drift undermines trust and auditability. Confirming alignment ensures deployed assets reflect approved design. Baseline validation supports recovery and compliance. Continuous verification reduces unknown risk. | CM-2 CM-3 CM-3(7) CM-4(2) CM-6 SA-10 |
| SPR-394 | Procedural | Process / Procedure | The [organization] shall implement a two-person rule, or similar dual authorization mechanism, for all changes to the SV configuration, and such actions should only be conducted with documented change control board approval. | Dual authorization reduces insider threat and accidental misconfiguration. Change board approval ensures structured governance. Sensitive changes require accountability. Multi-party validation enhances resilience. | CM-3(8) |
| SPR-395 | Procedural | Process / Procedure | The [organization] shall prohibit the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code. | Closed binaries from unverified sources limit vulnerability inspection. Source availability supports transparency and review. Prohibiting opaque code reduces hidden malicious logic risk. Supply chain integrity depends on verifiability. | CM-7(8) |
| SPR-396 | Procedural | Process / Procedure | The [organization] shall perform configuration management during system, component, or service during [design; development; implementation; operations]. | Configuration discipline ensures traceability from design through operations. Lifecycle oversight prevents undocumented changes. Structured management supports rollback and audit. Configuration integrity underpins mission assurance. | SA-10 |
| SPR-397 | Procedural | Process / Procedure | The [organization] shall create prioritized list of software weakness classes (e.g., Common Weakness Enumerations) to be used during static code analysis for prioritization of static analysis results. | The prioritized list of CWEs should be created considering operational environment, attack surface, etc. Results from the threat modeling and attack surface analysis should be used as inputs into the CWE prioritization process. There is also a CWSS (https://cwe.mitre.org/cwss/cwss_v1.0.1.html) process that can be used to prioritize CWEs. The prioritized list of CWEs can help with tools selection as well as you select tools based on their ability to detect certain high priority CWEs. | SA-11(1) SA-15(7) |
| SPR-398 | Procedural | Process / Procedure | The [organization] shall perform a manual code review of all flight code. | Flight code governs mission-critical behavior. Manual review detects subtle logic flaws missed by automation. Human expertise enhances safety assurance. Defense-in-depth requires layered validation. | SA-11(4) |
| SPR-399 | Procedural | Process / Procedure | The [organization] shall define acceptable coding languages to be used by the software developer. | Standardized languages reduce complexity and maintenance burden. Approved languages support secure development practices. Language governance strengthens code quality and review consistency. Reduced heterogeneity improves assurance. | SA-15 |
| SPR-400 | Procedural | Process / Procedure | The [organization] shall define acceptable secure coding standards for use by the software developers. | Secure coding standards mitigate common vulnerability patterns. Structured guidance reduces CWE-class weaknesses. Enforcing standards promotes predictable behavior. Governance supports sustainable security hygiene. | SA-15 |
| SPR-401 | Procedural | Process / Procedure | The [organization] shall correct reported cybersecurity-related information system flaws. | * Although this requirement is stated to specifically apply to cybersecurity-related flaws, the Program office may choose to broaden it to all SV flaws. * This requirement is allocated to the Program, as it is presumed, they have the greatest knowledge of the components of the system and when identified flaws apply. | SI-2 |
| SPR-402 | Procedural | Process / Procedure | The [organization] shall identify, report, and coordinate correction of cybersecurity-related information system flaws. | Centralized reporting ensures timely remediation. Coordinated correction prevents repeated exposure. Documentation strengthens audit traceability. Rapid flaw management reduces exploitation window. | SI-2 |
| SPR-403 | Procedural | Process / Procedure | The [organization] shall develop and document an inventory of the spacecraft components that accurately reflects the to-be launched system. | Accurate inventory enables vulnerability tracking and configuration validation. Knowing what is deployed supports incident response. Inventory integrity strengthens supply chain assurance. Visibility reduces systemic blind spots. | CM-8 CM-2 |
| SPR-404 | Procedural | Process / Procedure | The [organization] shall establish and formally review the baseline configuration to confirm that it represents an agreed-upon set of specifications for the spacecrafts. | Formal baseline review ensures consensus on spacecraft specifications. Structured validation prevents silent drift. Agreement strengthens accountability. Baseline governance supports mission reliability. | CM-2 CM-6 |
| SPR-405 | Procedural | Process / Procedure | The [organization] shall define/maintain an approved operating system list for use on spacecraft. | The operating system is extremely important to security and availability of the spacecraft, therefore should receive high levels of assurance that it operates as intended and free of critical weaknesses/vulnerabilities. | CM-7(5) |
| SPR-406 | Procedural | Process / Procedure | The [organization] shall track security advisories, patches/updates, and ensure compliance with license agreements and usage restrictions for all software within the SBOM. | Software dependencies evolve over time. Tracking advisories prevents latent vulnerability exposure. SBOM transparency enables rapid risk assessment. Compliance monitoring strengthens lifecycle resilience. | CM-10 |
| SPR-407 | Procedural | Process / Procedure | The [organization] shall maintain a Software Bill of Materials (SBOM) for all software code utilized and continuously update/revise the SBOM for each step in the software lifecycle (to include the deployment of that software). | Continuous SBOM updates ensure accurate dependency tracking. Lifecycle revision captures changes in deployed components. Accurate SBOMs enable vulnerability correlation. Transparency enhances supply chain integrity. | CM-8 |
| SPR-408 | Procedural | Documentation Requirement | The [organization] shall produce a plan for the continuous monitoring of security control effectiveness. The plan shall explicitly cover the space platform and link segment telemetry, automated anomaly detection, and SOC correlation of uplink, crosslink, and payload communications. | Comprehensive coverage ensures both onboard and communication segments are monitored. Telemetry-driven detection strengthens anomaly awareness. SOC correlation integrates space and ground visibility. Structured planning enhances detection capability. | SA-4(8) CP-4(5) PM-31 |
| SPR-409 | Procedural | Process / Procedure | The [organization] shall ensure security representatives are included in all change control board reviews and decisions. | Security oversight during change decisions prevents risk oversight. Cross-functional review reduces blind spots. Integrated governance balances operational urgency with protection. Participation ensures consistent enforcement. | CM-3(4) SA-10(7) |
| SPR-410 | Procedural | Process / Procedure | The [organization] shall define, document, and approve access restrictions associated with changes to the spacecraft. | Changes to spacecraft configuration must be controlled. Clear restrictions prevent unauthorized modification. Structured access governance reduces insider risk. Accountability supports traceability. | CM-5 |
| SPR-411 | Procedural | Process / Procedure | The [organization] shall define and enforce restrictions on activities and transactions permissible when interacting with external systems.These access controls shall be regularly reviewed and updated to align with organizational security policies and requirements. | External systems may introduce compromise pathways. Defined boundaries limit exposure. Regular review ensures alignment with evolving policy. Controlled interfaces strengthen resilience. | AC-20 AC-20(1) AC-20(3) |
| SPR-412 | Procedural | Process / Procedure | The [organization] shall define the criteria (i.e.updates to physical controls) in addition to the frequency for providing refresher physical security awareness training to all information system users (including managers, senior executives, and [organization]s). | Physical access controls protect hardware integrity. Updated criteria reflect evolving threats. Regular reinforcement maintains vigilance. Human factors remain critical. | AT-3(2) |
| SPR-413 | Procedural | Process / Procedure | Clear process ensures personnel understand physical safeguards. Structured training reduces unauthorized access risk. Education strengthens compliance. Physical security supports cyber resilience. | Clear process ensures personnel understand physical safeguards. Structured training reduces unauthorized access risk. Education strengthens compliance. Physical security supports cyber resilience. | AT-3(2) |
| SPR-414 | Procedural | Process / Procedure | The [organization] shall identify and document training activities to include basic security awareness training (per AT-2) and role-based security related training (per AT-3). | Formal documentation ensures traceable compliance. Clear identification distinguishes baseline vs role-based training. Governance ensures consistent implementation. Structured awareness strengthens defense posture. | AT-4 |
| SPR-415 | Procedural | Documentation Requirement | The [organization] shall engage relevant stakeholders to discuss performance impacts/tradeoffs for implementing the desired monitoring approach, document any deviations from initial desired approach, and ensure the Authorizing Official (AO) signs off on the risk posed by the exclusion of the functionality in question. | Aerospace work published in TOR-2019-02178 "Telemetry Security" provides examples of telemetry values that may be useful to monitor for indications of malicious onboard activity (not a comprehensive list): Vehicle Command Counter (VCC) Rejected Command Counter Command Receiver On/Off Mode Command Receivers Received Signal Strength Command Receiver Lock Modes Telemetry Downlink Modes Cryptographic Modes Received Commands System Clock GPS Ephemeris Watchdog Timer (WDT) | AU-2 |
| SPR-416 | Procedural | Documentation Requirement | The [organization] shall identify and document the on-board events and values that will be monitored for indicators of unexpected or malicious activity. | Aerospace work published in TOR-2019-02178 "Telemetry Security" provides examples of telemetry values that may be useful to monitor for indications of malicious onboard activity (not a comprehensive list): Vehicle Command Counter (VCC) Rejected Command Counter Command Receiver On/Off Mode Command Receivers Received Signal Strength Command Receiver Lock Modes Telemetry Downlink Modes Cryptographic Modes Received Commands System Clock GPS Ephemeris Watchdog Timer (WDT) | AU-2 |
| SPR-417 | Procedural | Documentation Requirement | The [organization] shall use automated mechanisms to: prohibit changes to the system until designated approvals are received; document all implemented changes to the system; document proposed changes to the system; highlight proposed changes to the system that have not been approved or disapproved by [time_period]; notify [authorities] of proposed changes to the system and request change approval; notify [personnel] when approved changes to the system are completed; and prohibit changes to the system until designated approvals are received. | Automation enforces approval workflows and prevents unauthorized modification. Structured documentation improves audit traceability. Notifications ensure accountability. Automated governance reduces human error. | CM-3(1) |
| SPR-418 | Procedural | Concept of Operations (ConOps) | The [organization] shall define a process to limit privileges to change system components and system-related information within a production or operational environment. | Operational environments require strict change control. Limiting privileges reduces insider exploitation risk. Controlled modification protects mission stability. Governance supports reliability. | CM-5(5) |
| SPR-419 | Procedural | Process / Procedure | The [organization] shall periodically review the spacecraft and subsystems to identify and disable unnecessary and/or nonsecure functions, ports, protocols, software, and services. | Unused services expand attack surface. Periodic review removes exploitable vectors. Simplification enhances predictability. Surface reduction strengthens defensive posture. | CM-7(1) |
| SPR-420 | Technical | Technical Requirement | The [organization] shall employ automated mechanisms to maintain an up-to-date inventory of spacecraft components, including automatic ingestion of on‑orbit inventory delta reports produced by the [spacecraft]. | Automated ingestion ensures accurate and timely asset visibility. On-orbit delta reporting captures configuration drift. Real-time inventory supports anomaly detection. Visibility underpins governance. | CM-8(2) |
| SPR-421 | Technical | Technical Requirement | The [organization] shall employ automated mechanisms to detect unauthorized components within the spacecraft component inventory. | Unauthorized hardware or firmware may introduce implants. Automated detection reduces supply chain risk. Inventory validation strengthens assurance. Continuous monitoring prevents silent compromise. | CM-8(3) |
| SPR-422 | Technical | Technical Requirement | The [organization] shall establish and maintain an accountability mechanism for tracking individuals responsible for spacecraft components (e.g.assign components to individuals within inventory documentation). | Assigning responsibility enhances traceability and oversight. Accountability deters negligent handling. Clear ownership supports configuration integrity. Governance reinforces trust. | CM-8(4) |
| SPR-423 | Technical | Technical Requirement | The [organization] shall develop, document, and implement a Configuration Management Plan for the spacecraft that defines the processes, procedures, and responsibilities for managing configuration changes and ensuring the security of the system. | A formal CMP defines structured change governance. Clear roles and procedures reduce ambiguity. Lifecycle configuration control supports security enforcement. Documented processes strengthen compliance. | CM-9 |
| SPR-424 | Procedural | Documentation Requirement | The [organization] shall ensure that all personnel involved in configuration management activities are trained and follow the procedures outlined in the Configuration Management Plan. | Effective CM requires knowledgeable practitioners. Training ensures adherence to documented procedures. Skilled personnel reduce configuration drift. Governance effectiveness depends on execution. | CM-9 |
| SPR-425 | Procedural | Documentation Requirement | The [organization] shall regularly update the Configuration Management Plan to reflect changes in the information system and to align with evolving security requirements. | Evolving threats necessitate plan updates. Regular revision maintains relevance. Continuous improvement supports adaptive defense. Governance must remain dynamic. | CM-9 |
| SPR-426 | Procedural | Process / Procedure | The [organization] shall designate a supply chain coordinator as part of the incident handling process to facilitate communication and coordination between incident response teams and relevant stakeholders, including suppliers, vendors, and other entities within the supply chain. | Central coordination improves communication during incidents. Defined liaison strengthens supplier engagement. Structured oversight reduces fragmented response. Supply chain integration supports resilience. | IR-4(10) |
| SPR-427 | Procedural | Process / Procedure | The [organization] shall identify the appropriate control baseline (NIST or CNSS) for the spacecraft based on mission information types and associated impact. | Selecting correct baseline ensures proportional protection. Mission impact drives control rigor. Structured alignment supports compliance. Accurate baseline selection strengthens assurance. Space Platform Overlay (CNSS 1253 Appendix F is recommended) | PL-10 |
| SPR-428 | Procedural | Process / Procedure | The [organization] shall develop and implement a process for tailoring the control baseline for the spacecraft in accordance with organizational requirements (e.g.CNSS Space Overlay or similar). | Tailoring aligns controls with mission architecture and threat model. Structured customization prevents over- or under-protection. Governance ensures justified deviations. Tailoring improves efficiency and resilience. | PL-11 |
| SPR-429 | Procedural | Concept of Operations (ConOps) | The [organization] shall develop, document, and implement policies that outline security planning processes such as writing rules of behavior, conops documentation, control baseline selection/tailoring, and similar activities that require advanced planning. | Advanced planning integrates security into operational doctrine. Documented processes ensure consistency. Structured governance reduces ambiguity. Preparation strengthens mission readiness. | PL-11 |
| SPR-430 | Procedural | Process / Procedure | The [organization] shall employ privileged access authorization to applications and components for vulnerability scanning activities. | Scanning requires elevated permissions. Controlled authorization prevents misuse. Clear privilege boundaries reduce exposure. Governance balances testing with protection. | RA-5(5) |
| SPR-431 | Procedural | Documentation Requirement | The [organization] shall include the following requirements, descriptions, and criteria, explicitly or by reference, in the acquisition of a system, system component, or system service: a.Functional security requirements; b.Strength of mechanism requirements; c.Security assurance requirements; d.Controls needed to satisfy the security requirements.e.Security documentation requirements; f.Requirements for protecting security documentation; g.Description of the system development environment and environment in which the system is intended to operate; h.Allocation of responsibility or identification of parties responsible control implementation and continuous monitoring/enforcement throughout the system life cycle; and i.Acceptance criteria. | Security must be embedded in procurement documentation. Explicit criteria prevent ambiguity. Defined acceptance standards ensure compliance. Acquisition governance strengthens supply chain assurance. | SA-4 |
| SPR-432 | Procedural | Process / Procedure | The [organization] shall require the developer of the system, system component, or system services to provide a description of the functional properties of the controls to be implemented. | Understanding control behavior ensures accurate evaluation. Clear functional descriptions support validation. Transparency improves assessment quality. Governance requires documented control intent. | SA-4(1) |
| SPR-433 | Procedural | Documentation Requirement | The [organization] shall require the developer of the system, system component, or system services to provide design and implementation information for the controls that includes low-level security-relevant design information, source code, and hardware schematics. | 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. | SA-4(2) |
| SPR-434 | Technical | Process / Procedure | The [organization] shall determine criteria for unusual or unauthorized activities or conditions for all communications to/from the spacecraft. | Clear anomaly criteria enable consistent detection. Defined thresholds prevent subjective interpretation. Structured definitions strengthen monitoring logic. Proactive detection improves response speed. | SI-4(4) |
| SPR-435 | Procedural | Process / Procedure | 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. | 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). | SA-3 SA-3(1) SA-8(9) SA-8(11) SA-12 SA-12(1) SR-1 SR-5 |
| SPR-436 | Deprecated | Deprecated | 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]. | 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. | SA-3 SA-4(3) |
| SPR-437 | Procedural | Process / Procedure | The [organization] shall enable integrity verification of software and firmware components. | * 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. | 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) |
| SPR-438 | Procedural | Process / Procedure | 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. | 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. | SA-8(9) SA-8(11) SA-12 SA-12(1) SR-1 SR-5 |
| SPR-439 | Procedural | Process / Procedure | 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. | 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). | SA-8(9) SA-8(11) SA-8(21) SA-12 SA-12(1) SR-1 SR-4(4) SR-5 |
| SPR-440 | Procedural | Process / Procedure | 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. | 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. | SR-1 SR-5 |
| SPR-441 | Procedural | Process / Procedure | 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. | 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). | SR-1 SR-5 |
| SPR-442 | Procedural | Process / Procedure | 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. | 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). | SR-1 SR-5 |
| SPR-443 | Deprecated | Deprecated | 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. | SR-1 SR-5 | |
| SPR-444 | Procedural | Process / Procedure | 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. | 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. | SR-1 SR-5 |
| SPR-445 | Procedural | Process / Procedure | 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. | 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). | SR-1 SR-5 |
| SPR-446 | Procedural | Process / Procedure | The [organization] shall enable integrity verification of hardware components. | * 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. | SA-10(3) SA-8(21) SA-10(3) SC-51 |
| SPR-447 | Procedural | Process / Procedure | The [organization] shall have physical security controls to prevent unauthorized access to the systems that have the ability to command the spacecraft. | Note: These are not spacecraft requirements but important to call out but likely are covered under other requirements by the customer. | PE-3 |
| SPR-448 | Procedural | Process / Procedure | The [organization] shall define security requirements/configurations for development environments to prevent the compromise of source code from supply chain or information leakage perspective. | Source code should be classified as Controlled Unclassified Information (CUI) or formally known as Sensitive but Unclassified. Ideally source code would be rated SECRET or higher and stored on classified networks. NIST 800-171 is insufficient when protecting highly sensitive unclassified information and more robust controls from NIST SP 800-53 and CNSSI 1253 should be employed. Greater scrutiny must be applied to all development environments. | SA-15 |
| SPR-449 | Technical | Technical Requirement | The [spacecraft] shall enforce mandatory access control over subjects and objects. | MAC ensures centrally enforced policy cannot be overridden by subjects. Strong policy binding reduces discretionary abuse. Deterministic enforcement enhances mission protection. Strict separation strengthens confidentiality and integrity. | AC-3 AC-3(3) |
| SPR-450 | Technical | Technical Requirement | The [spacecraft] shall prevent flight software and payload applications from modifying access control labels or rules and shall validate label integrity at startup and during policy updates. | Label integrity ensures policy decisions remain trustworthy. Preventing modification protects data classification enforcement. Validation at startup prevents persistent compromise. Policy integrity underpins MAC assurance. | AC-3(3) AC-3(11).AC-16 SI-7 |
| SPR-451 | Technical | Technical Requirement | The [spacecraft] shall ingest [organization]-defined revocation updates to onboard access control lists and attribute sets and shall enforce revocation within [Program-defined time] of receipt. | Timely revocation prevents continued access by compromised identities. Defined enforcement timelines reduce residual exposure. Structured update ingestion strengthens identity governance. Rapid revocation reduces insider and key compromise risk. | AC-3(8) |
| SPR-452 | Technical | Technical Requirement | The [spacecraft] shall deny commands, data requests, and connections from revoked identities and shall generate an audit record for each denial. | Explicit denial and logging strengthens accountability. Automated enforcement reduces reliance on manual monitoring. Recorded denials support forensic investigation. Policy adherence strengthens defense. | AC-3 AC-3(8) AU-2 AU-12 |
| SPR-453 | Technical | Technical Requirement | The [spacecraft] shall restrict any override of access control mechanisms to [Program-defined emergency conditions] and shall generate an auditable event for each invocation that includes the time, origin, justification code, affected functions, and exit status. | Overrides introduce risk and must be tightly constrained. Auditable invocation ensures accountability. Time-limited emergency use reduces misuse potential. Structured control preserves integrity. | AC-3 AC-3(10) AU-2 AU-3 |
| SPR-454 | Technical | Interface Control (ICD) / Standard | The [spacecraft] shall tag telemetry and logs produced during override and shall automatically restore standard enforcement when exit conditions are met or after [Program-defined timeout]. | Override transparency ensures operators are aware of elevated state. Automatic restoration prevents lingering weakened posture. Structured tagging supports audit and review. Governance reduces accidental persistence. | AC-3(10) AU-3 AU-12 |
| SPR-455 | Technical | Technical Requirement | The [spacecraft] shall restrict access to flight software executables, cryptographic material, command dictionaries, and [organization]-defined sensitive payload data to the privileged execution domain and shall deny all other access by default. | Flight executables and cryptographic materials are high-value targets. Restricting access reduces exploitation pathways. Default deny enforces least privilege. Segmentation enhances resilience. | AC-3(11) AC-6 |
| SPR-456 | Technical | Technical Requirement | The [spacecraft] shall implement OS or hardware enforcement for these restrictions and shall log any attempted access violations. | Hardware-enforced policy is harder to bypass than software-only controls. Logging violations supports detection and response. Layered enforcement strengthens assurance. Technical barriers reinforce governance intent. | AC-3 AC-3(11) |
| SPR-457 | Technical | Technical Requirement | The [spacecraft] shall verify cryptographic integrity and origin of data at each relay hop before forwarding information between internal components, payloads, crosslinks, and ground. | End-to-end security alone is insufficient in multi-hop spacecraft architectures. Verifying integrity and origin at each relay prevents compromised subsystems from forwarding malicious data laterally. Hop-by-hop validation limits propagation of injected commands or payload tampering. This enforces zero-trust principles internally. | CA-3(7) SC-8(1) SC-13 SC-23 |
| SPR-458 | Technical | Technical Requirement | The [spacecraft] shall enforce [organization]-defined domain based routing policies that restrict which subsystems may relay information to one another. | Domain segmentation prevents unrestricted lateral data movement. Restricting which subsystems may relay information reduces cross-domain compromise risk. Routing policy enforcement supports least privilege and mission isolation. Structured boundaries strengthen resilience. | CA-3(7) AC-4 |
| SPR-459 | Technical | Technical Requirement | The [spacecraft] shall validate security labels or tags on received data and shall drop or quarantine content with missing, invalid, or downgraded labels. | Label validation ensures data classification and access control integrity. Dropping or quarantining downgraded or malformed labels prevents policy bypass. Enforced label integrity supports mandatory access control. | AC-16 |
| SPR-460 | Technical | Technical Requirement | The [spacecraft] shall record transitive forwarding decisions and rejections in cyber relevant audit data for downlink. | Audit records of forwarding and rejection decisions enable forensic reconstruction. Visibility into routing logic prevents covert channel abuse. Logged rejections demonstrate enforcement of policy. Downlink visibility strengthens ground oversight. | CA-3(7) AU-3 AU-12 |
| SPR-461 | Technical | Technical Requirement | The [spacecraft] shall fail over mission critical processing to a redundant onboard compute element while maintaining authentication, authorization, and cryptographic protections. | Redundant compute without preserved security controls introduces new risk. Failover must maintain authentication and cryptographic state. Secure redundancy prevents availability from undermining integrity. Resilience must not weaken protection. | CP-2(6) CP-10 |
| SPR-462 | Technical | Technical Requirement | The [spacecraft] shall support delegation of temporary data storage to [organization]-authorized alternate nodes or spacecraft and shall preserve confidentiality, integrity, and access controls for the delegated data. | Delegated storage or processing expands trust boundaries. Maintaining CIA protections during delegation prevents exposure. Secure federation supports constellation-based architectures. Controlled delegation strengthens distributed resilience. | CP-2(6) SC-28 AC-3 |
| SPR-463 | Technical | Technical Requirement | The [spacecraft] shall maintain configuration and cryptographic synchronization required to activate alternate processing or storage and shall verify the alternate before activation. | Activation of alternate nodes requires synchronized keys and configurations. Unsynchronized failover risks data corruption or exposure. Verification before activation prevents propagation of compromised states. Coordinated readiness supports secure recovery. | CP-2(6) CM-2 |
| SPR-464 | Technical | Technical Requirement | The [spacecraft] shall accept command and telemetry sessions from [organization]-authorized alternate ground or relay providers only when presented with valid cryptographic credentials and whitelisted link characteristics. | Accepting sessions only from authorized, cryptographically verified providers prevents rogue ground station compromise. Whitelisted link characteristics reduce spoofing risk. Strict admission control strengthens link-layer assurance. This supports TRANSEC alignment. | AC-17 SC-23 |
| SPR-465 | Technical | Technical Requirement | The [spacecraft] shall provide configurable allowlists for external service providers and shall disable or revoke provider access within one contact upon Program direction. | External providers must be tightly governed. Configurable allowlists permit controlled flexibility. Revocation within one contact minimizes compromise dwell time. Agile credential governance strengthens mission continuity. | CP-2(7) AC-20 |
| SPR-466 | Technical | Technical Requirement | The [spacecraft] shall support rapid rollover of communications credentials to restore secure operations with an alternate provider. | Credential compromise requires immediate remediation capability. Rapid rollover restores secure communications without prolonged outage. Agility prevents mission interruption. Cryptographic agility is foundational to resilience. | SC-12 IA-5 |
| SPR-467 | Technical | Technical Requirement | The [spacecraft] shall maintain an onboard inventory of mission components, including unique identifiers, firmware versions or hashes, configuration state, and operational status, and shall downlink the inventory at [organization]-defined intervals and upon any change. | Real-time inventory visibility enables anomaly detection and supply chain verification. Downlinked fingerprints support ground-based validation. Continuous attestation strengthens configuration assurance. Transparency reduces silent tampering risk. | PE-20 CM-8 |
| SPR-468 | Technical | Technical Requirement | The [spacecraft] shall detect and report the connection of any unauthorized or unknown component to onboard interfaces. | Hardware implants pose existential mission risk. Detection of unknown components prevents covert insertion. Automated alerting reduces dwell time. Inventory integrity supports physical security. | PE-20 CM-8(3) SI-4 |
| SPR-469 | Technical | Technical Requirement | The [spacecraft] shall log component activation, deactivation, replacement, and firmware updates with timestamps that map to UTC. | Lifecycle logging ensures traceability. UTC mapping supports synchronized forensic analysis. Transparent change history reduces repudiation. Logging strengthens accountability. | AU-3 AU-8 |
| SPR-470 | Deprecated | Deprecated | The [spacecraft] shall protect mission-critical electronics, power, and RF interfaces against electromagnetic pulse environments at [organization]-defined levels by employing surge suppression, filtering, and shielding, and shall verify compliance by ground testing prior to launch. | ||
| SPR-471 | Technical | Technical Requirement | The [spacecraft] shall preserve trusted boot and cryptographic key storage functionality under EMP conditions by locating those functions within hardened, power-conditioned domains. | Electromagnetic disruption is a realistic space threat. Hardening trusted boot and key storage ensures continuity of secure startup. Protection of root-of-trust preserves system integrity. Resilient design supports adversarial environments. | PE-21 |
| SPR-472 | Procedural | Process / Procedure | The [organization] shall define mission and business processes that map mission objectives to space-segment security requirements, including safe-mode criteria, secure uplink and downlink obligations, and recovery procedures, and shall baseline these processes under configuration control. | Security must align with mission objectives. Explicit mapping ensures safe-mode criteria and communication obligations are controlled. Baseline governance prevents undocumented deviations. Integration supports mission assurance. | PM-11 PL-2 CM-2 |
| SPR-473 | Technical | Technical Requirement | The [organization] shall establish a threat awareness program that provides mission-relevant cyber and EW threat briefings and advisories to spacecraft engineering, integration, and operations personnel at an [organization]-defined frequency, and shall track completion. | Continuous threat awareness informs engineering decisions. Structured briefings reduce blind spots. Tracking completion ensures accountability. Knowledge improves preparedness. | PM-16 |
| SPR-474 | Procedural | Process / Procedure | The [organization] shall incorporate space cyber threat scenarios and mitigations into mission rehearsals and anomaly response training. | Realistic exercises validate preparedness. Embedding cyber threats in rehearsals strengthens operational readiness. Scenario-based training reduces reaction latency. Prepared teams enhance resilience. | PM-16 IR-2 |
| SPR-475 | Procedural | Process / Procedure | The [organization] shall implement automated mechanisms to ingest, validate, and distribute space-relevant threat intelligence to [organization]-defined recipients, and to format uplinkable indicators or signatures for onboard detection capabilities where applicable. | Timely ingestion and distribution of space-relevant intelligence reduces exposure. Formatting indicators for onboard use supports proactive detection. Automation accelerates defensive posture. Integration supports adaptive security. | SI-5 PM-16(1) |
| SPR-476 | Procedural | Process / Procedure | 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. | Mission-critical suppliers require elevated scrutiny. Contractual language enforces security standards. Periodic audits reduce supply chain risk. Oversight strengthens systemic assurance. | PM-30(1) SR-6 SR-3 |
| SPR-477 | Procedural | Process / Procedure | The [organization] shall require independent testing and inspection of mission-critical components prior to integration to verify hardware integrity and cryptographic module assurance. | 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. | PM-30(1) SR-11 |
| SPR-478 | Procedural | Process / Procedure | The [organization] shall map supplier failure impact to mission functions and assign risk-based oversight and acceptance criteria. | 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. | PM-30(1) SR-2 RA-3 |
| SPR-479 | Procedural | Concept of Operations (ConOps) | 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. | Defining authorized and prohibited functions prevents scope creep. Clear purposing bounds updates and operational use. Governance limits misuse potential. Structured baseline supports disciplined operations. | PM-32 PL-8 |
| SPR-480 | Procedural | Process / Procedure | The [organization] shall conduct technical surveillance countermeasures surveys of integration, test, and storage facilities for spacecraft and link-segment equipment to detect covert devices or unauthorized transmissions prior to launch, and shall document and remediate findings. | Pre-launch surveillance reduces covert hardware risk. Detecting unauthorized transmissions prevents compromise before orbit. Documented remediation strengthens assurance. Physical inspection complements cyber controls. | RA-6 PE-18 |
| SPR-481 | Procedural | Documentation Requirement | The [organization] shall define and document data ownership for mission data types across the space platform and link segment, including authority over classification, storage, retention, distribution, cross-domain transfer, and decommissioning. | Clear authority over mission data reduces ambiguity. Defined classification and retention policies prevent mishandling. Ownership governance strengthens accountability. Structured control supports compliance. | SA-4(12) |
| SPR-482 | Procedural | Process / Procedure | The [organization] shall require alternative configuration management and acceptance processes for suppliers lacking mature CM, including trusted build reproduction, cryptographic evidence of provenance, and hardware-in-the-loop acceptance testing prior to integration. | Suppliers lacking mature CM require compensating controls. Trusted build reproduction and cryptographic evidence reduce risk. Hardware-in-the-loop testing validates integration integrity. Structured mitigation preserves assurance. | SA-10(2) CM-2 |
| SPR-483 | Procedural | Process / Procedure | 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. | Controlled builds prevent unauthorized code injection. Reproducible builds strengthen supply chain transparency. Golden images support rollback and forensic validation. Configuration control strengthens integrity. | SA-10(4) |
| SPR-484 | Technical | Design Constraint | The [organization] shall employ interactive application security testing within spacecraft simulation or hardware-in-the-loop test benches to observe flight software runtime behavior, capture memory use, API calls, and data flows, and shall identify and report vulnerabilities prior to integration. | Runtime behavior analysis detects dynamic vulnerabilities. Hardware-in-the-loop testing reveals integration flaws. Early detection reduces costly remediation. Testing strengthens secure development lifecycle. | SA-11(9) |
| SPR-485 | Procedural | Process / Procedure | The [organization] shall require that IAST results are recorded as assessment evidence and shall block promotion of builds with unresolved high-severity findings to the flight baseline. | Preventing promotion of vulnerable builds protects mission integrity. Enforced gating ensures accountability. Security evidence supports auditability. Quality control strengthens assurance. | SA-11(9) |
| SPR-486 | Technical | Technical Requirement | The [spacecraft] shall structure security-relevant software and firmware into cohesive modules that expose only [organization]-approved interfaces and prevent unintended cross-module data or control flow. | Cohesive modules reduce unintended coupling. Limited interfaces prevent cross-module exploitation. Clear boundaries strengthen isolation. Structured architecture supports resilience. | SC-3 SC-3(4) |
| SPR-487 | Technical | Technical Requirement | The [spacecraft] shall verify during integration that modules providing security functions are isolated from non-security modules and that dependencies are limited to documented interfaces. | Integration validation ensures isolation is effective. Limiting dependencies reduces lateral risk. Structured interface enforcement strengthens policy assurance. Verification prevents silent drift. | SC-3 SC-3(4) |
| SPR-488 | Technical | Interface Control (ICD) / Standard | The [spacecraft] shall implement traffic flow security on uplink, downlink, and crosslink communications to conceal or randomize transmission timing, size, and observable patterns, using [organization]‑defined techniques such as padding or constant‑rate telemetry, randomized schedules, or filler traffic in accordance with the System TRANSEC Plan. The [spacecraft] shall ensure traffic flow security does not disable required authentication or encryption and shall coordinate implementation with TRANSEC and anti‑fingerprinting measures. | Concealing traffic patterns reduces adversary inference capability. Padding and scheduling obscure operational tempo. Coordination with TRANSEC ensures layered protection. Traffic flow security enhances confidentiality. | SC-8(4) SC-40 |
| SPR-489 | Technical | Technical Requirement | The [spacecraft] shall host privileged functions, including flight control and cryptographic key management, in physically separate processing domains that have no direct data bus connectivity to non privileged domains. | Hardware-level separation prevents software bypass. Isolation protects flight control and key management. Physical boundaries strengthen trust. Segmentation enforces zero-trust architecture. | SC-3 SC-32(1) SC-39 |
| SPR-490 | Technical | Technical Requirement | The [spacecraft] shall ensure cross domain exchanges occur only through [organization] defined, verified guards that enforce format, rate, and content checks. | Verified guards ensure controlled data exchange. Format and rate checks prevent covert channel exploitation. Enforced mediation supports mandatory control. Guarded exchange strengthens isolation. | AC-4 SC-7 SC-32(1) |
| SPR-491 | Technical | Interface Control (ICD) / Standard | The [spacecraft] shall employ transmission security techniques that conceal or randomize RF signal parameters, including modulation, timing, and power characteristics, to prevent signal fingerprinting and association in accordance with the System TRANSEC Plan. Implementation and verification shall be coordinated with TRANSEC and Traffic Flow Security. | Concealing RF characteristics prevents signal fingerprinting. Randomization reduces tracking and targeting risk. Coordinated TRANSEC alignment strengthens defense. Signal agility enhances survivability. | SC-8 SC-40(4) |
| SPR-492 | Technical | Technical Requirement | The [spacecraft] shall update signal parameter selections using cryptographically sound PRNG inputs at [organization]‑defined intervals or triggers, coordinated with TRANSEC and Traffic Flow Security. | Predictable signal patterns enable adversary exploitation. Strong PRNG inputs ensure randomness integrity. Coordinated update intervals prevent synchronization attacks. Cryptographic randomness strengthens concealment. | SC-8 SC-12 SC-40(4) |
| SPR-493 | Technical | Technical Requirement | The [spacecraft] shall ensure that security-critical functions, including cryptographic processing, key storage, secure boot, and audit logging, continue under single-component failure by providing redundancy, graceful degradation, or verified fallback modes. | Single-point failure in security undermines mission assurance. Redundancy ensures continued enforcement. Graceful degradation maintains CIA protections. Fault tolerance supports resilience. | SI-13 SC-24 |
| SPR-494 | Technical | Technical Requirement | The [spacecraft] shall preserve and protect a golden backup of security credentials and integrity anchors and shall restore them automatically when corruption is detected. | Protected backups enable secure recovery from corruption. Automatic restoration reduces downtime. Integrity anchors preserve trust. Backup governance strengthens resilience. | SI-13 CP-9 |
| SPR-495 | Technical | Technical Requirement | The [spacecraft] shall detect impending failure of security components and initiate controlled failover to preserve confidentiality, integrity, and availability. | Early detection prevents cascading compromise. Controlled switchover maintains CIA properties. Structured alerting enhances situational awareness. Fault handling preserves assurance. | SI-4 SI-13 CP-10 |
| SPR-496 | Technical | Technical Requirement | The [spacecraft] shall provide standby instances for [organization]-defined high-criticality security components and automatically switch to the standby upon failure detection, generating an immediate alert that includes the component identity, time, and fault reason. | Automatic failover reduces human delay. Immediate alerts support oversight. Identity and fault logging strengthen accountability. Resilient architecture supports mission continuity. | SI-13(4) CP-10 AU-5 |
| SPR-497 | Technical | Technical Requirement | The [spacecraft] shall verify the standby component integrity before activation using stored signatures and shall revert if verification fails. | Failover to compromised standby defeats purpose. Signature verification ensures trust continuity. Reversion prevents propagation of corruption. Validation strengthens resilience. | SI-13(4) |
| SPR-498 | Technical | Design Constraint | The [spacecraft] shall minimize persistence of sensitive data and cryptographic material by using ephemeral session keys stored only in volatile memory and purging them upon session end, mode change, or power cycle. | Minimizing persistence reduces exposure window. Volatile storage prevents residual compromise. Automatic purge enforces key hygiene. Ephemerality strengthens confidentiality. | SI-14 |
| SPR-499 | Technical | Design Constraint | The [spacecraft] shall automatically zeroize temporary buffers, caches, and shared resources after use. | Temporary buffers may contain sensitive data. Automatic clearing prevents forensic extraction. Zeroization reduces residual exposure. Memory hygiene strengthens protection. | SI-14 |
| SPR-500 | Technical | Technical Requirement | The [spacecraft] shall avoid storing sensitive operational data in nonvolatile memory unless required by mission, and if stored, it shall be encrypted and retained only for [organization]-defined durations. | Minimizing nonvolatile storage reduces compromise surface. Encrypted storage protects required retention. Defined retention periods prevent indefinite exposure. Controlled persistence supports compliance. | SI-14 |
| SPR-501 | Procedural | Documentation Requirement | The [organization] shall assign and record unique cryptographic identities for flight-critical hardware components, firmware images, and software builds and shall maintain an authoritative registry mapping identities to approved suppliers and versions. | Unique identities enable provenance tracking. Registry mapping supports supplier validation. Identity governance strengthens supply chain assurance. Structured attestation supports lifecycle integrity. | SR-4(1) IA-3 |
| SPR-502 | Technical | Technical Requirement | The [spacecraft] shall report component and software identities and version fingerprints in telemetry at boot and upon changes to support provenance verification. | On-orbit reporting enables real-time provenance verification. Version fingerprints support anomaly detection. Transparency reduces silent drift. Telemetry-based attestation strengthens oversight. | SR-4(1) IA-3 |
| SPR-503 | Procedural | Process / Procedure | 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) | Receipt validation prevents counterfeit or tampered parts integration. Program-controlled trust anchors ensure consistency. Early detection reduces downstream risk. Intake verification strengthens SCRM posture. | SR-4(3) SR-11 SI-7 |
| SPR-504 | Procedural | Process / Procedure | 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. | Installation-time validation prevents stale or revoked components. Ledger recording strengthens traceability. Blocking on mismatch prevents compromise propagation. Continuous verification enhances assurance. | SR-4(3) SR-11 SI-7 |
| SPR-505 | Technical | Technical Requirement | The [spacecraft] shall cryptographically verify boot images and configurations at power-on and after any update | 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. | SR-4(3) SI-7 CM-14 |
| SPR-506 | Procedural | Process / Procedure | 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. | Signed pedigree documents manufacturing and handling lineage. Chain-of-custody transparency reduces counterfeit risk. Ledger tracking strengthens auditability. Supply chain evidence supports mission trust. | SR-4(4) SR-6 |
| SPR-507 | Procedural | Process / Procedure | 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. | 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. | SR-4(4) SR-6 |
| SPR-508 | Procedural | Process / Procedure | 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 | 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. | SR-4(4) SR-11 PE-16 |
| SPR-509 | Procedural | Process / Procedure | 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. | 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. | SR-4(4) SR-3 SR-5 |
| SPR-510 | Procedural | Process / Procedure | 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. | 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. | SR-11(3) |
| SPR-511 | Procedural | Documentation Requirement | 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. | Immediate quarantine prevents contaminated integration. Formal incident tracking ensures accountability. Supplier corrective actions reduce recurrence risk. Structured containment strengthens resilience. | SR-11(3) IR-6 |
| SPR-512 | Procedural | Process / Procedure | 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. | Tool calibration ensures detection reliability. Competency tracking strengthens operator assurance. Compliance documentation supports audit readiness. Precision supports integrity validation. | SR-11(3) |
| SPR-513 | Procedural | Policy / Governance | The [organization] shall develop and maintain a phase‑ and mode‑aware access control policy for the mission that maps operator/station identities to command families and pass windows, defines on‑orbit key lifecycle (generation, activation, rotation, retirement), session establishment/renewal/teardown behaviors, and time‑synchronization assumptions across space and ground; the policy shall be validated in simulators/flatsats. | Access requirements vary by mission phase and spacecraft mode. Explicit mapping prevents inappropriate command authority. Simulator validation ensures policy feasibility. Context-aware governance supports Zero Trust principles. | AC-1 PL-2 |
| SPR-514 | Technical | Technical Requirement | The [spacecraft] shall emit a standardized accept/reject reason code for every telecommand, including mode/precondition results, parameter/range/sequence checks, and rate/temporal‑limit evaluations, and shall include the code in downlinked audit. | Consistent reason codes enhance operator clarity and forensic traceability. Transparent rejection rationale reduces ambiguity. Downlinked codes support ground analysis. Deterministic feedback strengthens accountability. | AU-3 AU-12 |
| SPR-515 | Technical | Technical Requirement | The [spacecraft] shall enforce discretionary access on [organization]-defined payload data stores using short‑lived, purpose‑specific grants bound to execution windows or end‑of‑pass, with automatic expiration, audited changes/uses, and integrity checks on permission metadata that survive resets/SEUs. | Ephemeral grants reduce persistence risk. Execution-window binding prevents privilege creep. Surviving SEUs ensures metadata integrity. Time-bounded access supports least privilege. | AC-3(4) |
| SPR-516 | Technical | Design Constraint | 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. | Discovery mechanisms can leak sensitive timing or state information. Guardrails restrict beacon content to non-sensitive data. Controlled discovery reduces inference risk. | AC-4 AC-14 |
| SPR-517 | Technical | Technical Requirement | The [organization] shall correlate station/operator session activity with pass schedules and spacecraft mode, alert on off‑schedule access and command families invalid for the current mode, and retain results as audit evidence. | Off-schedule or mode-inconsistent commands signal compromise. Correlation across dimensions strengthens anomaly detection. Audit retention supports post-event review. Context validation strengthens mission assurance. | AC-17 AC-17(1) SI-4 AU-6 |
| SPR-518 | Procedural | Process / Procedure | The [organization] shall require external stations/relays to complete an onboarding certification demonstrating operator/facility vetting, key custody and revocation practices, RF configuration discipline, time synchronization, and adherence to pass scheduling and emergency procedures, with periodic re‑certification. | Relay and partner stations expand trust boundaries. Certification ensures consistent security practices. Periodic re-validation prevents drift. External governance strengthens link integrity. | AC-17 AC-20 AC-20(1) SR-6 |
| SPR-519 | Technical | Technical Requirement | The [spacecraft] shall cryptographically bind audit records to their origin using per‑record MACs/signatures or sequence‑linked hashes and include station/operator ID and selected RF/link indicators (e.g., SNR/BER, frame counters) when available; ground shall verify and log the results. | Per-record signatures prevent tampering or replay. Sequence linkage detects gaps. Including RF indicators enhances forensic value. Verified logging strengthens evidentiary integrity. | AU-3 AU-3(1) AU-9 AU-9(2) AU-10 |
| SPR-520 | Technical | Technical Requirement | The [spacecraft] shall implement tiered audit retention with overwrite protection for [organization]-defined high‑value categories (e.g., crypto events, command outcomes, mode changes) and expose buffer health/occupancy and retention decisions in telemetry; priorities shall be tunable by phase/mode. | High-value events require overwrite protection. Tunable priorities align storage with mission phase. Telemetry exposure ensures transparency. Structured retention strengthens audit survivability. | AU-4 AU-4(1) AU-11 |
| SPR-521 | Technical | Technical Requirement | The [spacecraft] shall prevent execution of [organization]-defined hazardous procedures when minimal auditing cannot be assured (e.g., verified buffer availability or local shadow log), while allowing essential safing actions; operator feedback shall distinguish “blocked due to no audit” from other rejects. | Certain operations require audit traceability. Blocking when audit is unavailable prevents blind execution. Essential safing remains permitted. Conditional enforcement strengthens accountability. | AC-3 AU-5 AU-5(2) |
| SPR-522 | Procedural | Process / Procedure | The [organization] shall implement a canonical time base and identifiers (station ID, session ID, command ID/APID, image/bitstream IDs) across TT&C front ends, consoles, and on‑board logs and shall de‑duplicate and gap‑detect during aggregation with rules for the source of truth for command history. | Unified identifiers prevent ambiguity in command history. Gap detection identifies dropped or spoofed entries. Clear source-of-truth logic prevents dispute. Time discipline strengthens forensic precision. | AU-6 AU-6(4) AU-8 IA-4 |
| SPR-523 | Procedural | Process / Procedure | The [organization] shall define and implement a common audit schema for flight and ground that supports event tiering, consistent identifiers/time bases, and dynamic elevation/suppression of categories by phase/mode; ground aggregators shall normalize and integrity‑check records. | Normalization supports cross-domain correlation. Tiered categories enable adaptive visibility. Integrity checks prevent log injection. Structured schema strengthens systemic monitoring. | AU-1 AU-6 AU-12 |
| SPR-524 | Technical | Technical Requirement | The [spacecraft] shall protect on‑board audit storage using ECC and periodic scrubbing, commit markers/journaling to survive partial writes, redundant partitions/devices where available, and prioritized retention for high‑value events. | ECC and journaling preserve log integrity under fault. Redundant partitions improve survivability. Prioritized retention protects high-value evidence. Durable logging strengthens mission accountability. | AU-9 AU-9(3) |
| SPR-525 | Procedural | Process / Procedure | The [organization] shall enforce least privilege and separation of duties for audit data (distinct roles for viewing, exporting, administering logs), apply heightened protections to sensitive categories (e.g., crypto operations), and provide break‑glass pathways with strong auditing. | Separation of duties prevents misuse of logs. Break-glass pathways preserve emergency access with oversight. Heightened protections reduce tampering risk. Structured governance strengthens trust. | AC-6 AU-9 AU-9(5) |
| SPR-526 | Procedural | Process / Procedure | The [organization] shall tie go/no‑go authorizations to verified artifacts (flatsat/twin results, signed images, key ceremonies) and define how authorization boundaries adjust under contingency conditions; evidence shall be captured for A&A. | Flight decisions must rely on validated artifacts. Evidence capture strengthens compliance. Contingency adjustments must remain controlled. Governance alignment supports mission safety. | CA-1 PL-2 CM-3 |
| SPR-527 | Procedural | Process / Procedure | The [organization] shall ingest vendor advisories, SBOM deltas, and provenance changes for components/toolchains into the Continuous Monitoring Program and correlate exposure with the “as‑flown” configuration to prioritize mitigations. | Exposure must be evaluated against actual deployed versions. SBOM deltas enable precise mitigation prioritization. Continuous ingestion strengthens responsiveness. Configuration awareness improves risk management. | CA-7 CA-7(6) CM-8 |
| SPR-528 | Technical | Technical Requirement | The [organization] shall package each flight change (software, bitstreams, configuration tables) with a signed manifest, precondition checks (mode, power/thermal, link), explicit hold/commit points, and resumable procedures across AOS/LOS; the [spacecraft] shall enforce manifest checks prior to activation. | Manifest enforcement ensures integrity prior to activation. Precondition checks prevent unsafe changes. Resumable logic supports space contact constraints. Structured packaging strengthens update security. | CM-3 CM-3(2) SI-7 SA-10 |
| SPR-529 | Procedural | Process / Procedure | The [organization] shall define freeze windows around launch/maneuvers/high‑risk events, specify exception criteria and approvers, and require chunking, rate limits, checksum/signature gates, and telemetry cues that confirm final state when changes occur within a freeze. | Operational stability requires disciplined change control. Freeze periods reduce compounding risk. Defined exceptions preserve agility. Structured boundaries protect mission safety. | CM-3 CM-3(5) CM-5 |
| SPR-530 | Technical | Technical Requirement | 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. | Maintenance capabilities expand risk surface. Time-limited activation reduces abuse window. Telemetry exposure ensures oversight. Auto-revert strengthens containment. | CM-7 CM-7(2) SA-8 SA-8(14) AC-3 |
| SPR-531 | Technical | Technical Requirement | The [spacecraft] shall enforce whitelisting for executable images and mission scripts/procedures by ID, hash, or signature, accept only artifacts produced by the mission build pipeline, and constrain interpreters/macros to sandboxed contexts with provenance checks on inputs. | Accepting only pipeline-produced artifacts prevents unauthorized code execution. Hash/signature validation ensures integrity. Sandbox constraints limit interpreter abuse. Provenance enforcement strengthens defense. | CM-7 CM-7(5) CM-7(8) SI-7 |
| SPR-532 | Technical | Technical Requirement | The [spacecraft] shall authenticate inter‑service exchanges (e.g., planning > command stacks, payload summaries > bus) using message‑level MACs/signatures or mutually authenticated channels appropriate to resource limits, and shall verify provenance for code‑driven actions. | Internal services must not assume implicit trust. Message-level authentication prevents spoofing. Resource-appropriate methods balance cost and assurance. Provenance verification strengthens command chain integrity. | IA-9 AC-4 |
| SPR-533 | Technical | Technical Requirement | The [spacecraft] and [organization] shall adapt identification and authorization based on mission context (e.g., anomaly response, unscheduled contact, safe mode) by tightening factors/keys, narrowing station whitelists, and enforcing geo/time and mode constraints, with telemetry cues and reversion to baseline. | Threat posture varies by mission state. Adaptive controls tighten during anomalies. Telemetry cues ensure transparency. Contextual enforcement supports Zero Trust maturity. | IA-1 IA-5 IA-10 |
| SPR-534 | Procedural | Process / Procedure | The [organization] shall deploy deception/canary artifacts in ground TT&C environments (e.g., decoy credentials, fake repositories, canary procedures that never propagate to flight) and integrate alerts into incident handling; mechanisms shall not induce hazardous commanding. | Canary artifacts reveal credential misuse or lateral movement. Integration with incident handling accelerates response. Mechanisms must not impact flight safety. Controlled deception strengthens detection. | IR-4 IR-4(12) SI-4 |
| SPR-535 | Procedural | Process / Procedure | The [organization] shall define space‑specific incident reporting thresholds, timelines aligned to pass cadence, distribution lists (including partners/regulators), and approved artifact formats (sanitized as required) to support coordinated response. | Pass cadence requires unique timing considerations. Defined thresholds ensure rapid escalation. Coordinated artifact formats improve response efficiency. Structured communication strengthens resilience. | IR-6 |
| SPR-536 | Procedural | Process / Procedure | The [organization] shall capture on‑board and ground evidence, produce an “as‑run” timeline with decisions/assumptions, and feed findings into updated playbooks, training, twin/flatsat scenarios, risk registers, and baselines, verifying changes via rehearsal. | Post-incident reconstruction improves institutional learning. Feeding findings into twins and training strengthens preparedness. Verification via rehearsal ensures improvement. Continuous feedback supports maturity. | IR-4 CA-7 |
| SPR-537 | Procedural | Process / Procedure | 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. | 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. | RA-3 RA-3(1) CA-7 |
| SPR-538 | Technical | Technical Requirement | The [spacecraft] shall budget CPU/power/memory for security functions (crypto, logging, verification), implement graceful degradation (e.g., summarize logs, throttle verification) that preserves TT&C and safing, and expose telemetry showing throttling decisions and residual capacity. | Security must not starve essential TT&C. Explicit resource budgeting ensures sustained enforcement. Graceful degradation preserves mission priority. Telemetry visibility supports oversight. | PE-9 SA-8(8) SC-6 CP-2 |
| SPR-539 | Technical | Design Constraint | 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. | Isolation reduces compromise propagation. Minimal shared infrastructure limits attack surface. Strict message filtering enforces boundaries. Architectural separation strengthens resilience. | SC-3 AC-4 SA-8(11) |
| SPR-540 | Technical | Technical Requirement | The [spacecraft] shall employ deterministic scheduling where feasible and bound retries/timeouts on command/telemetry paths by mode, exposing retry counters, backoff state, and finite‑state transitions in telemetry with consistent error/reject reason codes. | Determinism prevents runaway retries or timing exploitation. Exposed counters support diagnosis. Finite-state transitions strengthen transparency. Predictable behavior improves assurance. | SA-8(12) SI-10(3) SI-13 |
| SPR-541 | Technical | Design Constraint | 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. | Narrow interfaces reduce attack vectors. Explicit trusted-path indicators prevent misuse. Strengthened authentication protects critical operations. Procedural confirmation ensures compliance. | SA-8(13) SC-11 SC-12 |
| SPR-542 | Technical | Technical Requirement | The [spacecraft] shall reserve CPU/memory/link budget for essential TT&C (command authentication, attitude/power control loops, critical telemetry) and preempt/shape payload and nonessential traffic under stress. | Command authentication and attitude control may take precedence. Traffic shaping prevents payload starvation attacks. Priority enforcement preserves safe operations. Resource governance strengthens availability. | SC-5 SC-5(2) SC-6 CP-10 |
| SPR-543 | Technical | Technical Requirement | The [spacecraft] shall complement link‑layer protections with per‑message MACs/signatures for commands and selected telemetry so integrity and origin assurance persist across relays and storage/forwarding; operator feedback shall distinguish corruption vs. integrity vs. authentication failures. | Storage/forwarding relays can break link-layer trust. Message-level MACs preserve end-to-end assurance. Clear error distinctions aid operators. Layered integrity strengthens trust continuity. | AC-17(10) SC-8 SC-8(2) |
| SPR-544 | Technical | Technical Requirement | The [spacecraft] shall close sessions at LOS, invalidate per‑session tokens/nonces, and safely pause queued procedures with no partial side effects, supporting resumable execution at next AOS with explicit telemetry of residual stacks and state. | Session invalidation prevents replay or token reuse. Safe pausing prevents partial side effects. Resumable logic supports orbital realities. Session discipline strengthens security. | AC-12 SC-10 IA-5 |
| SPR-545 | Technical | Technical Requirement | The [spacecraft] shall bind session authenticity to station identity, operator role, spacecraft mode, and time/sequence and shall expose session parameters (IDs, counters, active role/mode) in telemetry; acceptance checks shall enforce geo/time/mode and station‑whitelist constraints with clear behavior on variance. | Station, role, mode, and time binding prevents misuse. Telemetry exposure ensures traceability. Constraint enforcement reduces impersonation risk. Context binding strengthens Zero Trust alignment. | SC-23 SC-23(1) SC-23(3) |
| SPR-546 | Procedural | Process / Procedure | The [organization] shall restrict removable media and peripheral device use within TT&C enclaves to [organization]-approved cases, enforce port/media controls on modulation chains and control hosts, and re‑validate enable/disable states after maintenance. | Media introduces malware and exfiltration risk. Port controls limit unauthorized insertion. Re-validation ensures configuration integrity post-maintenance. Controlled access strengthens enclave protection. | SC-41 MP-7 |
| SPR-547 | Technical | Technical Requirement | The [spacecraft] shall support chunked uploads of software/bitstreams/configuration with per‑chunk verification and commit markers, resumable across passes, with atomic activation and rollback if activation checks fail. | Per-chunk verification prevents partial corruption. Atomic activation avoids inconsistent states. Rollback ensures safe recovery. Structured update logic strengthens resilience. | SI-7 SI-7(15) |
| SPR-548 | Technical | Technical Requirement | The [spacecraft] shall retire superseded images, keys, and parameter sets using cryptographic erasure or verified wipe where supported, retain only golden and current versions needed for rollback, and expose an inventory of active/staged artifacts in telemetry. | Cryptographic erasure prevents legacy exploitation. Limiting retained versions reduces attack surface. Telemetry exposure ensures awareness. Controlled lifecycle management strengthens integrity. | SI-2(6) |
| SPR-549 | Technical | Technical Requirement | The [spacecraft] shall enforce memory‑protection hardening on flight processors (MPU/MMU isolation of partitions, W^X/no‑execute, stack canaries) and employ ECC with periodic scrubbing for critical memories; partition health and protection status shall be exposed in telemetry. | MPU/MMU isolation prevents partition compromise. W^X and stack canaries mitigate exploitation. ECC with scrubbing preserves memory integrity. Exposed health telemetry strengthens monitoring. | SI-16 SC-39 |
| SPR-550 | Technical | Technical Requirement | The [spacecraft] shall provide authenticated, auditable commands to inhibit or narrow subsystems/functions without risking loss of recovery paths, with explicit telemetry confirming resultant state; ground systems shall provide authenticated RF‑transmitter inhibits and rack‑level power controls with audit. | Controlled inhibit functions enable safe containment. Explicit telemetry confirms resultant state. Ground RF inhibits add physical-layer safety. Auditable containment strengthens operational control. | PE-10 AC-6 AC-6(5) IA-2 |
| SPR-551 | Procedural | Process / Procedure | The [organization] shall ensure end‑of‑life sanitization or destruction of boards/media that stored cryptographic material or mission data, render on‑orbit cryptographic material unrecoverable at decommissioning, and retain records proving disposal actions. | Residual crypto material poses long-term risk. Verified destruction prevents reuse or recovery. Documented disposal supports compliance. Lifecycle closure strengthens mission assurance. | SR-12 MP-6 |