| SPR-79 |
The [spacecraft] and all ground support systems (including those during development) shall be capable of detecting unauthorized hardware components/connections.{SV-SP-5,SV-SP-4}{CM-7(9)}
|
Unauthorized hardware introduces supply chain risk, covert backdoors, or malicious implants. Detection across development and operational environments prevents latent compromise from propagating to flight systems. Hardware verification supports trusted system baselines. Physical-layer assurance complements software integrity controls.
|
| SPR-89 |
The [spacecraft] shall implement the hardware, firmware, and software anti-tamper mechanisms identified in the Anti-Tamper Plan.{SV-SP-5,SV-SP-4}{SR-9(1),SR-10}
|
Anti-tamper mechanisms deter reverse engineering, unauthorized modification, and physical compromise. Integrated hardware, firmware, and software protections raise adversary cost. Defined Anti-Tamper Plans ensure consistent implementation across lifecycle phases. Protection must address both physical and cyber attack vectors.
|
| SPR-214 |
The [spacecraft] root of trust shall be an ECDSA NIST P-384 public key.{SV-AC-3,SV-IT-3,SV-SP-4,SV-SP-5}{SI-7(9),SI-7(10)}
|
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.
|
| SPR-215 |
The [spacecraft] root of trust shall be loadable only once, post-purchase.{SV-SP-9,SV-SP-4,SV-SP-10}{SI-7(9),SI-7(10)}
|
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.
|
| SPR-227 |
The [organization] shall identify all locations (including ground and contractor systems) that store or process sensitive system information.{SV-CF-3,SV-SP-4,SV-SP-10}{AC-3(11),CM-12}
|
Space system sensitive information can include a wide range of candidate material: functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of link segment protections subject to disabling/bypassing, failure/anomaly resolution, and any other sensitive information related to architecture, software, and mission operations.
|
| SPR-229 |
The [organization] shall protect documentation and Controlled Unclassified Information (CUI) as required, in accordance with the risk management strategy.{SV-CF-3,SV-SP-4,SV-SP-10}{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-10,SC-8(1),SC-28(3),SI-12}
|
Documentation may reveal architecture details exploitable by adversaries. Proper handling prevents leakage. Protection of CUI supports regulatory compliance. Information governance complements technical controls.
|
| SPR-232 |
The [organization] shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design.{SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4}{CP-2,CP-2(8),PL-7,PM-11,PM-30(1),RA-3(1),RA-9,SA-8(9),SA-8(11),SA-8(25),SA-12,SA-14,SA-15(3),SC-7(29),SR-1}
|
During SCRM, criticality analysis will aid in determining supply chain risk. For mission critical functions/components, extra scrutiny must be applied to ensure supply chain is secured.
|
| SPR-233 |
The [organization] shall identify the applicable physical and environmental protection policies covering the development environment and spacecraft hardware. {SV-SP-4,SV-SP-5,SV-SP-10}{PE-1,PE-14,SA-3,SA-3(1),SA-10(3)}
|
Development environments must be protected from tampering. Physical controls prevent hardware supply chain compromise. Policy clarity ensures consistent safeguards. Secure development underpins secure deployment.
|
| SPR-235 |
The [organization] shall ensure security requirements/configurations are placed in accordance with NIST 800-171 with enhancements in 800-172 on the development environments to prevent the compromise of source code from supply chain or information leakage perspective.{SV-SP-4,SV-SP-10,SV-CF-3}{AC-3,SA-3,SA-3(1),SA-15}
|
Supply chain threats target development environments. Enhanced controls reduce risk of source code exfiltration. Compliance strengthens contractual and regulatory assurance. Development security directly impacts spacecraft integrity.
|
| SPR-240 |
The [organization] shall categorize/classify preproduction environments (i.e., development, I&T, etc.) at the same level as any operational data in use within the environment and protect the system consistent with its categorization/classification.{SV-SP-10,SV-SP-4}{SA-3(2)}
|
Development systems often become attack vectors. Equal classification ensures consistent safeguards. Protection must reflect data sensitivity. Weak dev security undermines operational integrity.
|
| SPR-247 |
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.{SV-CF-3,SV-SP-4}{SR-12}
|
Improper disposal may expose system details. Lifecycle security includes end-of-life handling. Secure destruction prevents reconstruction or reverse engineering. Governance extends beyond operations.
|
| SPR-249 |
The [organization] shall employ [Program-defined Operations Security (OPSEC) safeguards] to protect supply chain-related information for the system, system components, or system services.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CP-2(8),PM-30,SA-12(9),SC-38,SR-7}
|
OPSEC safeguards may include: (1) Limiting the disclosure of information needed to design, develop, test, produce, deliver, and support the element for example, supplier identities, supplier processes, potential suppliers, security requirements, design specifications, testing and evaluation result, and system/component configurations, including the use of direct shipping, blind buys, etc.; (2) Extending supply chain awareness, education, and training for suppliers, intermediate users, and end users; (3) Extending the range of OPSEC tactics, techniques, and procedures to potential suppliers, contracted suppliers, or sub-prime contractor tier of suppliers; and (4) Using centralized support and maintenance services to minimize direct interactions between end users and original suppliers.
|
| SPR-256 |
The [organization] shall perform penetration testing/analysis: (1) On potential system elements before accepting the system; (2) As a realistic simulation of the active adversary’s known adversary tactics, techniques, procedures (TTPs), and tools; and (3) Throughout the lifecycle on physical and logical systems, elements, and processes.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CA-8(1),SA-9,SA-11(5),SR-5(2)}
|
Penetration testing should be performed throughout the lifecycle on physical and logical systems, elements, and processes including: (1) Hardware, software, and firmware development processes; (2) Shipping/handling procedures; (3) Personnel and physical security programs; (4) Configuration management tools/measures to maintain provenance; and (5) Any other programs, processes, or procedures associated with the production/distribution of supply chain elements.
|
| SPR-264 |
The [organization] shall report counterfeit information system components to [organization] officials. {SV-SP-4}{IR-6,IR-6(2),PM-30,SA-19,SR-11}
|
Counterfeit components may contain malicious implants or reliability risks. Reporting ensures centralized tracking and mitigation. Early notification prevents systemic exposure. Hardware integrity underpins mission assurance.
|
| SPR-267 |
The [organization] shall perform software component analysis (a.k.a.origin analysis) for developed or acquired software.{SV-SP-4,SV-SP-6}{CM-10,CM-10(1),RA-3(1),RA-5,SA-15(7),SI-3,SI-3(10),SR-4(4)}
|
Origin analysis identifies embedded third-party libraries and dependencies. Transparency reduces supply chain opacity. Knowing component lineage enables targeted vulnerability tracking. This mitigates inherited risk.
|
| SPR-282 |
The [organization] shall use all-source intelligence analysis of suppliers and potential suppliers of the information system, system components, or system services to inform engineering, acquisition, and risk management decisions.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-16,PM-30,RA-2,RA-3(1),RA-3(2),RA-7,SA-9,SA-12(8),SR-5(2)}
|
* The Program should also consider sub suppliers and potential sub suppliers.
* All-source intelligence of suppliers that the organization may use includes: (1) Defense Intelligence Agency (DIA) Threat Assessment Center (TAC), the enterprise focal point for supplier threat assessments for the DOD acquisition community risks; (2) Other U.S. Government resources including: (a) Government Industry Data Exchange Program (GIDEP) – Database where government and industry can record issues with suppliers, including counterfeits; and (b) System for Award Management (SAM) – Database of companies that are barred from doing business with the US Government.
|
| SPR-283 |
The [organization] shall request threat analysis of suppliers of critical components and manage access to and control of threat analysis products containing U.S.person information.{SV-SP-3,SV-SP-4,SV-SP-11}{PM-16,PM-30(1),RA-3(1),SA-9,SA-12,SR-1}
|
The intent of this requirement is to address supply chain concerns on hardware and software vendors. Not required for trusted suppliers accredited to the Defense Microelectronic Activity (DMEA). If the Program intends to use a supplier not accredited by DMEA, the government customer should be notified as soon as possible. If the Program has internal processes to vet suppliers, it may meet this requirement. All software used and its origins must be included in the SBOM and be subjected to internal and Government vulnerability scans.
|
| SPR-293 |
The [organization] shall employ techniques to limit harm from potential adversaries identifying and targeting the [organization]s supply chain.{SV-SP-4,SV-SP-5,SV-SP-6}{CP-2,PM-30,SA-9,SA-12(5),SC-38,SR-3,SR-3(1),SR-3(2),SR-5(2)}
|
Adversaries often exploit supplier relationships. Protective measures reduce reconnaissance and manipulation. Supply chain resilience strengthens mission integrity. Proactive defense mitigates systemic exposure.
|
| SPR-300 |
The [organization] shall maintain the integrity of the mapping between the master build data (hardware drawings and software/firmware code) describing the current version of hardware, software, and firmware and the on-site master copy of the data for the current version.{SV-SP-4,SV-SP-9}{CM-6,SA-8(21),SA-8(30),SA-10,SA-10(3),SA-10(4),SA-10(5),SI-7(10),SR-4(4)}
|
Build data linkage ensures reproducibility and traceability. Tampering detection depends on accurate mapping. Integrity of master copies prevents unauthorized modification. Configuration discipline supports resilience.
|
| SPR-304 |
The [organization] shall maintain a list of suppliers and potential suppliers used, and the products that they supply to include software.{SV-SP-3,SV-SP-4,SV-SP-11}{CM-10,PL-8(2),PM-30,SA-8(9),SA-8(11)}
|
Ideally you have diversification with suppliers
|
| SPR-305 |
The [organization] shall develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including support tamper resistance and provide a level of protection against the introduction of malicious code or hardware.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CM-3(8),CM-7(9),PM-30,SA-8(9),SA-8(11),SA-9,SA-10(3),SA-19,SC-51,SR-4(3),SR-4(4),SR-5(2),SR-11}
|
Counterfeit hardware may embed malicious implants. Formal policies reduce infiltration risk. Supplier verification strengthens trust. Hardware authenticity is foundational to cybersecurity.
|
| SPR-306 |
The [organization] shall conduct a supplier review prior to entering into a contractual agreement with a sub [organization] to acquire systems, system components, or system services.{SV-SP-4,SV-SP-6}{PM-30,PM-30(1),RA-3(1),SA-8(9),SA-8(11),SA-9,SA-12(2),SR-5(2),SR-6}
|
Pre-contract review ensures vendor security posture. Due diligence reduces third-party risk exposure. Structured evaluation strengthens procurement governance. Supplier trust must be verified.
|
| SPR-307 |
The [organization] shall maintain documentation tracing the strategies, tools, and methods implemented to mitigate supply chain risk .{SV-SP-3,SV-SP-4,SV-AV-7}{PM-30,RA-3(1),SA-12(1),SR-5}
|
Examples include: (1) Transferring a portion of the risk to the developer or supplier through the use of contract language and incentives; (2) Using contract language that requires the implementation of SCRM throughout the system lifecycle in applicable contracts and other acquisition and assistance instruments (grants, cooperative agreements, Cooperative Research and Development Agreements (CRADAs), and other transactions). Within the DOD some examples include: (a) Language outlined in the Defense Acquisition Guidebook section 13.13. Contracting; (b) Language requiring the use of protected mechanisms to deliver elements and data about elements, processes, and delivery mechanisms; (c) Language that articulates that requirements flow down supply chain tiers to sub-prime suppliers. (3) Incentives for suppliers that: (a) Implement required security safeguards and SCRM best practices; (b) Promote transparency into their organizational processes and security practices; (c) Provide additional vetting of the processes and security practices of subordinate suppliers, critical information system components, and services; and (d) Implement contract to reduce SC risk down the contract stack. (4) Gaining insight into supplier security practices; (5) Using contract language and incentives to enable more robust risk management later in the lifecycle; (6) Using a centralized intermediary or “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary;
|
| SPR-308 |
The [organization] shall protect against supply chain threats to the system, system components, or system services by employing security safeguards as defined by NIST SP 800-161 Rev.1.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-30,RA-3(1),SA-8(9),SA-8(11),SA-12,SI-3,SR-1}
|
The chosen supply chain safeguards should demonstrably support a comprehensive, defense-in-breadth information security strategy. Safeguards should include protections for both hardware and software. Program should define their critical components (HW & SW) and identify the supply chain protections, approach/posture/process.
|
| SPR-313 |
The [organization] shall develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of organization-defined systems, system components, or system services.{SV-SP-4,SV-SP-5,SV-SP-6}{SR-2}
|
Structured SCRM planning identifies lifecycle risks. Comprehensive coverage ensures holistic oversight. Risk planning mitigates systemic exposure. Governance extends beyond deployment.
|
| SPR-314 |
The [organization] shall protect the supply chain risk management plan from unauthorized disclosure and modification.{SV-SP-4}{SR-2}
|
Disclosure of SCRM strategy may expose defensive weaknesses. Controlled access preserves operational advantage. Plan integrity prevents tampering. Governance artifacts must be secured.
|
| SPR-315 |
The [organization] shall review and update the supply chain risk management plan as required, to address threats, organizational, or environmental changes.{SV-SP-4}{SR-2}
|
Threat landscapes evolve rapidly. Periodic updates maintain relevance. Adaptive management strengthens resilience. Continuous improvement is essential.
|
| SPR-316 |
The [organization] shall establish a supply chain risk management team to lead and support supply chain risk management activities.{SV-SP-4}{SR-2(1)}
|
Dedicated oversight ensures coordinated supply chain defense. Defined roles improve accountability. Central leadership streamlines mitigation efforts. Organizational focus strengthens resilience.
|
| SPR-317 |
The [organization] shall employ [organization]-defined techniques to limit harm from potential adversaries identifying and targeting the Program supply chain.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-3(2),SC-38}
|
Examples of security safeguards that the organization should consider implementing to limit the harm from potential adversaries targeting the organizational supply chain, are: (1) Using trusted physical delivery mechanisms that do not permit access to the element during delivery (ship via a protected carrier, use cleared/official couriers, or a diplomatic pouch); (2) Using trusted electronic delivery of products and services (require downloading from approved, verification-enhanced sites); (3) Avoiding the purchase of custom configurations, where feasible; (4) Using procurement carve outs (i.e., exclusions to commitments or obligations), where feasible; (5) Using defensive design approaches; (6) Employing system OPSEC principles; (7) Employing a diverse set of suppliers; (8) Employing approved vendor lists with standing reputations in industry; (9) Using a centralized intermediary and “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary Employing inventory management policies and processes; (10) Using flexible agreements during each acquisition and procurement phase so that it is possible to meet emerging needs or requirements to address supply chain risk without requiring complete revision or re-competition of an acquisition or procurement; (11) Using international, national, commercial or government standards to increase potential supply base; (12) Limiting the disclosure of information that can become publicly available; and (13) Minimizing the time between purchase decisions and required delivery.
|
| SPR-318 |
The [organization] shall ensure that the controls included in prime contracts are also included in the contracts of subcontractors.{SV-SP-4,SV-SP-6}{SR-3(3)}
|
Security gaps in subcontractors create systemic vulnerabilities. Flow-down requirements enforce consistent standards. Contractual alignment strengthens supply chain assurance. Uniform governance reduces weak links.
|
| SPR-322 |
The [organization] shall retain at least two previous versions of all spacecraft associated software on the ground with the capability to restore previous version on the spacecraft.{SV-SP-9,SV-SP-4}{CM-2(3),CM-3(7),CM-4(2),SA-10,SA-10(4)}
|
Maintaining prior software versions enables rapid rollback in the event of faulty or malicious updates. In space systems, recovery options are limited once deployed. Retained versions preserve operational continuity and reduce mission impact. Controlled rollback strengthens resilience against supply chain or update-based compromise.
|
| SPR-324 |
The [organization] shall inspect system components periodically during development to detect tampering (in accordance with the Anti-Tamper Plan).{SV-SP-5,SV-SP-4}{SR-10}
|
Development environments are prime targets for hardware or firmware manipulation. Regular inspection supports early detection of unauthorized modification. Alignment with the Anti-Tamper Plan ensures structured verification. Early detection prevents compromised components from reaching flight configuration.
|
| SPR-325 |
The [organization] shall develop and implement anti-counterfeit policy and procedures, in coordination with the [CIO], that is demonstrably consistent with the anti-counterfeit policy defined by the Program office.{SV-SP-4,SV-SP-11}{SR-11}
|
Consistent anti-counterfeit policy ensures supply chain integrity across organizational boundaries. Alignment with Program office guidance prevents inconsistent enforcement. Counterfeit components introduce reliability and malicious implant risks. Formal policy strengthens procurement assurance.
|
| SPR-326 |
The [organization] shall employ technical means to determine if system components are genuine or have been altered.{SV-SP-5,SV-SP-4}{SR-11(3)}
|
Organizations may leverage supplier and contractor processes for validating that a system or component is genuine and has not been altered and for replacing a suspect system or component.
|
| SPR-327 |
The [organization] shall document, monitor, and maintain valid provenance of critical system components and associated data in accordance with the Supply Chain Risk Management Plan.{SV-SP-4,SV-SP-5}{SR-4,SR-4(1),SR-4(2)}
|
Traceable provenance reduces supply chain opacity and hidden dependency risk. Documentation of origin enables vulnerability tracking and recall response. Monitoring component lineage strengthens trust in deployed hardware and software. Transparency enhances lifecycle accountability.
|
| SPR-328 |
The [organization] shall ensure any update to on-board software, memory, or stored procedures has met high assurance standards before execution. {SV-SP-9,SV-SP-4}{AC-3(2),CM-3,SA-8(8),SA-8(31),SA-10(2),SR-4(4)}
|
On-orbit updates carry significant risk if not validated. High assurance standards prevent unauthorized or corrupted uploads from executing. Structured validation protects system integrity. Update governance reduces mission-ending configuration errors.
|
| SPR-330 |
The [organization] shall employ the [organization]-defined approaches for the purchase of the system, system components, or system services from suppliers.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-5}
|
This could include tailored acquisition strategies, contract tools, and procurement methods.
|
| SPR-332 |
The [organization] shall employ [Selection (one or more): independent third-party analysis, Program penetration testing, independent third-party penetration testing] of [Program-defined supply chain elements, processes, and actors] associated with the system, system components, or system services.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-6(1)}
|
Third-party testing identifies weaknesses across suppliers and processes. Independent review strengthens trust in acquisition channels. Broader testing scope reduces systemic risk. Supply chain validation enhances mission security posture.
|
| SPR-336 |
The [organization] (and Prime Contractor) shall conduct a supplier review prior to entering into a contractual agreement with a contractor (or sub-contractor) to acquire systems, system components, or system services.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-6}
|
|
| SPR-345 |
The [organization] shall update the inventory of spacecraft components as an integral part of component installations, removals, and spacecraft updates.{SV-MA-4,SV-SP-4}{CM-8(1),CA-7,CM-2,CM-3}
|
Accurate inventory enables vulnerability tracking and incident response. Lifecycle updates prevent undocumented changes. Asset visibility strengthens security management. Configuration awareness reduces blind spots.
|
| SPR-363 |
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.{SV-SP-5,SV-SP-4}{PE-6,PE-6(1),PE-6(4),PE-18,PE-20,SC-7(14)}
|
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.
|
| SPR-372 |
The [organization] shall develop and document program-specific system maintenance policies for performing maintenance on the spacecraft hardware (pre-launch) and software (post-launch). {SV-SP-9,SV-SP-4}{MA-1}
|
Maintenance must preserve system integrity. Defined policies prevent unauthorized modification. Lifecycle control supports traceability. Maintenance governance strengthens resilience.
|
| SPR-374 |
The [organization] shall develop and maintain an overarching document that details policies and procedures regarding system and services acquisition.{SV-SP-4,SV-SP-6}{SA-1}
|
Acquisition governance ensures security requirements flow into procurement. Structured oversight reduces supply chain risk. Comprehensive documentation supports compliance. Early integration improves lifecycle protection.F377
|
| SPR-393 |
The [organization] shall confirm that the operational spacecrafts correspond to the baseline configuration. {SV-SP-9,SV-SP-4}{CM-2,CM-3,CM-3(7),CM-4(2),CM-6,SA-10}
|
Configuration drift undermines trust and auditability. Confirming alignment ensures deployed assets reflect approved design. Baseline validation supports recovery and compliance. Continuous verification reduces unknown risk.
|
| SPR-403 |
The [organization] shall develop and document an inventory of the spacecraft components that accurately reflects the to-be launched system. {SV-MA-4,SV-SP-4}{CM-8,CM-2}
|
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.
|
| SPR-404 |
The [organization] shall establish and formally review the baseline configuration to confirm that it represents an agreed-upon set of specifications for the spacecrafts.{SV-SP-4}{CM-2,CM-6}
|
Formal baseline review ensures consensus on spacecraft specifications. Structured validation prevents silent drift. Agreement strengthens accountability. Baseline governance supports mission reliability.
|
| SPR-406 |
The [organization] shall track security advisories, patches/updates, and ensure compliance with license agreements and usage restrictions for all software within the SBOM.{SV-SP-6,SV-SP-4}{CM-10}
|
Software dependencies evolve over time. Tracking advisories prevents latent vulnerability exposure. SBOM transparency enables rapid risk assessment. Compliance monitoring strengthens lifecycle resilience.
|
| SPR-407 |
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).{SV-SP-6,SV-SP-4}{CM-8}
|
Continuous SBOM updates ensure accurate dependency tracking. Lifecycle revision captures changes in deployed components. Accurate SBOMs enable vulnerability correlation. Transparency enhances supply chain integrity.
|
| SPR-420 |
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].{SV-MA-4,SV-SP-4}{CM-8(2)}
|
Automated ingestion ensures accurate and timely asset visibility. On-orbit delta reporting captures configuration drift. Real-time inventory supports anomaly detection. Visibility underpins governance.
|
| SPR-421 |
The [organization] shall employ automated mechanisms to detect unauthorized components within the spacecraft component inventory.{SV-SP-5,SV-SP-4}{CM-8(3)}
|
Unauthorized hardware or firmware may introduce implants. Automated detection reduces supply chain risk. Inventory validation strengthens assurance. Continuous monitoring prevents silent compromise.
|
| SPR-423 |
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.{SV-MA-6,SV-SP-4}{CM-9}
|
A formal CMP defines structured change governance. Clear roles and procedures reduce ambiguity. Lifecycle configuration control supports security enforcement. Documented processes strengthen compliance.
|
| SPR-426 |
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.{SV-SP-4,SV-MA-5}{IR-4(10)}
|
Central coordination improves communication during incidents. Defined liaison strengthens supplier engagement. Structured oversight reduces fragmented response. Supply chain integration supports resilience.
|
| SPR-431 |
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.{SV-SP-4,SV-SP-6}{SA-4}
|
Security must be embedded in procurement documentation. Explicit criteria prevent ambiguity. Defined acceptance standards ensure compliance. Acquisition governance strengthens supply chain assurance.
|
| SPR-432 |
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.{SV-SP-4}{SA-4(1)}
|
Understanding control behavior ensures accurate evaluation. Clear functional descriptions support validation. Transparency improves assessment quality. Governance requires documented control intent.
|
| SPR-433 |
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.{SV-SP-4,SV-SP-5}{SA-4(2)}
|
Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc.
|
| SPR-446 |
The [organization] shall enable integrity verification of hardware components.{SV-SP-5,SV-SP-4}{SA-10(3),SA-8(21),SA-10(3),SC-51}
|
* The integrity verification mechanisms may include:
** Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites;
** Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery;
** Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure;
** Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses;
** Implementing cryptographic hash verification; and
** Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing.
** Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites;
** Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery;
** Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure;
** Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses;
** Implementing cryptographic hash verification; and
** Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing.
|
| SPR-467 |
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.{SV-MA-4,SV-SP-4}{PE-20,CM-8}
|
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.
|
| SPR-468 |
The [spacecraft] shall detect and report the connection of any unauthorized or unknown component to onboard interfaces.{SV-SP-5,SV-SP-4}{PE-20,CM-8(3),SI-4}
|
Hardware implants pose existential mission risk. Detection of unknown components prevents covert insertion. Automated alerting reduces dwell time. Inventory integrity supports physical security.
|
| SPR-476 |
The [organization] shall identify suppliers of mission-critical or mission-essential items and apply enhanced oversight that includes security practice vetting, contract language mandating secure manufacturing, and periodic compliance audits.{SV-SP-4,SV-SP-5}{PM-30(1),SR-6,SR-3}
|
Mission-critical suppliers require elevated scrutiny. Contractual language enforces security standards. Periodic audits reduce supply chain risk. Oversight strengthens systemic assurance.
|
| SPR-478 |
The [organization] shall map supplier failure impact to mission functions and assign risk-based oversight and acceptance criteria.{SV-SP-4,SV-MA-6}{PM-30(1),SR-2,RA-3}
|
Understanding supplier failure impact informs oversight priority. Risk-based criteria ensure proportional governance. Structured assessment prevents blind spots. Supply chain risk alignment strengthens mission resilience.
|
| SPR-482 |
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.{SV-SP-4,SV-SP-5}{SA-10(2),CM-2}
|
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.
|
| SPR-483 |
The [organization] shall require trusted generation of flight and payload software and configuration baselines in a controlled build environment that enforces signed commits, reproducible builds, cryptographic hashing, and code signing of release artifacts, and shall maintain a configuration-controlled golden image for comparison and rollback.{SV-SP-4,SV-SP-3,SV-SP-9}{SA-10(4)}
|
Controlled builds prevent unauthorized code injection. Reproducible builds strengthen supply chain transparency. Golden images support rollback and forensic validation. Configuration control strengthens integrity.
|
| SPR-497 |
The [spacecraft] shall verify the standby component integrity before activation using stored signatures and shall revert if verification fails.{SV-SP-4,SV-AC-3}{SI-13(4)}
|
Failover to compromised standby defeats purpose. Signature verification ensures trust continuity. Reversion prevents propagation of corruption. Validation strengthens resilience.
|
| SPR-501 |
The [organization] shall assign and record unique cryptographic identities for flight-critical hardware components, firmware images, and software builds and shall maintain an authoritative registry mapping identities to approved suppliers and versions.{SV-SP-4,SV-SP-5}{SR-4(1),IA-3}
|
Unique identities enable provenance tracking. Registry mapping supports supplier validation. Identity governance strengthens supply chain assurance. Structured attestation supports lifecycle integrity.
|
| SPR-502 |
The [spacecraft] shall report component and software identities and version fingerprints in telemetry at boot and upon changes to support provenance verification.{SV-SP-4,SV-MA-4}{SR-4(1),IA-3}
|
On-orbit reporting enables real-time provenance verification. Version fingerprints support anomaly detection. Transparency reduces silent drift. Telemetry-based attestation strengthens oversight.
|
| SPR-503 |
The [organization] shall validate authenticity and integrity of all flight-designated hardware, firmware, and software upon receipt using program-controlled trust anchors (approved vendor list, golden hash/cert manifest){SV-SP-4,SV-SP-5}{SR-4(3),SR-11,SI-7}
|
Receipt validation prevents counterfeit or tampered parts integration. Program-controlled trust anchors ensure consistency. Early detection reduces downstream risk. Intake verification strengthens SCRM posture.
|
| SPR-504 |
The [organization] shall re-validate component identity (serial/lot), firmware measurements (cryptographic hashes), and certificate status immediately prior to installation, writing results to the SCRM/provenance ledger and blocking install on mismatch.{SV-SP-4,SV-SP-5}{SR-4(3),SR-11,SI-7}
|
Installation-time validation prevents stale or revoked components. Ledger recording strengthens traceability. Blocking on mismatch prevents compromise propagation. Continuous verification enhances assurance.
|
| SPR-506 |
The [organization] supplier shall provide a signed pedigree for each critical flight item (COTS/ASIC/FPGA/embedded SW library) including: manufacturing lot/wafer, test results and environmental/rad-hard certs, sub-tier sources, workforce vetting attestation as required, and full chain-of-custody events; the program shall store/track this in the SCRM/provenance ledger.{SV-SP-4,SV-SP-5}{SR-4(4),SR-6}
|
Signed pedigree documents manufacturing and handling lineage. Chain-of-custody transparency reduces counterfeit risk. Ledger tracking strengthens auditability. Supply chain evidence supports mission trust.
|
| SPR-508 |
Within [organization]-defined window (e.g.,30/60/90 days) before integration or stow, the pedigree shall be re-verified and seals/marks inspected to detect substitution{SV-SP-4,SV-SP-5}{SR-4(4),SR-11,PE-16}
|
Time between receipt and integration creates substitution risk. Re-verification ensures seals, markings, and provenance remain intact. This reduces last-minute supply chain compromise. Periodic pedigree validation strengthens SCRM integrity.
|
| SPR-509 |
The [organization] shall procure flight items only from an AO-approved vetted supplier whitelist; off-list buys require documented risk acceptance and compensating pedigree/scanning.{SV-SP-4}{SR-4(4),SR-3,SR-5}
|
Restricting procurement to vetted suppliers reduces counterfeit and tampering risk. Off-list acquisitions require formal risk acceptance, preserving governance. Structured sourcing strengthens trust anchors. Controlled procurement reduces systemic exposure.
|
| SPR-511 |
The [organization] shall quarantine anti-counterfeit anomalies, block integration until disposition, open an incident record, notify SCRM lead/AO, and require supplier corrective action/lot containment as applicable.{SV-SP-4,SV-MA-5}{SR-11(3),IR-6}
|
Immediate quarantine prevents contaminated integration. Formal incident tracking ensures accountability. Supplier corrective actions reduce recurrence risk. Structured containment strengthens resilience.
|
| SPR-527 |
The [organization] shall ingest vendor advisories, SBOM deltas, and provenance changes for components/toolchains into the Continuous Monitoring Program and correlate exposure with the “as‑flown” configuration to prioritize mitigations.{SV-SP-6,SV-SP-4,SV-DCO-1}{CA-7,CA-7(6),CM-8}
|
Exposure must be evaluated against actual deployed versions. SBOM deltas enable precise mitigation prioritization. Continuous ingestion strengthens responsiveness. Configuration awareness improves risk management.
|
| SPR-531 |
The [spacecraft] shall enforce whitelisting for executable images and mission scripts/procedures by ID, hash, or signature, accept only artifacts produced by the mission build pipeline, and constrain interpreters/macros to sandboxed contexts with provenance checks on inputs.{SV-SP-9,SV-SP-4}{CM-7,CM-7(5),CM-7(8),SI-7}
|
Accepting only pipeline-produced artifacts prevents unauthorized code execution. Hash/signature validation ensures integrity. Sandbox constraints limit interpreter abuse. Provenance enforcement strengthens defense.
|
| SPR-546 |
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.{SV-MA-7,SV-SP-4}{SC-41,MP-7}
|
Media introduces malware and exfiltration risk. Port controls limit unauthorized insertion. Re-validation ensures configuration integrity post-maintenance. Controlled access strengthens enclave protection.
|
| SPR-549 |
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.{SV-IT-4,SV-SP-4}{SI-16,SC-39}
|
MPU/MMU isolation prevents partition compromise. W^X and stack canaries mitigate exploitation. ECC with scrubbing preserves memory integrity. Exposed health telemetry strengthens monitoring.
|
| SPR-551 |
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.{SV-SP-4}{SR-12,MP-6}
|
Residual crypto material poses long-term risk. Verified destruction prevents reuse or recovery. Documented disposal supports compliance. Lifecycle closure strengthens mission assurance.
|