a. Employ integrity verification tools to detect unauthorized changes to the following software, firmware, and information: [Assignment: organization-defined software, firmware, and information]; and b. Take the following actions when unauthorized changes to the software, firmware, and information are detected: [Assignment: organization-defined actions].
| ID | Name | Description | D3FEND | |
| CM0049 | Machine Learning Data Integrity | When artificial intelligence (AI) or machine learning (ML) is employed for mission-critical spacecraft or ground system operations, the integrity of the training data set is a foundational security requirement, not merely a data quality concern. Data poisoning attacks introduce or modify training samples, labels, or other data-pipeline inputs to alter resulting model behavior. Poisoning may cause general performance degradation, targeted misclassification, or backdoor behavior that appears only when specific operational inputs or triggers are present. Remediation may require identifying and removing affected data, retraining or fine-tuning from a trusted dataset, or rolling back to a validated model. Because remediation can be difficult and may not identify every affected behavior, controls should prioritize preventing unauthorized data changes and detecting suspicious inputs before training while maintaining recoverable trusted dataset and model versions. Detection and prevention techniques include validity checking of data sets to identify statistically anomalous or out-of-distribution inputs, statistical analysis to detect injected samples that deviate from expected data distributions, manual analysis of flagged inputs, and regression testing over time to identify model behavioral drift that may indicate successful historical poisoning. These controls must be applied as part of a continuous data governance process spanning the full training pipeline, from data collection and curation through model validation and operational deployment. | D3-PH D3-FE D3-DENCR D3-PA D3-FA | |
| CM0004 | Development Environment Security | A secure development environment requires a current and sufficiently complete inventory of the people, devices, software, services, credentials, and automated identities capable of accessing or influencing the environment. The development environment includes source-code repositories, developer workstations, build servers, CI/CD runners, compiler and linker toolchains, container and virtual machine images, package registries, artifact repositories, signing systems, test environments, integration laboratories, and release-staging systems. For space systems, these environments may produce or manage flight software images, firmware, FPGA bitstreams, software-defined radio waveforms, command and telemetry databases, configuration tables, ephemerides, calibration products, fault-management logic, and on-orbit update packages. Unmanaged assets, unauthorized access, compromised dependencies, altered toolchains, and untrusted build services are significant pathways through which adversaries may maliciously modify software or other mission artifacts during development and build activities. All personnel and assets touching the development environment must be inventoried and actively managed. MFA shall be enforced for human access, while non-human identities shall use managed workload identities, scoped credentials, protected secrets, and defined rotation or expiration period, with particular rigor applied to code repositories, where threat actors may attempt to inject malicious code into software under development without detection. Zero-trust access controls should govern repository access, with protected branch and tag policies shall restrict direct modification, prohibit unauthorized force pushes or deletion, require successful security checks, and require independent review before merging or releasing critical code. Effective development environment security also requires integrated change management, privilege management, comprehensive audit logging, and continuous in-depth monitoring across all components of the environment. | D3-AI D3-AVE D3-SWI D3-HCI D3-NNI D3-OAM D3-AM D3-OM D3-DI D3-MFA D3-CH D3-OTP D3-BAN D3-PA D3- FAPA D3- DQSA D3-IBCA D3-PCSV D3-PSMD | |
| CM0010 | Update Software | Regular software and firmware updates are a primary mechanism for reducing exploitation risk by remediating known vulnerabilities before adversaries can leverage them against mission systems. Updates must undergo suitable regression testing to verify that security patches do not introduce functional defects or degrade safety-critical behaviors before deployment to operational systems. Release cadence should be governed by a mission-defined update frequency that balances vulnerability severity, exploitability, mission risk tolerance, testing requirements, and operational constraints. The program should define maximum allowable remediation or deployment timeframes (e.g., 30 days) for applicable vulnerability severities rather than applying a single update interval to all software and firmware. Update scheduling must account for operational constraints, coordinating patch deployment with mission downtime windows to avoid disrupting critical operations. Following a successful update, superseded software versions should be removed from active operational use unless retained as an authorized recovery image. Verified restoration images, commonly referred to as gold images, should be retained under access and integrity controls to support recovery when an update introduces unacceptable system behavior or an authorized rollback is operationally required. | D3-SU | |
| CM0011 | Vulnerability Scanning | Vulnerability scanning systematically identifies known security weaknesses in commercial off-the-shelf (COTS) and open-source software (OSS) components, including vulnerable dependencies and outdated software versions, across spacecraft and ground system environments. Custom-developed code requires separate analysis approaches, such as static and dynamic code analysis, that fall outside the scope of this countermeasure; however, COTS, OSS, and third-party dependencies incorporated into custom-developed software remain within the scope of vulnerability scanning and SCA. Scanning programs should incorporate software composition analysis (SCA) to detect vulnerabilities introduced through third-party libraries and dependency chains, which represent a significant and frequently underestimated attack surface in modern space systems. Scanning tools and processes should conform to recognized interoperability standards that support enumeration of platforms, software flaws, and configuration weaknesses; standardized formatting of checklists and test procedures; and consistent measurement of vulnerability impact. Adherence to these standards enables automation of key vulnerability management workflow steps, facilitates tool interoperability across the mission ecosystem, and produces outputs that are comparable across programs and organizations. Vulnerability scanning shall be performed against the approved as-built or deployed software baseline using methods that do not jeopardize mission operations. Active scanning of live spacecraft, safety-critical ground systems, or operational technology should occur only after the scanning method has been authorized and evaluated for operational impact. Where live scanning presents unacceptable risk, scanning should be performed against representative software images, firmware packages, or test environments that match the approved operational baseline. | D3-AI D3-NM D3-AVE D3-NVA D3-PM D3-FBA D3-OSM D3-SFA D3-PA D3-PSA D3-PLA D3-PCSV D3-FA D3-DA D3-ID D3-HD D3-UA | |
| CM0012 | Software Bill of Materials | 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. | D3-AI D3-AVE D3-SWI | |
| CM0013 | Dependency Confusion | Dependency confusion is a software supply chain attack in which an adversary publishes a malicious package to a public repository using the same name as an organization's internal private package, exploiting build tools that may inadvertently resolve the public version over the intended internal one. Mitigating this attack requires a layered set of controls: internal dependencies must be sourced exclusively from private, controlled repositories rather than public package registries; build and continuous integration and continuous delivery (CI/CD) pipeline configurations must explicitly define trusted repository sources and resolution order to prevent inadvertent public package substitution; and dependency integrity must be validated at the point of consumption by verifying that cryptographic checksums match those of the known-good official packages. A secure build environment is a prerequisite for these controls to be effective, as a compromised build environment can undermine dependency controls regardless of repository configuration. Together, these measures ensure that only verified, intended dependencies are incorporated into flight software, ground system software, and supporting toolchains. | D3-LFP D3-UBA D3-RAPA D3-MAC | |
| CM0015 | Software Source Control | 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. | D3-PM D3-SBV D3-EI D3-EAL D3- EDL D3-DCE | |
| CM0016 | CWE List | A prioritized list of software weakness classes, drawn from a recognized weakness enumeration taxonomy such as the common weakness enumeration (CWE) framework, provides the analytical foundation for targeted, mission-relevant static code analysis. Rather than treating all weakness classes as equally significant, mission teams should derive a system-specific priority ranking based on the spacecraft or ground system's architecture, threat environment, operational constraints, and consequence of exploitation for each weakness class. This prioritized list serves two functions: it directs static analysis tool configuration toward the weakness classes most relevant to the mission, and it provides a defensible, documented basis for triaging and ranking analysis findings so that remediation resources are applied where mission risk is highest. The prioritization rationale should be documented and maintained as a controlled artifact, as it reflects security-relevant design decisions about the system's risk posture. | D3-AI D3-AVE | |
| CM0017 | Coding Standard | A formally defined coding standard establishes the rules, conventions, and constraints that govern how software is written across the mission's development program, directly influencing the security, maintainability, and verifiability of the delivered system. The standard must specify acceptable programming language types, with language selection driven by a documented evaluation of security requirements, application complexity, scalability needs, available development resources, schedule constraints, and the availability of security-relevant language features such as memory safety, type safety, and bounds checking. Language choices that introduce classes of vulnerability by design, such as languages without memory safety guarantees used in contexts where memory corruption is a plausible attack vector, require explicit justification and compensating controls. The coding standard must include security-relevant rules for input validation, error handling, cryptographic usage, memory management, and concurrency, as applicable to the selected languages and system design. Adherence should be evaluated through automated means where supported, supplemented by manual review for requirements that cannot be reliably automated. | D3-AI D3-AVE D3-SWI D3-DCE D3-EHPV D3-ORA D3-FEV D3-FR D3-ER D3-PE D3-PT D3-PS | |
| CM0018 | Dynamic Testing | Dynamic analysis subjects executing software and firmware to active testing conditions to identify weaknesses and vulnerabilities that static analysis alone cannot detect, including runtime memory corruption, logic errors, timing vulnerabilities, and interface behaviors that only manifest under operational conditions. Applicable techniques include simulation-based testing, penetration testing, fuzz testing, and adversarial emulation using realistic threat actor tactics, techniques, and procedures (TTPs). Dynamic testing must be applied to all software and firmware categories: mission-developed code, open-source components, commercial off-the-shelf (COTS) software, and third-party developed code. Dynamic testing should be performed on potential system elements before acceptance, include realistic simulation of known adversary TTPs, and tools, and continue throughout the lifecycle on applicable physical and logical systems, elements, and processes. Full-scale hardware integration testbeds, commonly referred to as flat satellite (FLATSAT) environments, provide high-fidelity physical test platforms for dynamic analysis; digital twins implemented via instruction set simulation, also known as emulation, provide a flexible and scalable alternative environment capable of supporting TTP execution across a broad range of test scenarios without requiring physical hardware availability. | D3-DA D3-FBA D3-PSA D3-PLA D3-PA D3-SEA D3-MBT | |
| CM0019 | Static Analysis | Static source code analysis examines software without executing it, identifying security-relevant weaknesses in the codebase before they can be exploited at runtime. Static analysis must be performed across all available source code. The mission’s weakness prioritization (i.e., CM0016) process should guide tool configuration and finding triage without unnecessarily excluding other weakness classes supported by the tools. The static analysis program must employ no fewer than two distinct tools with complementary language and weakness-detection capabilities. The tools should be applied at defined points throughout the development and maintenance lifecycle to provide overlapping and complementary analysis coverage and reduce the likelihood that exploitable weaknesses persist into integration or deployment. Tool selection should account for language compatibility, weakness class coverage, and the ability to produce findings in formats that support triage and remediation tracking. Static analysis should be integrated into the software build pipeline as an automated, recurring activity rather than conducted as a periodic manual exercise, ensuring that new code contributions are analyzed continuously throughout development. | D3-PM D3-FBA D3-FEMC D3-FV D3-PFV D3-SFV D3-OSM | |
| CM0021 | Software Digital Signature | 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. | D3-CH D3-CBAN D3-FV D3-DLIC D3-EAL D3-SBV | |
| CM0023 | Configuration Management | 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. | D3-ACH D3-CI D3-SICA D3-USICA | |
| CM0014 | Secure boot | 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. | D3-PH D3-BA D3-DLIC D3-TBI | |
| ID | Description | |
| SV-CF-2 |
Eavesdropping (RF and proximity) |
|
| SV-IT-2 |
Unauthorized modification or corruption of data |
|
| SV-MA-3 |
Attacks on critical software subsystems Attitude Determination and Control (AD&C) subsystem determines and controls the orientation of the satellite. Any cyberattack that could disrupt some portion of the control loop - sensor data, computation of control commands, and receipt of the commands would impact operations Telemetry, Tracking and Commanding (TT&C) subsystem provides interface between satellite and ground system. Computations occur within the RF portion of the TT&C subsystem, presenting cyberattack vector Command and Data Handling (C&DH) subsystem is the brains of the satellite. It interfaces with other subsystems, the payload, and the ground. It receives, validate, decodes, and sends commands to other subsystems, and it receives, processes, formats, and routes data for both the ground and onboard computer. C&DH has the most cyber content and is likely the biggest target for cyberattack. Electrical Power Subsystem (EPS) provides, stores, distributes, and controls power on the satellite. An attack on EPS could disrupt, damage, or destroy the satellite. |
|
| SV-SP-1 |
Exploitation of software vulnerabilities (bugs); Unsecure code, logic errors, etc. in the FSW. |
|
| SV-SP-3 |
Introduction of malicious software such as a virus, worm, Distributed Denial-Of-Service (DDOS) agent, keylogger, rootkit, or Trojan Horse |
|
| SV-SP-6 |
Software reuse, COTS dependence, and standardization of onboard systems using building block approach with addition of open-source technology leads to supply chain threat |
|
| SV-SP-9 |
On-orbit software updates/upgrades/patches/direct memory writes. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code |
|
| SV-AC-6 |
Three main parts of S/C. CPU, memory, I/O interfaces with parallel and/or serial ports. These are connected via busses (i.e., 1553) and need segregated. Supply chain attack on CPU (FPGA/ASICs), supply chain attack to get malware burned into memory through the development process, and rogue RTs on 1553 bus via hosted payloads are all threats. Security or fault management being disabled by non-mission critical or payload; fault injection or MiTM into the 1553 Bus - China has developed fault injector for 1553 - this could be a hosted payload attack if payload has access to main 1553 bus; One piece of FSW affecting another. Things are not containerized from the OS or FSW perspective; |
|
| SV-IT-3 |
Compromise boot memory |
|
| SV-SP-7 |
Software can be broken down into three levels (operating system and drivers’ layer, data handling service layer, and the application layer). Highest impact on system is likely the embedded code at the BIOS, kernel/firmware level. Attacking the on-board operating systems. Since it manages all the programs and applications on the computer, it has a critical role in the overall security of the system. Since threats may occur deliberately or due to human error, malicious programs or persons, or existing system vulnerability mitigations must be deployed to protect the OS. |
|
| SV-AV-6 |
Complete compromise or corruption of running state |
|
| SV-DCO-1 |
Not knowing that you were attacked, or attack was attempted |
|
| SV-IT-1 |
Communications system spoofing resulting in denial of service and loss of availability and data integrity |
|
| SV-AC-7 |
Weak communication protocols. Ones that don't have strong encryption within it |
|
| SV-MA-7 |
Exploit ground system and use to maliciously to interact with the spacecraft |
|
| SV-MA-6 |
Not planning for security on SV or designing in security from the beginning |
|
| SPARTA ID | Requirement | Rationale/Additional Guidance/Notes |
|---|---|---|
| SPR-245 | The [organization] shall define processes and procedures to be followed when integrity verification tools detect unauthorized changes to software, firmware, and information.{SV-IT-2}{CM-3,CM-3(1),CM-3(5),CM-5(6),CM-6,CP-2,IR-6,IR-6(2),PM-30,SC-16(1),SC-51,SI-3,SI-4(7),SI-4(24),SI-7,SI-7(7),SI-7(10)} | Predefined response procedures reduce reaction time. Clear escalation paths improve containment. Consistent handling prevents confusion during incidents. Preparedness strengthens resilience. |
| SPR-437 | The [organization] shall enable integrity verification of software and firmware components.{SV-IT-2}{CM-3(5),CM-5(6),CM-10(1),SA-8(9),SA-8(11),SA-8(21),SA-10(1),SI-3,SI-4(24),SI-7,SI-7(10),SI-7(12),SR-4(4)} | * The integrity verification mechanisms may include: ** Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites; ** Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery; ** Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure; ** Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses; ** Implementing cryptographic hash verification; and ** Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing. ** Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites; ** Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery; ** Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure; ** Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses; ** Implementing cryptographic hash verification; and ** Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing. |
| SPR-450 | The [spacecraft] shall prevent flight software and payload applications from modifying access control labels or rules and shall validate label integrity at startup and during policy updates.{SV-AC-1,SV-IT-2}{AC-3(3),AC-3(11).AC-16,SI-7} | Label integrity ensures policy decisions remain trustworthy. Preventing modification protects data classification enforcement. Validation at startup prevents persistent compromise. Policy integrity underpins MAC assurance. |
| SPR-503 | The [organization] shall validate authenticity and integrity of all flight-designated hardware, firmware, and software upon receipt using program-controlled trust anchors (approved vendor list, golden hash/cert manifest){SV-SP-4,SV-SP-5}{SR-4(3),SR-11,SI-7} | Receipt validation prevents counterfeit or tampered parts integration. Program-controlled trust anchors ensure consistency. Early detection reduces downstream risk. Intake verification strengthens SCRM posture. |
| SPR-504 | The [organization] shall re-validate component identity (serial/lot), firmware measurements (cryptographic hashes), and certificate status immediately prior to installation, writing results to the SCRM/provenance ledger and blocking install on mismatch.{SV-SP-4,SV-SP-5}{SR-4(3),SR-11,SI-7} | Installation-time validation prevents stale or revoked components. Ledger recording strengthens traceability. Blocking on mismatch prevents compromise propagation. Continuous verification enhances assurance. |
| SPR-505 | The [spacecraft] shall cryptographically verify boot images and configurations at power-on and after any update{SV-IT-3,SV-SP-9}{SR-4(3),SI-7,CM-14} | Secure boot prevents execution of unauthorized code. Post-update verification ensures integrity continuity. Root-of-trust enforcement protects mission-critical logic. Deterministic startup strengthens resilience. |
| SPR-528 | The [organization] shall package each flight change (software, bitstreams, configuration tables) with a signed manifest, precondition checks (mode, power/thermal, link), explicit hold/commit points, and resumable procedures across AOS/LOS; the [spacecraft] shall enforce manifest checks prior to activation.{SV-SP-9,SV-IT-2}{CM-3,CM-3(2),SI-7,SA-10} | Manifest enforcement ensures integrity prior to activation. Precondition checks prevent unsafe changes. Resumable logic supports space contact constraints. Structured packaging strengthens update security. |
| SPR-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-547 | The [spacecraft] shall support chunked uploads of software/bitstreams/configuration with per‑chunk verification and commit markers, resumable across passes, with atomic activation and rollback if activation checks fail.{SV-SP-9,SV-IT-2}{SI-7,SI-7(15)} | Per-chunk verification prevents partial corruption. Atomic activation avoids inconsistent states. Rollback ensures safe recovery. Structured update logic strengthens resilience. |
| ID | Name | Description | |
|---|---|---|---|
| REC-0006 | Gather FSW Development Information | Adversaries collect a cradle-to-operations view of how flight software is built, tested, signed, and released. Useful artifacts include architecture docs, source trees and SBOMs, compiler/linker toolchains and flags, RTOS and middleware versions, build scripts, CI/CD pipelines, code-signing workflows, defect trackers, and release notes that describe “as-built” vs. “as-flown” deltas. They also seek integration environments, emulators/SIL, flatsats/iron birds, hardware-in-the-loop rigs, and the autonomy/FDIR logic that governs mode transitions and patch acceptance. With this knowledge, a threat actor can identify weak crypto or provenance controls on update paths, predict error-handling behavior, and craft inputs that slip past unit/integration tests. Even small disclosures (e.g., a linker script, an assert string, or a sanitized crash dump) shrink the search space for exploitation. | |
| REC-0006.01 | Development Environment | Threat actors enumerate the exact environment used to produce flight builds: IDEs and plugins, cross-compilers and SDKs, container images/VMs, environment variables, path conventions, build systems, static libraries, and private package registries. They correlate repository layouts (mono- vs multi-repo), branch and review policies, protected branches/tags, and CI orchestrators to find where policy gaps allow unreviewed code or tool updates. Secrets embedded in configs (tokens, service accounts), permissive compiler/linker flags, or disabled hardening options are especially valuable. Knowledge of debug/diagnostic builds, symbol servers, and crash-dump handling lets an adversary reconstruct higher-fidelity testbeds or derive function boundaries in stripped images. | |
| IA-0001 | Compromise Supply Chain | Adversaries achieve first execution before the spacecraft ever flies by inserting malicious code, data, or configuration during manufacturing, integration, or delivery. Targets include software sources and dependencies, build systems and compilers, firmware/bitstreams for MCUs and FPGAs, configuration tables, test vectors, and off-the-shelf avionics. Inserted artifacts are designed to appear legitimate, propagate through normal processes, and activate under routine procedures or specific modes (e.g., safing, maintenance). Common insertion points align with where trust is assumed, vendor updates, mirrors and registries, CI/CD runners, programming stations, and “golden image” repositories. The result is pre-positioned access that blends with baseline behavior, often with delayed or conditional triggers and strong deniability. | |
| IA-0001.01 | Software Dependencies & Development Tools | This technique targets what developers import and the tools that transform source into flight binaries. Methods include dependency confusion and typosquatting, poisoned container/base images, malicious IDE plugins, and compromised compilers, linkers, or build runners that subtly alter output. Because flight and ground stacks frequently reuse open-source RTOS components, crypto libraries, protocol parsers, and build scripts, an upstream change can deterministically reproduce a backdoor downstream. Attackers also seed private mirrors or caches so “trust-on-first-use” locks in tainted packages, or abuse CI secrets and environment variables to pivot further. Effects range from inserting covert handlers into command parsers, to weakening integrity checks in update paths, to embedding telemetry beacons that exfiltrate build metadata helpful for later stages. | |
| IA-0001.02 | Software Supply Chain | Here the manipulation targets software delivered to flight or ground systems: altering source before build, swapping signed binaries at distribution edges, subverting update metadata, or using stolen signing keys to issue malicious patches. Space-specific vectors include mission control applications, schedulers, gateway services, flight tables and configuration packages, and firmware loads during I&T or LEOP. Adversaries craft payloads that pass superficial validation, trigger under particular operating modes, or reintroduce known weaknesses through version rollback. “Data payloads” such as malformed tables, ephemerides, or calibration products can double as exploits when parsers are permissive. The objective is to ride the normal promotion pipeline so the implant arrives pre-trusted and executes as part of routine operations. | |
| IA-0001.03 | Hardware Supply Chain | Adversaries alter boards, modules, or programmable logic prior to delivery to create latent access or reliability sabotage. Tactics include inserting hardware Trojans in ASIC/FPGA designs, modifying bitstreams or disabling security fuses, leaving debug interfaces (JTAG/SWD/UART) active, substituting near-spec counterfeits, or embedding parts that fail after specific environmental or temporal conditions (“time-bomb” components). Other avenues target programming stations and “golden” images so entire lots inherit the same weakness. Microcontroller boot configurations, peripheral EEPROMs, and supervisory controllers are common leverage points because small changes there can reshape trust boundaries across the bus. The effect is a platform that behaves nominally through acceptance test yet enables covert control, targeted degradation, or delayed failure once on orbit. | |
| IA-0002 | Compromise Software Defined Radio | Adversaries target SDR-based transceivers and payload radios because reconfigurable waveforms, FPGA bitstreams, and software flowgraphs create programmable footholds. Manipulation can occur in the radio’s development pipeline (toolchains, out-of-tree modules), at integration (loading of bitstreams, DSP coefficients, calibration tables), or in service via update channels that deliver new waveforms or patches. On-orbit SDRs often expose control planes (command sets for mode/load/select), data planes (baseband I/Q), and management/telemetry paths, any of which can embed covert behavior, alternate demod paths, or hidden subcarriers. A compromised SDR can establish clandestine command-and-control by activating non-public waveforms, piggybacking on idle fields, or toggling to time/ephemeris-triggered profiles that blend with nominal operations. On the ground, compromised SDR modems can be used to fabricate mission-compatible emissions or to decode protected downlinks for reconnaissance. Attackers leverage the SDR’s malleability so that malicious signaling, once seeded, presents as a legitimate but rarely exercised configuration. | |
| IA-0004 | Secondary/Backup Communication Channel | Adversaries pursue alternative paths to the spacecraft that differ from the primary TT&C in configuration, monitoring, or authentication. Examples include backup MOC/ground networks, contingency TT&C chains, maintenance or recovery consoles, low-rate emergency beacons, and secondary receivers or antennas on the vehicle. These channels exist to preserve commandability during outages, safing, or maintenance; they may use different vendors, legacy settings, or simplified procedures. Initial access typically pairs reconnaissance of failover rules with actions that steer operations onto the backup path, natural events, induced denial on the primary, or simple patience until scheduled tests and handovers occur. Once traffic flows over the alternate path, the attacker leverages its distinct procedures, dictionaries, or rate/size limits to introduce commands or data that would be harder to inject on the primary. | |
| IA-0004.02 | Receiver | Threat actors may target the spacecraft’s secondary (backup) RF receive path, often a differently sourced radio, alternate antenna/feed, or cross-strapped front end that is powered or enabled under specific modes. Threat actors map when the backup comes into play (safing, antenna obscuration, maintenance, link degradation) and what command dictionaries, framing, or authentication it expects. If the backup receiver has distinct waveforms, counters, or vendor defaults, the attacker can inject traffic that is accepted only when that path is active, limiting exposure during nominal ops. Forcing conditions that enable the backup, jamming the primary, exploiting geometry, or waiting for routine tests, creates the window for first execution. The result is a foothold gained through a rarely used RF path, exploiting differences in implementation and operational cadence between primary and standby receive chains. | |
| IA-0006 | Compromise Hosted Payload | Adversaries target hosted payloads as an alternate doorway into the host spacecraft. Hosted payloads often expose their own command sets, file services, and telemetry paths, sometimes via the host’s TT&C chain, sometimes through a parallel ground infrastructure under different operational control. Initial access arises when an attacker obtains the ability to issue payload commands, upload files, or alter memory/register state on the hosted unit. Because data and control must traverse an interface to the host bus (power, time, housekeeping, data routing, gateway processors), the payload–host boundary can also carry management functions: mode transitions, table loads, firmware updates, and cross-strapped links that appear only in maintenance or contingency modes. With knowledge of the interface specification and command dictionaries, a threat actor can activate rarely used modes, inject crafted data products, or trigger gateway behaviors that extend influence beyond the payload itself. In multi-tenant or commercial hosting arrangements, differences in keying, procedures, or scheduling between the payload operator and the bus operator provide additional opportunity for a first foothold that looks like routine payload commanding. | |
| IA-0007 | Compromise Ground System | Compromising the ground segment gives an adversary the most direct path to first execution against a spacecraft. Ground systems encompass operator workstations and mission control mission control software, scheduling/orchestration services, front-end processors and modems, antenna control, key-loading tools and HSMs, data gateways (SLE/CSP), identity providers, and cloud-hosted mission services. Once inside, a threat actor can prepare on-orbit updates, craft and queue valid telecommands, replay captured traffic within acceptance windows, or manipulate authentication material and counters to pass checks. The same foothold enables deep reconnaissance: enumerating mission networks and enclaves, discovering which satellites are operated from a site, mapping logical topology between MOC and stations, identifying in-band “birds” reachable from a given aperture, and learning pass plans, dictionaries, and automation hooks. From there, initial access to the spacecraft is a matter of timing and presentation, injecting commands, procedures, or update packages that align with expected operations so the first execution event appears indistinguishable from normal activity. | |
| IA-0007.01 | Compromise On-Orbit Update | Adversaries may target the pipeline that produces and transmits updates to an on-orbit vehicle. Manipulation points include source repositories and configuration tables, build and packaging steps that generate images or differential patches, staging areas on ground servers, update metadata (versions, counters, manifests), and the transmission process itself. Spacecraft updates span flight software patches, FPGA bitstreams, bootloader or device firmware loads, and operational data products such as command tables, ephemerides, and calibration files, each with distinct formats, framing, and acceptance rules. An attacker positioned in the ground system can substitute or modify an artifact, alter its timing and timetags to match pass windows, and queue it through the same procedures operators use for nominal maintenance. Activation can be immediate or deferred: implants may lie dormant until a specific mode, safing entry, or table index is referenced. | |
| IA-0011 | Auxiliary Device Compromise | Adversaries abuse peripherals and removable media that the spacecraft (or its support equipment) ingests during development, I&T, or on-orbit operations. Small satellites and hosted payloads frequently expose standard interfaces, USB, UART, Ethernet, SpaceWire, CAN, or mount removable storage for loading ephemerides, tables, configuration bundles, or firmware. A tainted device can masquerade as a trusted class (mass-storage, CDC/HID) or present crafted files that trigger auto-ingest workflows, file watchers, or maintenance utilities. Malware may be staged by modifying the peripheral’s firmware, seeding the images written by lab formatting tools, or swapping media during handling. Once connected, the device can deliver binaries, scripts, or malformed data products that execute under existing procedures. Because these interactions often occur during hurried timelines (checkouts, rehearsals, contingency maintenance), the initial execution blends with legitimate peripheral use while traversing a path already privileged to reach flight software or controllers. | |
| IA-0012 | Assembly, Test, and Launch Operation Compromise | Assembly, Test, and Launch Operation (ATLO) concentrates people, tools, and authority while components first exchange real traffic across flight interfaces. Test controllers, EGSE, simulators, flatsats, loaders, and data recorders connect to the same buses and command paths that will exist on orbit. Threat actors exploit this density and dynamism: compromised laptops or transient cyber assets push images and tables; lab networks bridge otherwise separate enclaves; vendor support accounts move software between staging and flight hardware; and “golden” artifacts created or modified in ATLO propagate into the as-flown baseline. Malware can traverse shared storage and scripting environments, ride update/checklist execution, or piggyback on protocol translators and gateways used to stimulate subsystems. Because ATLO often introduces late firmware loads, key/counter initialization, configuration freezes, and full-system rehearsals, a single well-placed change can yield first execution on multiple devices and persist into LEOP. | |
| IA-0013 | Compromise Host Spacecraft | The inverse of "IA-0006: Compromise Hosted Payload", this technique describes adversaries that are targeting a hosted payload, the host space vehicle (SV) can serve as an initial access vector to compromise the payload through vulnerabilities in the SV's onboard systems, communication interfaces, or software. If the SV's command and control systems are exploited, an attacker could gain unauthorized access to the vehicle's internal network. Once inside, the attacker may laterally move to the hosted payload, particularly if it shares data buses, processors, or communication links with the vehicle. | |
| EX-0003 | Modify Authentication Process | The adversary alters how the spacecraft validates authority so that future inputs are accepted on their terms. Modifications can target code (patching flight binaries, hot-patching functions in memory, hooking command handlers), data (changing key identifiers, policy tables, or counter initialization), or control flow (short-circuiting MAC checks, widening anti-replay windows, bypassing interlocks on specific opcodes). Common choke points include telecommand verification routines, bootloader or update verifiers, gateway processors that bridge payload and bus traffic, and maintenance dictionaries invoked in special modes. Subtle variants preserve outward behavior, producing normal-looking acknowledgments and counters, while internally accepting a broader set of origins, opcodes, or timetags. Others introduce conditional logic so the backdoor only activates under specific geometry or timing, masking during routine audit. Once resident, the modified process becomes the new trust oracle, enabling recurring execution for the attacker and, in some cases, denying legitimate control by causing authentic inputs to fail verification or to be deprioritized. | |
| EX-0004 | Compromise Boot Memory | The attacker manipulates memory and configuration used in the earliest stages of boot so that their code runs before normal protections and integrity checks take hold. Targets include boot ROM vectors, first-stage/second-stage bootloaders, boot configuration words and strap pins, one-time-programmable (OTP) fuses, non-volatile images in flash/EEPROM, and scratch regions copied into RAM during cold start. Techniques range from replacing or patching boot images to flipping configuration bits that alter trust decisions (e.g., image selection, fallback order, watchdog behavior). Faults can be induced deliberately (timed power/clock/EM glitches) or via crafted update/write sequences that leave a partially programmed but executable state. Once resident, the modification can insert early hooks, disable or short-circuit checks, or select downgraded images; destructive variants corrupt the boot path to induce a persistent reset loop or safeing entry (a denial of service). Because boot logic initializes buses, memory maps, and handler tables, even small changes at this stage cascade, shaping how command handlers load, how keys and counters are initialized, and which peripherals are trusted for subsequent execution. | |
| EX-0005 | Exploit Hardware/Firmware Corruption | The adversary achieves execution or effect beneath the software stack, in device firmware, programmable logic, or the hardware itself, either by corrupting that layer or by driving it through interfaces that function exactly as designed. Examples include tampering with firmware images or configuration blobs burned into non-volatile memory; targeting MCU/SoC boot ROM fallbacks; editing FPGA bitstreams or partial-reconfiguration frames; leveraging physical phenomena and timing to flip bits or skip checks; or issuing legitimate low-level device, maintenance, and calibration commands that act directly on hardware without passing through high-level command mediation. Because these actions occur below or alongside the operating system and application FSW, traditional endpoint safeguards see normal interfaces while trust anchors are already altered. | |
| EX-0005.01 | Design Flaws | Threat actors may exploit inherent properties or errata in the hardware/logic design rather than injecting new code. Levers include undocumented or weakly specified behaviors (scan chains, test modes, debug straps), counter/timer rollovers and wraparound, interrupt storms and priority inversions, MMU/TLB corner cases, DMA engines that can write outside intended buffers, and bus arbitration or clock-domain crossing issues that permit stale or reordered writes. RNGs and crypto accelerators with flawed seeding or side-channel leakage can expose secrets or enable predictable authentication values. In programmable logic, vulnerable state machines, insufficient reset paths, and hazardous partial-reconfiguration regions create opportunities to drive the design into privileged or undefined states. Even reliability features can be turned: hardware timers intended for liveness can be paced to starve control loops; ECC policies can be nudged so correction conceals attacker-induced drift. The common thread is using the platform’s own guarantees, timing, priority, persistence, or fault handling, to cause privileged behavior that the software stack accepts as “by design.” | |
| EX-0008 | Time Synchronized Execution | Malicious logic is arranged to run at precise times derived from onboard clocks or distributed time sources. The trigger may be absolute or relative. Spacecraft commonly maintain multiple clocks and counters and schedule autonomous sequences against them. An attacker leverages this machinery to ensure effects occur during tactically advantageous windows. Time-based execution reduces exposure, simplifies coordination across assets, and makes reproduction difficult in lab settings that lack the same temporal context. | |
| EX-0008.01 | Absolute Time Sequences | Execution is keyed to a fixed wall-clock timestamp or epoch, independent of current vehicle state. The implant watches a trusted time source, GNSS-derived time, crosslink-distributed network time, oscillator-disciplined UTC/TAI, or mission elapsed time anchored at activation, and triggers exactly at a programmed date/time. Absolute triggering supports coordinated multi-asset actions and allows long dormancy with a precise activation moment. Variants incorporate calendar logic (e.g., “first visible pass after YYYY-MM-DD hh:mm:ss”) or guard bands to fire only if the clock is within certain tolerances, ensuring the event occurs even with minor drift yet remains rare enough to blend with scheduled operations. | |
| EX-0008.02 | Relative Time Sequences | Execution is keyed to elapsed time since a reference event. The implant latches a start point, boot, reset, safing entry/exit, receipt of a particular telemetry/command pattern, achievement of sun-pointing, and arms a countdown or set of offsets (“N seconds after event,” “repeat every M cycles”). Relative sequences are resilient to clock discontinuities and mirror how many spacecraft schedule internal activities (e.g., after boot, run calibrations; after acquisition, start downlink). An attacker exploits this to ensure the trigger fires only within specific operational phases and to survive resets that would thwart absolute timestamps: after every reboot, wait for housekeeping steady state, then act; or, after a wheel unload completes, inject an additional command while control laws are in a known configuration. | |
| EX-0009 | Exploit Code Flaws | The adversary executes actions on-board by abusing defects in software that runs on the vehicle, ranging from application logic in flight software to libraries, drivers, and supporting services. Outcomes range from arbitrary code execution and privilege escalation to silent logic manipulation (e.g., bypassing interlocks, suppressing alarms) that appears operationally plausible. The hallmark of this technique is that the attacker co-opts existing code paths, often rarely used ones, to run unintended behavior under nominal interfaces. These attacks may be extremely targeted and tailored to specific coding errors introduced as a result of poor coding practices or they may target known issues in the commercial software components. | |
| EX-0009.01 | Flight Software | Flight software presents rich attack surface where mission-specific parsing and autonomy live. Vulnerable components include command and telemetry handlers, table loaders, file transfer services, mode management and safing logic, payload control applications, and gateway processes that bridge payload and bus protocols. Typical flaws are unchecked lengths and indices in command fields, arithmetic overflows in rate/size calculations, insufficient validation of table contents, format-string misuse in logging, incomplete state cleanup across rapid mode changes, and race conditions in concurrent message processing. Some FSW suites expose operator-facing APIs or scripting/procedure engines used for automation; malformed invocations can coerce unexpected behaviors or enable arbitrary expressions. Because many subsystems act on “last write wins,” logic errors can yield durable configuration changes without obvious anomalies in protocol syntax. Successful exploitation lets an adversary execute code, alter persistent parameters, or chain effects across partitions that would otherwise be segmented by design. | |
| EX-0009.02 | Operating System | At the OS layer, the attacker targets primitives that schedule work and mediate hardware. Modern spacecraft, particularly small satellites, increasingly rely on Linux-based operating systems (e.g., Yocto-derived distributions) rather than traditional RTOSes, significantly expanding the applicable attack surface to include techniques documented in MITRE ATT&CK for Linux - <a href='https://attack.mitre.org/matrices/enterprise/linux/' class='internal-link' target='_blank'>https://attack.mitre.org/matrices/enterprise/linux/</a>. Maintenance builds may expose shells or management consoles; misconfigurations around these interfaces can provide paths to command interpreters or privileged syscalls. Linux-based flight systems inherit standard Unix/Linux vulnerabilities including kernel exploits, container escapes, privilege escalation via misconfigured sudo/capabilities, and exploitation of systemd or other init systems. Exploitation yields kernel-mode execution, arbitrary memory read/write, or control of scheduling and address spaces, letting the actor tamper with FSW processes, intercept command paths, or manipulate storage and bus drivers beneath application checks. Common Linux-specific vectors include exploiting unpatched kernel vulnerabilities, abusing misconfigurations in containerized environments, leveraging POSIX API weaknesses in flight applications, and targeting shared libraries or dynamic linkers to inject malicious code into flight processes. The technique leverages generic OS weaknesses adapted to the spacecraft's particular build, turning low-level control into mission-facing effects that appear to originate from legitimate processes. Because spacecraft Linux builds are often minimized, long-lived (limited patching), and may retain debug interfaces or permissive file permissions from ground testing, they present a unique risk profile combining embedded-system constraints with commodity OS attack techniques. Flight images frequently retain extraneous binaries and utilities (e.g., compilers, debuggers, network tools, package managers) intended for ground testing or development that are not removed before launch, providing adversaries with ready-made 'living off the land' capabilities for reconnaissance, lateral movement, and privilege escalation without needing to upload custom tooling. | |
| EX-0009.03 | Known Vulnerability (COTS/FOSS) | Using knowledge of the software composition on-board, the adversary maps components and versions to publicly or privately known defects and then crafts inputs to trigger them. Typical targets include standard libraries (libc, STL), cryptographic and compression libraries, protocol stacks (CCSDS implementations, IP over space links, SpaceWire bridges), filesystems and parsers (FITS/CCSDS packetization, custom table formats), and vendor SDKs for radios, sensors, or payloads. Triggers arrive as well-formed but malicious packets, frames, or files whose edge-case fields exercise version-specific bugs, overflowing a parser, bypassing an authentication check, or causing a kernel/driver fault that reboots into a more permissive mode. Because these flaws are documented somewhere, exploitation emphasizes matching the exact build and build-time options used on the mission. | |
| EX-0010 | Malicious Code | The adversary achieves on-board effects by introducing executable logic that runs on the vehicle, either native binaries and scripts, injected shellcode, or “data payloads” that an interpreter treats as code (e.g., procedure languages, table-driven automations). Delivery commonly piggybacks on legitimate pathways: software/firmware updates, file transfer services, table loaders, maintenance consoles, or command sequences that write to executable regions. Once staged, activation can be explicit (a specific command, mode change, or file open), environmental (time/geometry triggers), or accidental, where operator actions or routine autonomy invoke the implanted logic. Malicious code can target any layer it can reach: altering flight software behavior, manipulating payload controllers, patching boot or device firmware, or installing hooks in drivers and gateways that bridge bus and payload traffic. Effects range from subtle logic changes (quiet data tampering, command filtering) to overt actions (forced mode transitions, resource starvation), and may include secondary capabilities like covert communications, key material harvesting, or persistence across resets by rewriting images or configuration entries. | |
| EX-0010.01 | Ransomware | Ransomware on a spacecraft encrypts data or critical configuration so that nominal operations can no longer proceed without the attacker’s cooperation. Targets include mass-memory file stores (engineering telemetry, payload data), configuration and command tables, event logs, on-board ephemerides, and even intermediate buffers used by downlink pipelines. Some variants interfere with key services instead of bulk data, e.g., encrypting a command dictionary or table index so valid inputs are rejected, or wrapping the payload data path in an attacker-chosen cipher so downlinked products appear as noise. By denying access to on-board content or control artifacts at scale, attackers convert execution into bargaining power or irreversible mission degradation. | |
| EX-0010.02 | Wiper Malware | Wipers deliberately destroy or irreversibly corrupt data and, in some cases, executable images to impair or end mission operations. Destructive routines may overwrite with patterns or pseudorandom data, repeatedly reformat volumes, trigger wear mechanisms on non-volatile memory, or manipulate low-level translation layers so recovery tools see a blank or inconsistent device. Activation can be immediate or staged, sleeping until a specific time, pass, or maintenance action, and may be paired with anti-recovery steps such as erasing checksums, undo logs, or golden images. Because wipers operate at storage and image layers that underpin many subsystems, collateral effects can cascade: autonomy enters safing without viable recovery paths, downlinks carry only noise, and subsequent updates cannot be authenticated or applied. The defining feature is irreversible loss of data or executables as the primary objective, rather than concealment or monetization. | |
| EX-0010.03 | Rootkit | A rootkit hides the presence and activity of other malicious components by interposing on the mechanisms that report system state. On spacecraft this can occur within flight software processes, at OS kernel level, inside separation kernels/hypervisors, or down in system firmware where drivers and initialization routines run. Techniques include API and syscall hooking, patching message queues and inter-process communication paths, altering task lists and scheduler views, filtering telemetry packets and event logs, and rewriting sensor or health values before they are recorded or downlinked. Rootkits may also hook command handlers and gateways so certain opcodes, timetags, or sources are silently accepted or ignored while external observers see normal acknowledgments. Because many missions rely on deterministic procedures and limited observability, even small alterations to reporting can make malicious actions appear as plausible mode transitions or benign anomalies. Persistence often pairs with the concealment layer, with the rootkit reinjecting companions after resets or rebuilds by monitoring for specific files, tables, or image loads and modifying them on the fly. | |
| EX-0010.04 | Bootkit | A bootkit positions itself in the pre-OS boot chain so that it executes before normal integrity checks and can shape what the system subsequently trusts. After seizing early control, the bootkit can redirect image selection, patch kernels or flight binaries in memory, adjust device trees and driver tables, or install hooks that persist across warm resets. Some variants maintain shadow copies of legitimate images and present them to basic verification routines while steering actual execution to a modified payload; others manipulate fallback logic so recovery modes load attacker-controlled code. Because the boot path initializes memory maps, buses, and authentication material, a bootkit can also influence key/counter setup and gateway configurations, creating conditions favorable to later tactics. The central characteristic is precedence: by running first, the implant defines the reality higher layers observe, ensuring that every subsequent component launches under conditions curated by the attacker. | |
| EX-0010.05 | On-Board Process Injection | Adversaries may inject malicious code into trusted onboard software processes in order to execute arbitrary functionality within the context of legitimate spacecraft software. Targeted processes may include flight software tasks, operating system services, telemetry handlers, middleware, communication daemons, scheduler services, device drivers, or other mission-critical runtime components. Process injection enables malicious code to inherit the permissions, memory access, execution context, and trust relationships associated with the compromised process. This may allow adversaries to manipulate telemetry, alter spacecraft operational behavior, suppress reporting, interfere with fault management, inject unauthorized commands, or evade detection without interrupting nominal spacecraft operations. Unlike standalone malicious binaries or scripts, injected code executes within legitimate onboard software contexts, causing malicious activity to appear operationally valid and making detection and forensic analysis significantly more difficult. | |
| EX-0012 | Modify On-Board Values | The attacker alters live or persistent data that the spacecraft uses to make decisions and route work. Targets include device and control registers, parameter and limit tables, internal routing/subscriber maps, schedules and timelines, priority/QoS settings, watchdog and timer values, autonomy/FDIR rule tables, ephemeris and attitude references, and power/thermal setpoints. Many missions expose legitimate mechanisms for updating these artifacts, direct memory read/write commands, table load services, file transfers, or maintenance procedures, which can be invoked to steer behavior without changing code. Edits may be transient (until reset) or latched/persistent across boots; they can be narrowly scoped (a single bit flip on an enable mask) or systemic (rewriting a routing table so commands are misdelivered). The effect space spans subtle biasing of control loops, selective blackholing of commands or telemetry, rescheduling of operations, and wholesale changes to mode logic, all accomplished by modifying the values the software already trusts and consumes. | |
| EX-0012.13 | Poison AI/ML Training Data | When missions employ AI/ML, for onboard detection/classification, compression, anomaly screening, guidance aids, or ground-side planning, training data becomes a control surface. Data poisoning inserts crafted examples or labels into the training corpus or fine-tuning set so the resulting model behaves incorrectly while appearing valid. Variants include clean-label backdoors (benign-looking samples with a hidden trigger that later induces a targeted response), label flipping and biased sampling (to skew decision boundaries), and corruption of calibration/ground-truth products that the pipeline trusts. For space systems, poisoning may occur in science archives, test vectors, simulated scenes, or housekeeping datasets used to train autonomy/anomaly models; models trained on poisoned corpora are then packaged and uplinked as routine updates. Once fielded, a simple trigger pattern in imagery, telemetry, or RF features can cause misclassification, suppression, or false positives at the time and place the adversary chooses, turning model behavior into an execution mechanism keyed by data rather than code. | |
| PER-0001 | Memory Compromise | The adversary arranges for malicious content to survive resets and mode changes by targeting memories and execution paths that initialize the system. Candidates include boot ROM handoff vectors, first/second-stage loaders, non-volatile images (flash/EEPROM), “golden” fallback partitions, configuration words/fuses, and RAM regions reconstructed at start-up from stored files or tables. Persistence may also ride auto-run mechanisms, init scripts, procedure engines, stored command sequences, or event hooks that execute on boot, safe-mode entry/exit, time triggers, or receipt of specific telemetry/commands. Variants keep the core payload only in RAM but ensure it is reloaded after every restart by patching copy-on-boot routines, altering file catalogs, or modifying table loaders so the same bytes are restored. The common thread is control of where the spacecraft looks for what to run next, so unauthorized logic is reinstated whenever the system resets or transitions modes. | |
| PER-0002 | Backdoor | A backdoor is a covert access path that bypasses normal authentication, authorization, or operational checks so the attacker can reenter the system on demand. Backdoors may be preexisting (undocumented service modes, maintenance accounts, debug features) or introduced by the adversary during development, integration, or on-orbit updates. Triggers range from “magic” opcodes and timetags to specific geometry/time conditions, counters, or data patterns embedded in routine traffic. The access they provide varies from expanded command sets and relaxed rate/size limits to alternate communications profiles and hidden file/parameter interfaces. Well-crafted backdoors blend with nominal behavior, appearing as ordinary operations while quietly accepting instructions that other paths would reject, thereby sustaining the attacker’s foothold across passes, resets, and operator handovers. | |
| PER-0002.01 | Hardware Backdoor | Hardware backdoors leverage properties of the physical design to provide durable, low-visibility reentry. Examples include enabled test/scan chains, manufacturing or boot-strap modes invoked by pins or registers, persistent debug interfaces (JTAG/SWD/UART), undocumented device commands, and logic inserted in FPGA/ASIC designs that activates under specific stimuli. Because these mechanisms sit below or beside flight software, they can grant direct access to buses, memories, or peripheral control even when higher layers appear healthy. Triggers may be electrical (pin states, voltage/clock sequences), protocol-level (special patterns on an instrument link), or environmental/temporal (particular temperature ranges, timing offsets). Once on orbit, such pathways are difficult to remove or reconfigure, allowing the attacker to persist by reusing the same physical entry points whenever conditions are met. | |
| PER-0002.02 | Software Backdoor | Software backdoors are code paths intentionally crafted or later inserted to provide privileged functionality on cue. In flight contexts, they appear as hidden command handlers, alternate authentication checks, special user/role constructs, or procedure/script hooks that accept nonpublic inputs. They can be embedded in flight applications, separation kernels or drivers, gateway processors that translate bus/payload traffic, or update/loader utilities that handle tables and images. SDR configurations offer another avenue: non-public waveforms, subcarriers, or framing profiles that, when selected, expose a private command channel. Activation is often conditional, specific timetags, geometry, message sequences, or file names, to keep the feature dormant during routine testing and operations. Once present, the backdoor provides a repeatable way to execute commands or modify state without traversing the standard control surfaces, sustaining the adversary’s access over time. | |
| DE-0003 | On-Board Values Obfuscation | The adversary manipulates housekeeping and control values that operators and autonomy rely on to judge activity, health, and command hygiene. Targets include command/telemetry counters, event/severity flags, downlink/reporting modes, cryptographic-mode indicators, and the system clock. By rewriting, freezing, or biasing these fields, and by selecting reduced or summary telemetry modes, unauthorized actions can proceed while the downlinked picture appears routine or incomplete. The result is delayed recognition, misattribution to environmental effects, or logs that cannot be reconciled post-facto. | |
| DE-0003.12 | Poison AI/ML Training for Evasion | When security monitoring relies on AI/ML (e.g., anomaly detection on telemetry, RF fingerprints, or command semantics), the training data itself is a target. Data-poisoning introduces crafted examples or labels so the learned model embeds false associations, treating attacker behaviors as normal, or flagging benign patterns instead. Variants include clean-label backdoors keyed to subtle triggers, label flipping that shifts decision boundaries, and biased sampling that suppresses rare-but-critical signatures. Models trained on tainted corpora are later deployed as routine updates; once in service, the adversary presents inputs containing the trigger or profile they primed, and the detector omits or downranks the very behaviors that would reveal the intrusion. | |
| DE-0007 | Evasion via Rootkit | A rootkit hides malicious activity by interposing on reporting paths after the system has booted. In flight contexts this includes patching flight software APIs, kernel syscalls, message queues, and telemetry publishers so task lists, counters, health channels, and event severities are falsified before downlink. Command handlers can be hooked to suppress evidence of certain opcodes or sources; recorder catalogs and file listings can be rewritten on the fly; and housekeeping can be biased to show nominal temperatures, currents, or voltages while actions proceed. The defining feature is runtime concealment: the observability surfaces operators rely on are altered to present a curated, benign narrative. | |
| DE-0008 | Evasion via Bootkit | A bootkit hides activity by running first and shaping what higher layers will later observe. Positioned in boot ROM handoff or early loaders, it can select or patch images in memory, alter device trees and driver tables, seed forged counters and timestamps, and preconfigure telemetry/crypto modes so subsequent components launch into a reality curated by the attacker. Because integrity and logging mechanisms are initialized afterward, the resulting view of processes, files, and histories reflects the bootkit’s choices, allowing long-term evasion that persists across resets and mode transitions. | |
| DE-0012 | Component Collusion | This technique involves two or more compromised components operating in coordination to conceal malicious activity. Threat actors compromise multiple software modules during the supply chain process and design them to behave cooperatively. Each component independently performs only a limited, seemingly benign function, such that when analyzed in isolation, no single module appears malicious. An example of implementation involves one component acting as a trigger agent, waiting for specific mission or system conditions (e.g., GPS fix, telemetry state) and writing a signal to a shared resource (e.g., file, bus). A separate action agent monitors this resource and only executes the malicious behavior (such as data exfiltration or command injection) upon receiving the trigger. This division of responsibilities significantly undermines traditional detection techniques, such as log analysis, static code review, or heuristic-based behavior monitoring. | |
| LM-0001 | Hosted Payload | The adversary pivots through the host–payload boundary to reach additional subsystems. Hosted payloads exchange power, time, housekeeping, and data with the bus via defined gateways (e.g., SpaceWire, 1553, Ethernet) and often support file services, table loads, and command dictionaries distinct from the host’s. A foothold on the payload can be used to inject traffic through the gateway processor, request privileged services (time/ephemeris distribution, firmware loads), or ride shared backplanes where payload traffic is bridged into C&DH networks. In some designs, payload processes execute on host compute or expose maintenance modes that temporarily widen access, creating paths from the payload into attitude, power, storage, or recorder resources. The movement is transitive: compromise a co-resident unit, then traverse the trusted interface that already exists for mission operations. | |
| EXF-0006 | Modify Communications Configuration | The adversary alters radio/optical link configuration so the spacecraft emits mission data over paths the program does not monitor or control. Levers include retuning carriers, adding sidebands or subcarriers, changing modulation/coding profiles, remapping virtual channels/APIDs, editing beacon content, or redirecting routing tables in regenerative payloads. Data can be embedded steganographically (idle fields, padding, frame counters, pilot tones) or carried on a covert auxiliary downlink/crosslink pointed at attacker-owned apertures. Because these emissions conform to plausible waveforms and scheduler behavior, they appear as ordinary link activity while quietly conveying payload products, housekeeping, or file fragments to non-mission receivers. | |
| EXF-0006.01 | Software Defined Radio | Programmable SDRs let an attacker introduce new waveforms or piggyback payloads into existing ones. By modifying DSP chains (filters, mixers, FEC, framing), the actor can: add a low-rate subcarrier under the main modulation, alter preamble/pilot sequences to encode bits, vary puncturing/interleaver patterns as a covert channel, or schedule brief “maintenance” bursts that actually carry exfiltrated data. Changes may be packaged as legitimate updates or configuration profiles so the SDR transmits toward attacker-visible geometry using standard equipment, while mission tooling interprets the emission as routine. | |
| EXF-0006.02 | Transponder | On bent-pipe or regenerative transponders, configuration controls what is translated, amplified, and routed. An adversary can remap input–output paths, shift translation frequencies, adjust polarization or gain to favor non-mission receivers, or enable auxiliary ports so selected virtual channels or recorder playbacks are forwarded outside the planned ground segment. In regenerative systems, edited routing tables or QoS rules can mirror traffic to an attacker-controlled endpoint. The result is a sanctioned-looking carrier that quietly delivers mission data to unauthorized listeners. | |
| EXF-0008 | Compromised Developer Site | By breaching development or integration environments (at the mission owner, contractor, or partner), the adversary gains access to source code, test vectors, telemetry captures, build artifacts, documentation, and configuration data, material that is often more complete than flight archives. Beyond theft of intellectual property, the attacker can embed telemetry taps, extended logging, or data “export” features into test harnesses, simulators, or flight builds so that, once fielded, the system produces extra observables or forwards content to non-mission endpoints. This activity typically occurs pre-launch during software production and ATLO, positioning exfiltration mechanisms to activate later in flight. | |