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.
Startup integrity checks detect boot-level compromise or unauthorized modification. Event-triggered checks provide additional protection when anomalies occur. This limits adversary persistence across reboots. Continuous validation reinforces trusted boot regimes.
SPR-82
The [spacecraft] boot firmware shall validate the boot loader, boot configuration file, and operating system image, in that order, against their respective signatures.{SV-IT-3}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10)}
A signature is ~770 bits long. No requirement is imposed on the storage location of signatures.
SPR-83
The [spacecraft] boot firmware shall verify a trust chain that extends through the hardware root of trust, boot loader, boot configuration file, and operating system image, in that order.{SV-IT-3}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10)}
These three items were chosen because they’re intended to be static values (once properly set up) but are in volatile storage. Also, the Boot ROM can’t be modified, so there’s no reason to check a signature.
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.
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.
It is important for the computing module to be able to access a set of functions and commands that it trusts; that is, that it knows to be true. This concept is referred to as root of trust (RoT) and should be included in the spacecraft design. With RoT, a device can always be trusted to operate as expected. RoT functions, such as verifying the device’s own code and configuration, must be implemented in secure hardware (i.e., field programmable gate arrays). By checking the security of each stage of power-up, RoT devices form the first link in a chain of trust that protects the spacecraft
SPR-213
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.{SV-IT-3}{SI-7(9),SI-7(10)}
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.
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-216
The [spacecraft] secure boot mechanism shall be Commercial National Security Algorithm Suite (CNSA) compliant.{SV-IT-3}{SI-7(9),SI-7(10)}
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.
SPR-217
The [spacecraft] shall allocate enough boot ROM memory for secure boot firmware execution.{SV-IT-3}{SI-7(9),SI-7(10)}
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.
SPR-218
The [spacecraft] shall allocate enough SRAM memory for secure boot firmware execution.{SV-IT-3}{SI-7(9),SI-7(10)}
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.
SPR-219
The [spacecraft] shall support the algorithmic construct of Elliptic Curve Digital Signature Algorithm (ECDSA) NIST P-384 + SHA-38 or equivalent strength.{SV-IT-3}{SI-7(9),SI-7(10)}
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
SPR-220
The [spacecraft] hardware root of trust shall be an ECDSA NIST P-384 public key.{SV-IT-3}{SI-7(9)}
No requirement is imposed on uniqueness.
SPR-221
The [spacecraft] hardware root of trust shall be loadable only once, post-purchase.{SV-IT-3}{SI-7(9)}
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.
SPR-222
The [spacecraft] shall implement trusted boot/RoT as a separate compute engine controlling the trusted computing platform cryptographic processor.{SV-IT-3}{SI-7(9)}
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.
SPR-223
The [spacecraft] shall implement trusted boot/RoT computing module on radiation tolerant burn-in (non-programmable) equipment.{SV-IT-3}{SI-7(9)}
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.
The [spacecraft] shall restrict access to flight software executables, cryptographic material, command dictionaries, and [organization]-defined sensitive payload data to the privileged execution domain and shall deny all other access by default.{SV-AC-1,SV-AC-3,SV-IT-3}{AC-3(11),AC-6}
Flight executables and cryptographic materials are high-value targets. Restricting access reduces exploitation pathways. Default deny enforces least privilege. Segmentation enhances resilience.
SPR-471
The [spacecraft] shall preserve trusted boot and cryptographic key storage functionality under EMP conditions by locating those functions within hardened, power-conditioned domains.{SV-IT-3,SV-AC-3}{PE-21}
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.
SPR-494
The [spacecraft] shall preserve and protect a golden backup of security credentials and integrity anchors and shall restore them automatically when corruption is detected.{SV-AC-3,SV-IT-3}{SI-13,CP-9}
Adversaries achieve first execution before the spacecraft ever flies by inserting malicious code, data, or configuration during manufacturing, integration, or delivery. Targets include software sources and dependencies, build systems and compilers, firmware/bitstreams for MCUs and FPGAs, configuration tables, test vectors, and off-the-shelf avionics. Inserted artifacts are designed to appear legitimate, propagate through normal processes, and activate under routine procedures or specific modes (e.g., safing, maintenance). Common insertion points align with where trust is assumed, vendor updates, mirrors and registries, CI/CD runners, programming stations, and “golden image” repositories. The result is pre-positioned access that blends with baseline behavior, often with delayed or conditional triggers and strong deniability.
Here the manipulation targets software delivered to flight or ground systems: altering source before build, swapping signed binaries at distribution edges, subverting update metadata, or using stolen signing keys to issue malicious patches. Space-specific vectors include mission control applications, schedulers, gateway services, flight tables and configuration packages, and firmware loads during I&T or LEOP. Adversaries craft payloads that pass superficial validation, trigger under particular operating modes, or reintroduce known weaknesses through version rollback. “Data payloads” such as malformed tables, ephemerides, or calibration products can double as exploits when parsers are permissive. The objective is to ride the normal promotion pipeline so the implant arrives pre-trusted and executes as part of routine operations.
The attacker manipulates memory and configuration used in the earliest stages of boot so that their code runs before normal protections and integrity checks take hold. Targets include boot ROM vectors, first-stage/second-stage bootloaders, boot configuration words and strap pins, one-time-programmable (OTP) fuses, non-volatile images in flash/EEPROM, and scratch regions copied into RAM during cold start. Techniques range from replacing or patching boot images to flipping configuration bits that alter trust decisions (e.g., image selection, fallback order, watchdog behavior). Faults can be induced deliberately (timed power/clock/EM glitches) or via crafted update/write sequences that leave a partially programmed but executable state. Once resident, the modification can insert early hooks, disable or short-circuit checks, or select downgraded images; destructive variants corrupt the boot path to induce a persistent reset loop or safeing entry (a denial of service). Because boot logic initializes buses, memory maps, and handler tables, even small changes at this stage cascade, shaping how command handlers load, how keys and counters are initialized, and which peripherals are trusted for subsequent execution.
The adversary arranges for malicious content to survive resets and mode changes by targeting memories and execution paths that initialize the system. Candidates include boot ROM handoff vectors, first/second-stage loaders, non-volatile images (flash/EEPROM), “golden” fallback partitions, configuration words/fuses, and RAM regions reconstructed at start-up from stored files or tables. Persistence may also ride auto-run mechanisms, init scripts, procedure engines, stored command sequences, or event hooks that execute on boot, safe-mode entry/exit, time triggers, or receipt of specific telemetry/commands. Variants keep the core payload only in RAM but ensure it is reloaded after every restart by patching copy-on-boot routines, altering file catalogs, or modifying table loaders so the same bytes are restored. The common thread is control of where the spacecraft looks for what to run next, so unauthorized logic is reinstated whenever the system resets or transitions modes.
Counterfeit electronic components represent a direct supply chain threat to space mission integrity, introducing hardware that may fail prematurely, perform outside specification, or contain malicious functionality deliberately embedded by an adversary during manufacture or distribution. A formal anti-counterfeit program must establish policy and procedures that span the entire component acquisition and integration lifecycle, from supplier qualification and procurement through incoming inspection, storage, and installation. The program must address two distinct but related risks: counterfeit components that fail to perform their intended function, degrading mission reliability; and deliberately tampered components that introduce malicious hardware functionality or create pathways for malicious code execution. Anti-counterfeit controls must include measures appropriate to component criticality and supply chain risk to authenticate components, detect evidence of tampering, and resist unauthorized modification. Detection and prevention must be treated as complementary objectives: prevention through qualified sourcing and procurement controls, detection through inspection and authentication techniques applied before components enter the system.
A supplier review is a structured pre-contract assessment conducted before entering into any agreement with a contractor or subcontractor for the acquisition of systems, system components, or system services. The review evaluates the prospective supplier's security posture, trustworthiness, and capability to deliver components or services that meet the mission's integrity and assurance requirements, before contractual commitments are made and before the supplier gains access to mission information or influence over mission systems. Supplier reviews reduce the risk of introducing supply chain vulnerabilities through poorly qualified, compromised, or adversary-influenced suppliers at any tier of the acquisition chain. The rigor and depth of the review should be calibrated to the criticality of the components or services being acquired, with suppliers of mission-critical hardware, software, or services subject to the most intensive assessment. Supplier review findings should inform not only the decision to contract but also the specific security requirements, oversight provisions, and flow-down obligations included in the resulting agreement.
Hardware components that cannot be sourced directly from the original component manufacturer (OCM) or an authorized franchised distributor, and software that cannot be obtained from the original publisher, developer, or an authorized distribution channel, represent elevated supply-chain risk and must not be procured or incorporated into the mission system without documented approval from the program’s supply-chain governance authority. Sourcing hardware from the OCM or authorized franchised distributors provides greater assurance of component authenticity, traceability, and conformance to specification. Obtaining software from the original publisher, developer, or an authorized distribution channel similarly reduces the risk of unauthorized, altered, fraudulent, or malicious software. Deviations from these approved sourcing channels introduce additional supply-chain risk that must be assessed before acceptance. The approval process for non-OCM-sourced items must evaluate the specific risk posed by the alternative source, the criticality of the component or software to mission function, the availability and adequacy of compensating inspection and authentication measures, and whether a compliant source can be identified before accepting the deviation. This governance requirement applies to hardware components, firmware, and software, although the applicable sourcing and authentication methods differ. Hardware controls should address component authenticity and traceability, while software controls should address publisher or developer provenance, distribution-channel integrity, license legitimacy, and cryptographic verification where available.
Custom application-specific integrated circuits (ASICs) should be fabricated through accredited trusted foundries, and field-programmable gate array (FPGA) devices should be procured through trusted suppliers with documented fabrication provenance, to reduce the risk of hardware Trojan insertion or unauthorized modification. Unlike software, hardware trojans embedded during semiconductor manufacturing are extremely difficult to detect through functional testing alone, as they may be designed to activate only under specific operational conditions or remain dormant indefinitely; the integrity of the fabrication source is therefore a primary defense. Trusted foundry accreditation provides assurance that the accredited fabrication activities are subject to security controls intended to reduce the risk of unauthorized modification. Assurance for design, intellectual property, aggregation, packaging, assembly, testing, and distribution must be addressed through trusted suppliers or other controls applicable to those lifecycle stages. This requirement applies to custom ASICs and to the base silicon used in FPGA implementations. The programmable design loaded onto an FPGA requires separate protection because trusted fabrication of the device does not establish the integrity or authenticity of the configured bitstream.
Tamper protection encompasses physical and logical controls that detect, deter, and respond to unauthorized modification of mission hardware and software throughout the acquisition, transit, storage, integration, and operational phases of the mission lifecycle. Physical tamper protection requires inspection of hardware at defined custody transfer points to detect evidence of unauthorized access or modification, and requires the use of tamper-evident packaging and sealing mechanisms during shipping and receiving to ensure that any interference with equipment in transit is detectable upon arrival. Logical tamper protection addresses the integrity of software and firmware through layered techniques including code obfuscation, integrity checks that verify software has not been altered from its approved state, and runtime integrity monitoring mechanisms such as self-checking code. Watchdog processes may supplement these controls by detecting abnormal execution or failure to complete expected processing, but do not by themselves verify software integrity. Physical and logical tamper protections are complementary and should be applied together where warranted by system criticality, threat exposure, and lifecycle conditions. Physical access to hardware can enable logical tampering, while failure to verify software integrity can reduce the assurance provided by physical controls.
A software bill of materials (SBOM) is a structured inventory of software components, libraries, dependencies, and associated metadata comprising a delivered system, spanning first-party code and available third-party and open-source supply-chain information. The SBOM serves as the foundational reference for continuous vulnerability management: by cross-correlating the component inventory against known vulnerability databases, such as those cataloging common vulnerabilities and exposures (CVEs), mission owners and operators can rapidly identify which specific system components are affected by newly disclosed vulnerabilities and prioritize remediation accordingly. SBOM generation must cover the full software supply chain, including transitive dependencies that are not explicitly declared in top-level manifests, as these indirect inclusions represent a persistent and frequently exploited blind spot in software inventory programs. An SBOM may reveal component composition and vulnerability-relevant information that could assist adversary reconnaissance. Its classification, sensitivity, dissemination, and handling requirements shall be determined using applicable mission guidance, contractual requirements, and a documented disclosure-risk assessment. If deemed to have sensitive information then the handling controls applied should align to other mission-critical security documentation as defined in CM0001.
Binary or machine-executable code obtained from sources that provide no warranty and no access to the corresponding source code must not be incorporated into spacecraft or ground systems. This prohibition addresses a fundamental software assurance gap: without source code, missions cannot perform source-based static analysis or independently review and modify implementation details, and may have reduced ability to assess, repair, or extend the software. Code from sources with limited or no warranty and no source code provision may be difficult to independently analyze, repair, or extend and leaves the mission dependent on supplier assurances and remediation capabilities. This countermeasure applies throughout the software supply chain, including components integrated by subcontractors.
Each software or firmware image subject to installation or update control shall be verified using an approved digital signature and an approved trust anchor before installation or activation. The trust anchor may be represented by a certificate or by a directly provisioned verification key, depending on the approved trust architecture. Successful verification establishes that the image was signed by an authorized signing identity and has not been modified since signing; it does not establish that the signed code is non-malicious, vulnerability-free, or operationally safe. Signature verification confirms the integrity and approved origin of the software but does not, by itself, prevent installation of an older validly signed version; update authorization and rollback protections must be enforced separately.
The verification mechanism must be implemented such that it cannot be bypassed through operational commands, configuration changes, or software updates, and must reject any component whose signature is absent or invalid, or whose signing certificate or trust anchor is not recognized and approved by the mission. Digital signature enforcement complements but is distinct from the boot-time chain of trust established through secure boot; it applies to software installation and update events throughout the operational lifecycle, not only at system startup.
Configuration management (CM) for space systems requires automated mechanisms to establish, maintain, validate, and report on the approved baseline configuration of spacecraft and supporting ground systems, ensuring the baseline remains current, complete, and accurate throughout the mission lifecycle. Automated mechanisms should support configuration management by improving the accuracy, currency, and validation of configuration records. Automation does not replace formal change control, engineering review, approval, or other configuration management activities that require human judgment. The approved baseline must be readily accessible to authorized personnel for operational decision-making, anomaly investigation, and change impact assessment. Deviations between the documented baseline and the actual system configuration represent both security and operational risk because undocumented changes may introduce vulnerabilities, mask adversary activity, or produce unpredictable system behavior. Automated validation should identify and report configuration drift at mission-defined intervals or following relevant change events, based on system observability and mission risk.
An on-board intrusion detection and prevention system (IDS/IPS) monitors mission-critical spacecraft components and systems, generates and stores audit records, and supports mission-approved responses to detected threats. Depending on the mission architecture, threat, and availability of ground support, responses may be autonomous, ground-directed, or a combination of both. The system should address both known attack patterns and previously unseen anomalous behavior through complementary signature-based and behavior- or anomaly-based detection methods. Machine learning or adaptive technologies may be used when their performance, resource consumption, and failure behavior have been validated for the mission environment. Detection and response coverage should address applicable adversary activities across the attack lifecycle, including initial access, execution, persistence, defense evasion, and exfiltration. The on-board IDS/IPS must be integrated with the spacecraft's traditional fault management system to provide a unified approach to anomaly response, ensuring that cyber-triggered responses are compatible with fault management logic and do not produce unintended effects or fratricide against the spacecraft's own systems; countermeasures that are incompatible with fault management are considered unsafe and must not be executed autonomously. The response hierarchy must prioritize vehicle safety and continued mission operations. Advanced containment or deception responses may be considered when they can be executed without unacceptable mission risk. The system should preserve evidence that supports post-event analysis, threat characterization, and potential attribution by authorized ground support.
Cyber-safe mode is a dedicated, configuration-controlled spacecraft operating state entered autonomously or by authorized ground command when mission-defined conditions indicate a credible threat to platform integrity. In this state, nonessential functions are shut down or isolated and the spacecraft operates from an integrity-protected, validated software and configuration baseline. Unlike traditional safe mode, which addresses hardware faults and operational anomalies, cyber-safe mode is specifically designed to respond to cyber threats, providing a secure recovery baseline from which the spacecraft can reconstitute compromised functions. Authentication and encryption must remain enabled within cyber-safe mode, ensuring that the reduced operational state does not degrade the security posture of the vehicle. The cyber-safe mode software and configuration must be stored onboard using hardware-based protections that prevent modification by nominal flight software, ordinary commands, and other untrusted execution paths. Where baseline updates are permitted, they must use a separately authorized and integrity-verified maintenance process that preserves a recoverable trusted version. Following entry into cyber-safe mode, the spacecraft must be capable of reconstituting firmware and software functions to pre-attack capability levels, either autonomously through self-healing mechanisms or with ground assistance, and must be capable of replanning operations based on whatever equipment remains available after the cyber event. The primary recovery objective is restoration of full mission capability; where that is not achievable, the spacecraft should attain the maximum reduced mission capability available given the post-attack system state.
Secure boot establishes and enforces a cryptographically verified chain of trust from a hardware-anchored root of trust (RoT) through each applicable stage of the startup sequence to the operating system or flight software image. Each stage in the chain must verify the integrity and authenticity of the next before transferring execution control. The boot policy must also prevent execution of unauthorized or revoked images, including unauthorized rollback to an older but validly signed software version. The trust anchor and initial verification function should be immutable after provisioning or protected by hardware-enforced mechanisms that prevent unauthorized modification and preserve their integrity. Components implementing the RoT must also be qualified for the expected mission radiation environment. Radiation tolerance addresses the reliability of the trust anchor, while immutability or protected update mechanisms address its resistance to unauthorized modification. This is particularly critical where radiation-induced bit flips and the physical inaccessibility of on-orbit hardware make a tamper-resistant, immutable hardware anchor essential to sustained boot integrity across the mission lifetime.