Apply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: [Assignment: organization-defined systems security and privacy engineering principles].
| ID | Name | Description | D3FEND | |
| CM0001 | Protect Sensitive Information | Space mission sensitive information spans a broad attack surface and must be inventoried, classified, and protected at a level commensurate with its sensitivity across every location where it resides, including ground systems, contractor networks, and remote access environments. Sensitive material typically includes functional and performance specifications, interface control documents (ICDs), command and telemetry (C&T) databases, uplink protection schemes including disable and bypass features, fault management logic, scripts, simulation and rehearsal results, failure and anomaly resolution records, and architecture and software documentation. Each information type must be assigned a protection level, such as unclassified, controlled, proprietary, or classified, and access must be restricted to personnel with defined roles and a verified need to know. Sensitive data shall be protected at rest and in transit using encryption or other mission-approved safeguards commensurate with its classification, sensitivity, threat exposure, and operational constraints. DLP capabilities shall be applied to systems and data flows where they are technically feasible and effective, with alternative access controls, monitoring, or information-flow protections used where conventional DLP technology is not suitable. Ongoing configuration management must track, control, and document all changes to command procedures and critical database content to prevent unauthorized modification and mission degradation. | D3-AI D3-AVE D3-NVA D3-CH D3-CBAN D3-CTS D3-PA D3-FAPA D3-SAOR | |
| CM0009 | Threat Intelligence Program | A threat intelligence program enables an organization to systematically collect, analyze, and apply information about adversary capabilities, infrastructure, and intent to inform defensive priorities and drive risk-informed security decisions across the mission lifecycle. For space missions specifically, this may include leveraging available all-source intelligence services or commercial satellite imagery to identify and monitor adversary infrastructure development and acquisition activities that may signal emerging threats to mission assets. Threat intelligence outputs should be operationalized into concrete adjustments to defensive architecture, monitoring priorities, and incident response posture rather than treated as informational products alone. Direct countermeasures against adversary infrastructure identified through this program will fall outside the scope of the mission in the majority of cases; the primary value of the program is in generating actionable awareness that sharpens the organization's own defensive posture. | D3-PH D3-AH D3-NM D3-NVA D3-SYSM D3-SYSVA | |
| CM0020 | Threat modeling | Threat modeling is a structured analytical process that identifies, enumerates, and prioritizes potential threats to a system by systematically examining assets, trust boundaries, data flows, and adversary capabilities relative to the system's architecture. Applied in combination with attack surface analysis and vulnerability analysis, threat modeling produces an integrated picture of where the system is most exposed and what the consequences of successful exploitation would be. Analysis should draw on findings from similar systems, components, or services where applicable, leveraging documented threat experience from comparable missions or architectures to avoid re-learning known lessons. The outputs of threat modeling must directly inform design decisions throughout the development process, with attack surface reduction treated as a design objective rather than a post-development hardening activity: interfaces, services, protocols, and code paths that are not necessary to mission function should be eliminated or constrained before they become embedded in the architecture. Threat model artifacts should be treated as living documents, updated as the system design evolves and as new threat intelligence becomes available. | D3-AI D3-AVE D3-SWI D3-HCI D3-NM D3-LLM D3-ALLM D3-PLLM D3-PLM D3-APLM D3-PPLM D3-SYSM D3-DEM D3-SVCDM D3-SYSDM | |
| CM0022 | Criticality Analysis | Criticality analysis is a structured engineering process that identifies the mission functions, system components, and data flows whose compromise, degradation, or loss would most severely impact mission success, crew safety, or operational continuity. The outputs of this analysis directly drive security investment prioritization: components and functions assessed as most critical receive the most rigorous design-phase protections, supply chain scrutiny, and operational security controls, while lower-criticality elements are protected proportionately. Criticality analysis findings should inform the application of complementary security design principles, including network and functional segmentation and least-privilege access control, to isolate critical components from less-trusted system elements and reduce the consequence of compromise elsewhere in the system. Supply chain protection resources and oversight rigor should be explicitly allocated in proportion to component criticality, ensuring that the most mission-essential hardware and software receive the most intensive sourcing controls, provenance verification, and supplier oversight. Criticality analysis must be initiated early in the system design process and updated as the architecture evolves, threat intelligence changes, or operational experience reveals previously unrecognized dependencies. | D3-AVE D3-OSM D3-IDA D3-SJA D3-AI D3-DI D3-SWI D3-NNI D3-HCI D3-NM D3-PLM D3-AM D3-SYSM D3-SVCDM D3-SYSDM D3-SYSVA D3-OAM D3-ORA | |
| CM0024 | Anti-counterfeit Hardware | 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. | D3-AI D3-SWI D3-HCI D3-FEMC D3-DLIC D3-FV | |
| CM0025 | Supplier Review | 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. | D3-OAM D3-ODM | |
| CM0026 | Original Component Manufacturer | 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. | D3-OAM D3-ODM D3-AM D3-FV D3-SFV | |
| CM0027 | ASIC/FPGA Manufacturing | 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. | D3-OAM D3-ODM D3-AM D3-FV D3-SFV | |
| CM0028 | Tamper Protection | Tamper protection encompasses physical and logical controls that detect, deter, and respond to unauthorized modification of mission hardware and software throughout the acquisition, transit, storage, integration, and operational phases of the mission lifecycle. Physical tamper protection requires inspection of hardware at defined custody transfer points to detect evidence of unauthorized access or modification, and requires the use of tamper-evident packaging and sealing mechanisms during shipping and receiving to ensure that any interference with equipment in transit is detectable upon arrival. Logical tamper protection addresses the integrity of software and firmware through layered techniques including code obfuscation, integrity checks that verify software has not been altered from its approved state, and runtime integrity monitoring mechanisms such as self-checking code. Watchdog processes may supplement these controls by detecting abnormal execution or failure to complete expected processing, but do not by themselves verify software integrity. Physical and logical tamper protections are complementary and should be applied together where warranted by system criticality, threat exposure, and lifecycle conditions. Physical access to hardware can enable logical tampering, while failure to verify software integrity can reduce the assurance provided by physical controls. | D3-PH D3-AH D3-RFS D3-FV | |
| CM0052 | Insider Threat Protection | Insider threats represent a distinct and particularly difficult risk category for space mission security, as individuals with authorized access to mission systems, facilities, and commanding infrastructure can cause significant damage without needing to overcome the external access controls that defend against outside adversaries. An insider threat program establishes the organizational, procedural, and technical controls necessary to deter, detect, and respond to malicious or negligent actions by personnel with legitimate access, including attempts by insiders to masquerade as other authorized individuals to access commanding functions or sensitive mission infrastructure under a false identity. The program must address both the technical controls that limit what any individual can do with their authorized access and the procedural and behavioral controls that create accountability, reduce opportunity, and enable early detection of concerning patterns. Effective insider threat protection requires integration across personnel security, access management, monitoring, and incident response functions, treating the insider threat as an ongoing operational risk to be managed continuously rather than a problem solved by initial personnel vetting alone. | D3-OAM D3-AM D3-OM D3-CH D3-SPP D3-MFA D3-UAP D3-UBA | |
| CM0030 | Crypto Key Management | Effective cryptographic key management is a foundational requirement for all mission encryption and authentication functions; the security of cryptographic implementations is only as strong as the protection afforded to the keys those implementations rely upon. Key management must conform to recognized cryptographic guidance and address the full lifecycle applicable to each key type, including generation or establishment, distribution, storage, activation, use, replacement, deactivation or revocation, recovery where authorized, compromise response, and destruction. Only approved cryptographic algorithms, key generation methods, key distribution techniques, and authentication mechanisms may be used; the use of unapproved, deprecated, or custom cryptographic primitives is prohibited regardless of perceived functional adequacy. Encryption key handling must be performed outside of onboard software and protected through dedicated cryptographic mechanisms, preventing keys from being exposed through software vulnerabilities, memory inspection, or software-level debugging interfaces. Secret and private key material must not be retrievable in plaintext through telecommands, telemetry, diagnostic outputs, debugging interfaces, or other externally accessible mechanisms, regardless of the privilege level of the requesting entity. | D3-CH D3-CP | |
| CM0031 | Authentication | All command-bearing sessions, frames, or messages involving spacecraft command links, crosslinks, or relay services shall provide cryptographic authentication of the command origin and integrity verification before commands are accepted. Mutual or bidirectional authentication shall be required where both endpoints must authenticate one another and the link and protocol architecture support that exchange. Acquisition requirements should mandate cryptographically based, bidirectional authentication for all command sessions across external links, including ground-to-spacecraft uplinks, spacecraft-to-spacecraft crosslinks, and any relay or intermediary ground station connections, with authentication required aBidirectional authentication enables both communicating entities to verify each other’s identity and helps prevent impersonation. Authentication establishes identity but does not by itself authorize a command, protect mission-data confidentiality, or prevent session hijacking. Command acceptance must also enforce authorization, and authenticated sessions or security associations must maintain integrity and replay resistance so that subsequent traffic remains bound to the authenticated entities. Beyond external links, authentication is strongly recommended for spacecraft internal bus communications and onboard inter-component connections, as an adversary with access to internal interfaces, whether through a compromised component or a physical access event, should face the same authentication barrier as an external adversary attempting to inject commands from outside the spacecraft. | D3-MH D3-MAN D3-CH D3-BAN D3-MFA D3-TAAN D3-CBAN | |
| CM0050 | On-board Message Encryption | Authentication controls on the spacecraft internal bus verify the identity of communicating components but do not protect the confidentiality of the data in transit; an adversary with access to the bus, whether through a compromised component, a hardware implant, or a physical access event, can observe all unencrypted inter-component communications regardless of whether authentication is enforced. Encrypting data traversing the spacecraft internal bus protects the confidentiality of selected message content from entities that can observe the bus but do not possess authorization and the applicable cryptographic keys. The protection does not prevent disclosure to a compromised component that legitimately possesses the decryption key, and it may not conceal unencrypted protocol headers, addressing information, message timing, or traffic volume. Bus encryption should be considered for bus segments or message types carrying information whose unauthorized disclosure would create unacceptable mission, security, privacy, or operational risk. Criticality alone does not establish a confidentiality requirement. Where confidentiality is required, encryption must be combined with message integrity, source authentication, and replay protection through an approved authenticated-encryption mechanism or an appropriately composed set of cryptographic protections. | D3-MH D3-MENCR D3-ET | |
| 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 | |
| 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 | |
| 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 | |
| CM0039 | Least Privilege | The principle of least privilege requires that every process, user account, service, and system component be granted only the permissions and access rights necessary to perform its defined function, with no additional privileges retained beyond what the assigned task requires. Applied to spacecraft and ground systems, this means that processes executing on flight computers, operating system services, ground system applications, and inter-system communication handlers are each confined to the minimum privilege level needed for their specific function, preventing a compromised or malfunctioning component from leveraging excess permissions to affect other system resources or functions. Separate execution domains should be used where supported to reinforce least privilege and contain process failures or compromise. Process isolation does not replace explicit access controls, because authorized communication and shared resources may still cross execution-domain boundaries. Least privilege is a foundational design principle that reduces the consequence of any individual component compromise by limiting what an adversary can accomplish within that component's execution context. | D3-MAC D3-EI D3-HBPI D3-KBPI D3-PSEP D3-MBT D3-PCSV D3-LFP D3-UBA | |
| CM0046 | Long Duration Testing | Long duration testing subjects spacecraft software, firmware, hardware, and relevant integrated ground interfaces, or representative simulation and emulation environments, to extended test execution of 30 days or more to expose security and reliability defects that may manifest only after prolonged operation or specific time-dependent conditions. Race conditions, memory or resource leaks, time-dependent state corruption, resource exhaustion, counter rollover, and time-triggered malicious behavior may not manifest during short-duration testing because their activation depends on accumulated runtime, rare timing interactions, or gradual changes in system state. Long duration testing increases the opportunity to expose these conditions before deployment and complements static analysis, formal analysis, stress testing, fault injection, and targeted rollover testing. Testing should use the highest-fidelity environment appropriate to the test objectives. Flight-representative hardware should be used where hardware timing, device behavior, or integration effects are material; validated simulation or emulation may be used for conditions that it represents with sufficient fidelity. Differences between the test environment and operational system must be documented and considered when interpreting results. | D3-SJA D3-PM D3-OSM D3-SDM D3-UBA D3-SYSVA | |
| CM0047 | Operating System Security | The spacecraft operating system (OS) must be subjected to software assurance scrutiny commensurate with its mission criticality and security role. Prior assurance and flight-history evidence may be reused only after its applicability to the selected OS version, configuration, target hardware, operational use, and current mission security requirements has been evaluated. The OS must be analyzed for its attack surface, and all features, services, libraries, and interfaces not required for the mission's defined operational functions must be stripped, disabled, or removed before the OS is integrated into the flight software stack. This hardening requirement is particularly significant for some real-time operating systems (RTOS), which commonly include networking stacks, file systems, shell interfaces, diagnostic services, and other general-purpose capabilities that are unnecessary for spacecraft operations but expand the exploitable attack surface available to an adversary. Only an organization-approved OS product, version, build, and configuration baseline may be used in the delivered spacecraft system. The approved baseline must be enforced through reproducible build controls, configuration management, component inventories, and automated verification where supported. | D3-AVE D3-OSM D3-EHB D3-SDM D3-SFA D3-SBV D3-PA D3-SCA D3-FCA | |
| CM0055 | Secure Command Mode(s) | Secure command modes provide additional layers of restriction on spacecraft command acceptance beyond standard authentication and encryption, constraining when, where, and under what operational conditions the spacecraft will process commands. These supplemental controls reduce the window of opportunity for unauthorized commanding by limiting command receptivity to defined parameters that an adversary would need to satisfy simultaneously with authentication requirements, substantially increasing the difficulty of a successful command injection attack. Specific implementations include geographic restriction, in which the spacecraft accepts commands only when in contact with designated ground station locations; operational mode restrictions, in which special flight software (FSW) modes must be active before certain command categories are accepted; and temporal controls, in which the spacecraft enforces time-bounded windows during which commands are valid. These mechanisms complement command authentication, integrity protection, anti-replay controls, and authorization and do not replace them. Encryption should also be applied where command confidentiality is required. Secure command modes may combine geographic, temporal, operational-state, source, or other mission-defined conditions according to the active command policy. Secure command modes helps create a multi-dimensional command acceptance policy that an adversary must defeat in its entirety to achieve unauthorized command execution. | D3-AH D3-ACH D3-MFA D3-OTP | |
| CM0035 | Protect Authenticators | Authenticators and associated authenticator material, including passwords, secret and private keys, tokens, biometric templates, shared secrets, certificates, and trust-store entries, must be protected against unauthorized modification and, where the material is confidential, unauthorized disclosure throughout their lifecycle. Disclosure of secret authenticator material may enable adversaries to impersonate legitimate users or systems. Unauthorized modification of authenticators, certificates, or trust information can deny access to legitimate entities, substitute adversary-controlled credentials, or corrupt the trust basis of mission authentication mechanisms. Protection must apply to authenticators at rest, in transit, and in use, and must extend to all forms and storage locations, including credential databases, configuration files, embedded device credentials, hardware security tokens, and cryptographic key stores. Authenticator protection is a prerequisite for the effectiveness of any authentication-based access control; an authentication system whose authenticators are unprotected provides no meaningful security regardless of the strength of the underlying authentication protocol. | D3-CE D3-ANCI D3-CA D3-ACA D3-PCA D3-CRO D3-CTS D3-SPP | |
| CM0053 | Physical Security Controls | Physical security controls form the outermost defensive layer protecting systems that can command the spacecraft, limiting access to commanding infrastructure to personnel who are both identity-verified and specifically authorized to be in those environments. Unauthorized physical access may enable theft, tampering, connection to exposed interfaces, use of unattended sessions, or attempts to extract or alter protected information. Physical security must therefore complement authentication, encryption, session management, tamper protection, and other technical controls rather than assume those controls will remain sufficient without protection of the underlying equipment. Physical security measures for commanding facilities and infrastructure must use layered controls selected according to the facility threat environment, system criticality, site characteristics, and consequence of unauthorized access. Controls may include perimeter barriers, controlled entry points, interior protected areas, identity and authorization verification, locks, intrusion detection, surveillance, and security personnel. Access to the facility must not, by itself, authorize physical access to commanding systems. Physical security controls must be commensurate with the sensitivity and criticality of the commanding functions they protect, with the most sensitive commanding capabilities requiring the most stringent physical access restrictions. | D3-RFS D3-AM | |
| CM0056 | Data Backup | A mission's ability to recover from a cyber incident, hardware failure, or adversary action depends directly on the availability of verified, uncorrupted backups of critical data that are stored independently from the primary systems those backups are intended to restore. Data backup procedures must be defined within a broader disaster recovery plan that specifies what data is backed up, at what frequency, through what process, and under what conditions restoration will be initiated. At least one recoverable backup copy must be stored outside the primary system’s administrative and failure domains and protected so that compromise of ordinary production systems, credentials, or management services does not provide the ability to modify or destroy that copy. Separation may use offline media, physically separate infrastructure, isolated storage systems, separate cloud accounts or security domains, immutable retention controls, or an approved combination of these mechanisms. Backup storage must be protected against the methods adversaries commonly use to target recovery capability, including ransomware that encrypts or deletes backup repositories, credential attacks against backup management systems, and physical access to backup media. Backup integrity must be verifiable, as a backup that has been silently corrupted or tampered with provides no recovery capability when needed. | D3-AI D3-DI D3-SYSM D3-DEM | |
| CM0042 | Robust Fault Management | The fault management system is a high-privilege, autonomous spacecraft function that adversaries may attempt to exploit as an attack vector, triggering protective responses that place the spacecraft in a degraded or more vulnerable operational state. Attack scenarios include manipulating sensor, state, or telemetry information to induce onboard or ground-directed safing actions; creating false fault conditions through sensor spoofing or proximity operations; exploiting safe-mode configurations that reduce security protections; and inducing autonomous maneuver responses through crafted fault indications. Robust fault management requires that safing procedures and autonomous responses be designed with explicit security analysis confirming that each protective action does not introduce a more exploitable system state than the fault condition it responds to. The integrity and authenticity of sensor data, state information, commands, and telemetry used by onboard or ground-based fault management functions must be protected to prevent falsified inputs from triggering unintended responses. Every fault response, including mode transitions, actuator commands, and communication reconfigurations, must be evaluated against the question of whether an adversary could deliberately induce that response and whether the resulting system state provides the adversary with meaningful advantage. | D3-AH D3-EHPV D3-PSEP D3-PH D3-SCP | |
| CM0044 | Cyber-safe Mode | 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. | D3-PH D3-EI D3-NI D3-BA | |
| CM0051 | Fault Injection Redundancy | Fault injection attacks deliberately induce errors in executing hardware or software, typically by manipulating voltage, clock signals, electromagnetic fields, or radiation, to corrupt computation and extract sensitive information or bypass security controls through observable fault effects. For mission-critical functions that must be protected against fault-based side-channel attacks, particularly cryptographic operations, redundancy-based countermeasures provide a robust detection and mitigation mechanism. The approach executes a protected function through two or more spatially or temporally redundant computations and compares their results. A mismatch indicates a computation fault or implementation discrepancy but does not by itself establish that fault injection occurred. With two results, the system can generally detect disagreement but cannot determine which result is valid. A voter or selection mechanism may provide fault masking only when the number of replicas, independence assumptions, and defined fault model support reliable adjudication; otherwise, the result must be rejected and a mission-approved protective response initiated. Although spacecraft sensor nodes and embedded processors operate under constrained resources, the functions most critical to protect through redundancy are typically cryptographic routines, whose execution footprint is bounded and whose compromise would have disproportionate mission security consequences. | D3-AH D3-SYSVA D3-ORA | |
| CM0037 | Disable Physical Ports | Physical data connection, debug, programming, and maintenance interfaces (e.g., joint test action group (JTAG)) that are not required for spacecraft operations must be disabled, removed, or otherwise made inaccessible before spacecraft operations begin. Interfaces required for operational functions must be explicitly identified and protected against unauthorized physical access and use. These interfaces, essential during development for programming, debugging, and testing, represent persistent attack surfaces in the operational environment: an adversary with physical access to the spacecraft before launch, during ground handling, or at a shared launch facility could exploit active debug interfaces to read memory, modify firmware, bypass security controls, or implant persistent malicious code without leaving detectable traces in software-visible logs. Disabling or removing unused physical interfaces closes a direct hardware-access pathway and reduces reliance on procedural controls or physical security alone. The capability to disable these interfaces must be designed into the system from the outset, as physical removal or reliable hardware-enforced disablement cannot be easily retrofitted into a completed board design. | D3-EI D3-IOPR | |
| CM0038 | Segmentation | Segmentation establishes physical or logical isolation boundaries between spacecraft system components and functional domains to limit the propagation of compromise, contain the consequences of a security failure, and enforce controlled information flow across the mission architecture. Mission-critical functions must be isolated from non-mission-critical functions through enforced partition boundaries that control access to and protect the integrity of the hardware, software, and firmware implementing those functions. Information flow between partitioned components or applications must be explicitly authorized by security policy; any flow not affirmatively permitted is denied by default. Boundary protections must be implemented to separate spacecraft bus, communications, and payload components, preventing a compromise in one domain from directly affecting the others. Information crossing the spacecraft boundary shall receive confidentiality protection where required by its classification, sensitivity, or mission risk. Command-bearing and other security-critical exchanges shall receive the mission-required authentication, integrity, authorization, and anti-replay protections regardless of whether confidentiality is required. These controls collectively implement a defense-in-depth architecture in which an adversary who gains a foothold in one partition faces enforced barriers before reaching mission-critical assets. | D3-NI D3-BDI D3-NTF D3-ITF D3-OTF D3-EI D3-HBPI D3-KBPI D3-MAC D3-RRID D3-EAL D3-EDL D3-IOPR D3-SCF | |
| CM0043 | Backdoor Commands | All commands capable of being executed on the spacecraft must be known, documented, and accounted for by the mission and spacecraft owner; the existence of undisclosed or undocumented commands, whether introduced by developers, component suppliers, or subsystem vendors, represents an unacceptable and unmanageable risk to mission integrity. Commands capable of adversely affecting mission success if misused must be identified through deliberate analysis and protected by mission-defined authorization and execution controls commensurate with their consequences. Commands that bypass normal operational safeguards require additional justification and restrictions appropriate to their emergency or contingency purpose. Backdoor, residual, hardware-level, test, diagnostic, or override commands that bypass normal operational pathways or safeguards should be retained only where mission-approved emergency or contingency access requires them. Their inclusion must be explicitly justified, and their commanding authority must be appropriately restricted. Hazardous commands required for normal mission operations are not prohibited by this countermeasure but must be governed by approved authorization, prerequisite, sequencing, and safety controls. Any command capability introduced by a subsystem supplier or component vendor that was not explicitly requested or authorized by the mission owner must be identified, evaluated, and either removed or brought under formal mission command governance before launch. | D3-OAM D3-AM D3-PH D3-CCSA D3-LAM D3-CE | |
| CM0045 | Error Detection and Correcting Memory | Error detection and correcting (EDAC) memory provides a foundational defense against radiation-induced corruption in spacecraft onboard memory. The selected EDAC scheme must detect and correct error patterns within its designed capability and identify errors that exceed that capability. Common single-error-correction, double-error-detection schemes correct single-bit errors and detect double-bit errors, but other schemes may provide different correction and detection capabilities. The EDAC scheme must be integrated with both the fault management system and the spacecraft's cyber-protection mechanisms, enabling coordinated responses to uncorrectable multi-bit errors that go beyond time-delayed ground monitoring of EDAC telemetry. This integration is security-relevant because multi-bit memory errors, whether radiation-induced or adversarially induced through deliberate fault injection, can corrupt flight software, configuration data, or security-critical parameters in ways that create exploitable system states if not detected and responded to promptly and autonomously. The spacecraft must use the selected EDAC architecture to detect and correct errors during memory access and, where applicable, perform periodic memory scrubbing to detect and remove latent correctable errors. The implementation must identify the affected memory address or region for detected uncorrectable errors involving two or more bits, to the extent supported by the memory architecture, with higher-order detection or correction provided where required by mission risk. Detection of an uncorrectable error must trigger a timely onboard fault-management or cyber-protection response that prevents continued use or propagation of suspect data and autonomously minimizes adverse effects without waiting for ground detection. Subsequent diagnosis and recovery may be autonomous, ground-directed, or combined according to mission requirements. | D3-HCI D3-MBT | |
| CM0057 | Tamper Resistant Body | A tamper-resistant physical enclosure increases the effort, time, and equipment required to physically probe, observe, remove, or modify protected spacecraft sensor nodes and embedded components. The enclosure must be designed for the specific physical-access and side-channel threats being addressed and should not be assumed to prevent every invasive or non-invasive attack. A passive tamper-resistant body can provide physical and side-channel protection without continuous processing or electrical power, which may make it suitable for resource-constrained sensor nodes. The design trade must also account for mass, volume, thermal performance, manufacturability, inspection, repairability, qualification, and lifecycle cost. Enclosures incorporating active sensing or response mechanisms require power and must be evaluated separately from fully passive designs. The physical security design must distinguish among tamper resistance, which impedes access; tamper evidence, which leaves observable indications of attempted access; tamper detection, which senses an attempt while it occurs; and tamper response, which protects designated sensitive assets after detection. The required properties and response behavior must be selected according to the protected component, threat model, and mission consequence of both successful tampering and false activation. | D3-PH D3-RFS | |
| ID | Description | |
| SV-AC-3 |
Compromised master keys or any encryption key |
|
| SV-CF-2 |
Eavesdropping (RF and proximity) |
|
| SV-IT-2 |
Unauthorized modification or corruption of data |
|
| SV-MA-2 |
Heaters and flow valves of the propulsion subsystem are controlled by electric signals so cyberattacks against these signals could cause propellant lines to freeze, lock valves, waste propellant or even put in de-orbit or unstable spinning |
|
| SV-AV-4 |
Attacking the scheduling table to affect tasking |
|
| SV-IT-5 |
Onboard control procedures (i.e., ATS/RTS) that execute a scripts/sets of commands |
|
| 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-5 |
Proximity operations (i.e., grappling satellite) |
|
| 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-AC-8 |
Malicious Use of hardware commands - backdoors / critical commands |
|
| SV-AV-2 |
Satellites base many operations on timing especially since many operations are automated. Cyberattack to disrupt timing/timers could affect the vehicle (Time Jamming / Time Spoofing) |
|
| SV-AV-3 |
Affect the watchdog timer onboard the satellite which could force satellite into some sort of recovery mode/protocol |
|
| SV-IT-3 |
Compromise boot memory |
|
| SV-IT-4 |
Cause bit flip on memory via single event upsets |
|
| SV-MA-8 |
Payload (or other component) is told to constantly sense or emit or run whatever mission it had to the point that it drained the battery constantly / operated in a loop at maximum power until the battery is depleted. |
|
| SV-SP-11 |
Software defined radios - SDR is also another computer, networked to other parts of the spacecraft that could be pivoted to by an attacker and infected with malicious code. Once access to an SDR is gained, the attacker could alter what the SDR thinks is correct frequencies and settings to communicate with the ground. |
|
| SV-SP-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-5 |
Using fault management system against you. Understanding the fault response could be leveraged to get satellite in vulnerable state. Example, safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of TLM to cause action from ground, or some sort of RPO to cause S/C to go into safe mode; |
|
| SV-AV-6 |
Complete compromise or corruption of running state |
|
| SV-DCO-1 |
Not knowing that you were attacked, or attack was attempted |
|
| SV-MA-5 |
Not being able to recover from cyberattack |
|
| SV-AC-1 |
Attempting access to an access-controlled system resulting in unauthorized access |
|
| SV-AC-2 |
Replay of recorded authentic communications traffic at a later time with the hope that the authorized communications will provide data or some other system reaction |
|
| SV-CF-1 |
Tapping of communications links (wireline, RF, network) resulting in loss of confidentiality; Traffic analysis to determine which entities are communicating with each other without being able to read the communicated information |
|
| SV-CF-4 |
Adversary monitors for safe-mode indicators such that they know when satellite is in weakened state and then they launch attack |
|
| 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-AV-1 |
Communications system jamming resulting in denial of service and loss of availability and data integrity |
|
| SV-MA-7 |
Exploit ground system and use to maliciously to interact with the spacecraft |
|
| SV-AC-4 |
Masquerading as an authorized entity in order to gain access/Insider Threat |
|
| SV-AV-7 |
The TT&C is the lead contributor to satellite failure over the first 10 years on-orbit, around 20% of the time. The failures due to gyro are around 12% between year one and 6 on-orbit and then ramp up starting around year six and overtake the contributions of the TT&C subsystem to satellite failure. Need to ensure equipment is not counterfeit and the supply chain is sound. |
|
| SV-CF-3 |
Knowledge of target satellite's cyber-related design details would be crucial to inform potential attacker - so threat is leaking of design data which is often stored Unclass or on contractors’ network |
|
| SV-MA-6 |
Not planning for security on SV or designing in security from the beginning |
|
| SV-SP-4 |
General supply chain interruption or manipulation |
|
| SV-SP-5 |
Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused} |
|
| SPARTA ID | Requirement | Rationale/Additional Guidance/Notes |
|---|---|---|
| SPR-9 | The [organization] shall implement a security architecture and design that provides the required security functionality, allocates security controls among physical and logical components, and integrates individual security functions, mechanisms, and processes together to provide required security capabilities and a unified approach to protection.{SV-MA-6}{PL-7,SA-2,SA-8,SA-8(1),SA-8(2),SA-8(3),SA-8(4),SA-8(5),SA-8(6),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30),SC-32,SC-32(1)} | Security functionality must be intentionally distributed across physical and logical components rather than bolted on post-design. A unified architecture prevents inconsistent enforcement, duplicated controls, or unprotected interfaces. Integrated design reduces attack surface and improves verification of mission-critical protections. |
| SPR-530 | The [spacecraft] shall enable selected maintenance capabilities only within time‑bounded and mode‑bounded windows, audit enable/disable events, auto‑revert on timeout/reset, and expose enabled/disabled capability state in telemetry.{SV-AC-8,SV-AC-4}{CM-7,CM-7(2),SA-8,SA-8(14),AC-3} | Maintenance capabilities expand risk surface. Time-limited activation reduces abuse window. Telemetry exposure ensures oversight. Auto-revert strengthens containment. |
| ID | Name | Description | |
|---|---|---|---|
| REC-0001 | Gather Spacecraft Design Information | Threat actors seek a coherent picture of the spacecraft and its supporting ecosystem to reduce uncertainty and plan follow-on actions. Useful design information spans avionics architecture, command and data handling, comms and RF chains, power and thermal control, flight dynamics constraints, payload-to-bus interfaces, redundancy schemes, and ground segment dependencies. Artifacts often include ICDs, block diagrams, SBOMs and toolchains, test procedures, AIT travelers, change logs, and “as-built” versus “as-flown” deltas. Adversaries combine open sources (papers, patents, theses, conference slides, procurement documents, FCC/ITU filings, marketing sheets) with gray sources (leaked RFP appendices, vendor manuals, employee resumes, social posts) to infer single points of failure, unsafe modes, or poorly defended pathways between space, ground, and supply chain. The output of this activity is not merely a document set but a working mental model and, often, a lab replica that enables rehearsal, timing studies, and failure-mode exploration. | |
| REC-0001.01 | Software Design | Adversaries target knowledge of flight and ground software to identify exploitable seams and to build high-fidelity emulators for rehearsal. Valuable details include RTOS selection and version, process layout, inter-process messaging patterns, memory maps and linker scripts, fault-detection/isolation/recovery logic, mode management and safing behavior, command handlers and table services, bootloaders, patch/update mechanisms, crypto libraries, device drivers, and test harnesses. Artifacts may be source code, binaries with symbols, stripped images with recognizable patterns, configuration tables, and SBOMs that reveal vulnerable dependencies. With these, a threat actor can reverse engineer command parsing, locate debug hooks, craft inputs that bypass FDIR, or time payload and bus interactions to produce cascading effects. Supply-chain access to vendors of COTS components, open-source communities, or integrators can be used to insert weaknesses or to harvest build metadata. Even partial disclosures, such as a unit test name, an assert message, or a legacy API, shrink the search space for exploitation. | |
| REC-0001.02 | Firmware | Firmware intelligence covers microcontroller images, programmable logic bitstreams, boot ROM behavior, peripheral configuration blobs, and anti-rollback or secure-boot settings for devices on the bus. Knowing device types, versions, and footprints enables inference of default passwords, debug interfaces (JTAG, SWD, UART), timing tolerances, and error handling under brownout or thermal stress. A threat actor may obtain firmware from vendor reference packages, public evaluation boards, leaked manufacturing files, over-the-air update images, or crash dumps. Correlating that with board layouts, harness drawings, or part markings helps map trust boundaries and locate choke points like power controllers, bus bridges, and watchdog supervisors. Attack goals include: preparing malicious but apparently valid updates, exploiting unsigned or weakly verified images, forcing downgrades, or manipulating configuration fuses to weaken later defenses. Even when cryptographic verification is present, knowledge of recovery modes, boot-pin strapping, or maintenance commands can offer alternate paths. | |
| REC-0001.03 | Cryptographic Algorithms | Adversaries look for the complete crypto picture: algorithms and modes, key types and lifecycles, authentication schemes, counter or time-tag handling, anti-replay windows, link-layer protections, and any differences between uplink and downlink policy. With algorithm and key details, a threat actor can craft valid telecommands, masquerade as a trusted endpoint, or degrade availability through replay and desynchronization. Sources include interface specifications, ground software logs, test vectors, configuration files, contractor laptops, and payload-specific ICDs that reuse bus-level credentials. Particular risk arises when command links rely on authentication without confidentiality; once an adversary acquires the necessary keys or counters, they can issue legitimate-looking commands outside official channels. Programs should assume that partial disclosures, MAC length, counter reset rules, or key rotation cadence, aid exploitation. | |
| REC-0001.04 | Data Bus | Bus intelligence focuses on which protocols are used (e.g., MIL-STD-1553, SpaceWire, etc.), controller roles, addressing, timings, arbitration, redundancy management, and the location of critical endpoints on each segment. Knowing the bus controller, remote terminal addresses, message identifiers, and schedule tables allows an adversary to craft frames that collide with or supersede legitimate traffic, to starve health monitoring, or to trigger latent behaviors in payload or power systems. Additional details such as line voltages, termination, connector types, harness pinouts, and EMC constraints inform feasibility of injection and disruption techniques. Attackers assemble this picture from ICDs, vendor datasheets, AIT procedures, harness drawings, lab photos, and academic or trade publications that reveal typical configurations. Enumeration of bridges and gateways is especially valuable because they concentrate trust across fault-containment regions and between payload and bus. | |
| REC-0001.05 | Thermal Control System | Adversaries seek a working map of the thermal architecture and its operating envelopes to anticipate stress points and plan timing for other techniques. Valuable details include passive elements (MLI, coatings, radiators, heat pipes/straps, louvers) and active control (survival and control heaters, thermostats, pumped loops), plus sensor placement, setpoints, deadbands, heater priority tables, and autonomy rules that protect critical hardware during eclipses and anomalies. Artifacts often come from thermal math models (TMMs), TVAC test reports, heater maps and harness drawings, command mnemonics, and on-orbit thermal balance procedures. When correlated with attitude constraints, payload duty cycles, and power budgets, this information lets a threat actor infer when components run close to limits, how safing responds to off-nominal gradients, and where power-thermal couplings can be exploited. Even small fragments, such as louver hysteresis or a heater override used for decontamination, can reveal opportunities to mask heating signatures or provoke nuisance safing. | |
| REC-0001.06 | Maneuver & Control | Threat actors collect details of the guidance, navigation, and control (GNC) stack to predict vehicle response and identify leverage points during station-keeping, momentum management, and anomaly recovery. Useful specifics include propulsion type and layout (monoprop/biprop/electric; thruster locations, minimum impulse bit, plume keep-out zones), reaction wheels/CMGs and desaturation logic, control laws and gains, estimator design (e.g., EKF), timing and synchronization, detumble/safe-mode behaviors, and the full sensor suite (star trackers, sun sensors, gyros/IMUs, GNSS). Artifacts include AOCS/AOCS ICDs, maneuver procedures, delta-v budgets, ephemeris products, scheduler tables, and wheel management timelines. Knowing when and how attitude holds, acquisition sequences, or wheel unloads occur helps an adversary choose windows where injected commands or bus perturbations have outsized effect, or where sensor blinding and spoofing are most disruptive. | |
| REC-0001.07 | Payload | Adversaries pursue a clear picture of payload type, operating modes, command set, and data paths to and from the bus and ground. High-value details include vendor and model, operating constraints (thermal, pointing, contamination), mode transition logic, timing of calibrations, safety inhibits and interlocks, firmware/software update paths, data formatting and compression, and any crypto posture differences between payload links and the main command link. Payload ICDs often reveal addresses, message identifiers, and gateway locations where payload traffic bridges to the C&DH or data-handling networks, creating potential pivot points. Knowledge of duty cycles and scheduler entries enables timing attacks that coincide with high-power or high-rate operations to stress power/thermal margins or saturate storage and downlink. Even partial information, calibration script names, test vectors, or engineering telemetry mnemonics, can shrink the search space for reverse engineering. | |
| REC-0001.08 | Power | Reconnaissance of the electrical power system (EPS) focuses on generation, storage, distribution, and autonomy. Useful details include solar array topology and SADA behavior, MPPT algorithms, array string voltages, eclipse depth assumptions, battery chemistry and configuration, BMS charge/discharge limits and thermal dependencies, PCDU architecture, load-shed priorities, latching current limiters, and survival power rules. Artifacts surface in EPS ICDs, acceptance test data, TVAC power margin reports, anomaly response procedures, and vendor manuals. Correlating these with attitude plans and payload schedules lets a threat actor infer when state-of-charge runs tight, which loads are shed first, and how fast recovery proceeds after a brownout or safing entry. Knowledge of housekeeping telemetry formats and rate caps helps identify blind spots where abusive load patterns or command sequences may evade detection. | |
| REC-0001.09 | Fault Management | Fault management (FDIR/autonomy/safing) materials are a prime reconnaissance target because they encode how the spacecraft detects, classifies, and responds to off-nominal states. Adversaries seek trigger thresholds and persistence timers, voting logic, inhibit and recovery ladders, safe-mode entry/exit criteria, command authority in safed states, watchdog/reset behavior, and any differences between flight and maintenance builds. Artifacts include fault trees, FMEAs, autonomy rule tables, safing flowcharts, and anomaly response playbooks. With these, a threat actor can craft inputs that remain just below detection thresholds, stack benign-looking events to cross safing boundaries at tactically chosen times, or exploit recovery windows when authentication, visibility, or redundancy is reduced. Knowledge of what telemetry is suppressed or rate-limited during safing further aids concealment. | |
| REC-0002 | Gather Spacecraft Descriptors | Threat actors compile a concise but highly actionable dossier of “who/what/where/when” attributes about the spacecraft and mission. Descriptors include identity elements (mission name, NORAD catalog number, COSPAR international designator, call signs), mission class and operator, country of registry, launch vehicle and date, orbit regime and typical ephemerides, and any publicly filed regulatory artifacts (e.g., ITU/FCC filings). They also harvest operational descriptors such as ground network affiliations, common pass windows by latitude band, and staffing patterns implied by press, social media, and schedules. Even when each item is benign, the aggregate picture enables precise timing (e.g., during beta-angle peaks, eclipse seasons, or planned maintenance), realistic social-engineering pretexts, and better targeting of ground or cloud resources that support the mission. | |
| REC-0002.01 | Identifiers | Adversaries enumerate and correlate all identifiers that uniquely tag the vehicle throughout its lifecycle and across systems. Examples include NORAD/Satellite Catalog numbers, COSPAR designators, mission acronyms, spacecraft serials and bus IDs, regulatory call signs, network addresses used by mission services, and any constellation slot or plane tags. These identifiers allow cross-reference across public catalogs, tracking services, regulatory filings, and operator materials, shrinking search spaces for pass prediction, link acquisition, and vendor ecosystem discovery. Seemingly minor clues, like a configuration filename embedding a serial number or an operator using the same short name across environments, can expose test assets or internal tools. Rideshare and hosted-payload contexts introduce additional ambiguity that an attacker can exploit to mask activity or misattribute traffic. | |
| REC-0002.02 | Organization | Threat actors map the human and institutional terrain surrounding the mission to find leverage for phishing, credential theft, invoice fraud, or supply-chain compromise. Targeted details include the owner/operator, prime and subcontractors (bus, payload, ground, launch), key facilities and labs, cloud/SaaS providers, organizational charts, distribution lists, and role/responsibility boundaries for operations, security, and engineering. The objective is to identify who can approve access, who can move money, who holds admin roles on ground and cloud systems, and which vendors maintain remote access for support. Understanding decision chains also reveals when changes control boards meet, when ops handovers occur, and where a single compromised account could bridge enclaves. | |
| REC-0002.03 | Operations | Adversaries collect high-level operational descriptors to predict when the mission will be busy, distracted, or temporarily less instrumented. Useful items include CONOPS overviews, daily/weekly activity rhythms, ground pass schedules, DSN or commercial network windows, calibration and maintenance timelines, planned wheel unloads or thruster burns, conjunction-assessment cycles, and anomaly response playbooks at the level of “who acts when.” For constellations, they seek plane/slot assignments, phasing and drift strategies, crosslink usage, and failover rules between vehicles. These descriptors enable time-targeted campaigns, e.g., sending malicious but syntactically valid commands near handovers, exploiting reduced telemetry during safing, or saturating links during high-rate downlinks. | |
| REC-0003 | Gather Spacecraft Communications Information | Threat actors assemble a detailed picture of the mission’s RF and networking posture across TT&C and payload links. Useful elements include frequency bands and allocations, emission designators, modulation/coding, data rates, polarization sense, Doppler profiles, timing and ranging schemes, link budgets, and expected Eb/N0 margins. They also seek antenna characteristics, beacon structures, and whether transponders are bent-pipe or regenerative. On the ground, they track station locations, apertures, auto-track behavior, front-end filters/LNAs, and handover rules, plus whether services traverse SLE, SDN, or commercial cloud backbones. Even small details, polarization sense, roll-off factors, or beacon cadence, shrink the search space for interception, spoofing, or denial. The outcome is a lab-replicable demod/decode chain and a calendar of advantageous windows. | |
| REC-0003.01 | Communications Equipment | Adversaries inventory space and ground RF equipment to infer capabilities, limits, and attack surfaces. On the spacecraft, they seek antenna type and geometry, placement and boresight constraints, polarization, RF front-end chains, transponder type, translation factors, gain control, saturation points, and protective features. On the ground, they collect dish size/aperture efficiency, feed/polarizer configuration, tracking modes, diversity sites, and backend modem settings. Beacon frequency/structure, telemetry signal type, symbol rates, and framing reveal demodulator parameters and help an actor build compatible SDR pipelines. Knowledge of power budgets and AGC behavior enables strategies to push hardware into non-linear regimes, causing self-inflicted denial or intermodulation. Equipment location and mounting inform visibility and interference opportunities. | |
| REC-0003.02 | Commanding Details | Threat actors study how commands are formed, authorized, scheduled, and delivered. High-value details include the telecommand protocol (e.g., CCSDS TC), framing and CRC/MAC fields, authentication scheme (keys, counters, anti-replay windows), command dictionary/database formats, critical-command interlocks and enable codes, rate and size limits, timetag handling, command queue semantics, and the roles of scripts or procedures that batch actions. They also collect rules governing “valid commanding periods”: line-of-sight windows, station handovers, maintenance modes, safing states, timeouts, and when rapid-response commanding is permitted. With this, an adversary can craft syntactically valid traffic, time injections to coincide with reduced monitoring, or induce desynchronization (e.g., counter resets, stale timetags). | |
| REC-0003.03 | Mission-Specific Channel Scanning | Beyond TT&C, many missions expose additional RF or network surfaces: high-rate payload downlinks (e.g., X/Ka-band), user terminals, inter-satellite crosslinks, and hosted-payload channels that may be operated by different organizations. Adversaries scan spectrum and public telemetry repositories for these mission-specific channels, characterizing carrier plans, burst structures, access schemes (TDMA/FDMA/CDMA), addressing, and gateway locations. For commercial services, they enumerate forward/return links, user terminal waveforms, and provisioning backends that could be impersonated or jammed selectively. In hosted-payload or rideshare contexts, differences in configuration control and key management present opportunities for pivoting between enclaves. | |
| REC-0003.04 | Valid Credentials | Adversaries seek any credential that would let them authenticate as a legitimate actor in space, ground, or supporting cloud networks. Targets include TT&C authentication keys and counters, link-encryption keys, PN codes or spreading sequences, modem and gateway accounts, mission control mission control user and service accounts, station control credentials, VPN and identity-provider tokens, SLE/CSP service credentials, maintenance backdoor accounts, and automation secrets embedded in scripts or CI/CD pipelines. Acquisition paths include spear-phishing, supply-chain compromise, credential reuse across dev/test/ops, logs and core dumps, misconfigured repositories, contractor laptops, and improperly sanitized training data. Because some missions authenticate uplink without encrypting it, possession of valid keys or counters may be sufficient to issue accepted commands from outside official channels. | |
| REC-0004 | Gather Launch Information | Adversaries collect structured launch intelligence to forecast when and how mission assets will transition through their most time-compressed, change-prone phase. Useful elements include the launch date/time windows, launch site and range operator, participating organizations (launch provider, integrator, range safety, telemetry networks), vehicle family and configuration, fairing type, and upper-stage restart profiles. This picture enables realistic social-engineering pretexts, supply-chain targeting of contractors, and identification of auxiliary systems (range instrumentation, TLM/FTS links) that may be less hardened than the spacecraft itself. Knowledge of ascent comms (bands, beacons, ground stations), early-orbit operations (LEOP) procedures, and handovers to mission control further informs when authentication, staffing, or telemetry margins may be tight. | |
| REC-0004.01 | Flight Termination | Threat actors may attempt to learn how the launch vehicle’s flight termination capability is architected and governed, command-destruct versus autonomous flight termination (AFTS), authority chains, cryptographic protections, arming interlocks, inhibit ladders, telemetry indicators, and range rules for safe-flight criteria. While FTS is a range safety function, its interfaces (command links, keys, timing sources, decision logic) can reveal design patterns, dependencies, and potential misconfigurations across the broader launch ecosystem. Knowledge of test modes, simulation harnesses, and pre-launch checks could inform social-engineering or availability-degrading actions against range or contractor systems during critical windows. | |
| 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. | |
| REC-0006.02 | Security Testing Tools | Adversaries study how you test to learn what you don’t test. They inventory static analyzers and coding standards (MISRA/C, CERT, CWE rulesets), dynamic tools (address/UB sanitizers, valgrind-class tools), fuzzers targeted at command parsers and protocols (e.g., CCSDS TC/TM, payload formats), property-based tests, mutation testing, coverage thresholds, and formal methods applied to mode logic or crypto. They also examine HIL setups, fault-injection frameworks, timing/jitter tests, and regression suites that gate release. Gaps, such as minimal negative testing on rare modes, weak corpus diversity, or untested rate/size limits, inform exploit design and the timing of inputs to evade FDIR or saturate queues. | |
| REC-0007 | Monitor for Safe-Mode Indicators | Adversaries watch for telltale signs that the spacecraft has entered a safed or survival configuration, typically sun-pointing or torque-limited attitude, reduced payload activity, conservative power/thermal setpoints, and low-rate engineering downlink. Indicators include specific mode bits or beacon fields, changes in modulation/coding and cadence, distinctive event packets (e.g., wheel unload aborts, brownout recovery), elevated heater duty, altered load-shed states, and operator behaviors such as emergency DSN requests, longer ground passes, or public anomaly notices. This reconnaissance helps time later actions to coincide with periods of reduced bandwidth, altered monitoring, or maintenance command availability. It may also reveal how safing affects authentication (e.g., whether rapid-response paths or recovery consoles differ from nominal). | |
| REC-0008 | Gather Supply Chain Information | Threat actors map the end-to-end pathway by which hardware, software, data, and people move from design through AIT, launch, and on-orbit sustainment. They catalog manufacturers and lots, test and calibration houses, logistics routes and waypoints, integrator touchpoints, key certificates and tooling, update and key-loading procedures, and who holds custody at each handoff. They correlate this with procurement artifacts, SBOMs, BOMs, and service contracts to locate where trust is assumed rather than verified. Particular attention falls on exceptions, engineering builds, rework tickets, advance replacements, depot repairs, and urgent field updates, because controls are frequently relaxed there. The result is a prioritized list of choke points (board fabrication, FPGA bitstream signing, image repositories, CI/CD runners, cloud artifact stores, freight forwarders) where compromise yields outsized effect. | |
| REC-0008.01 | Hardware Recon | Adversaries seek insight into component sources, screening levels, test histories, and configuration states to prepare pre-delivery manipulation of boards and modules. High-value details include ASIC/FPGA part numbers and stepping, security fuses and life-cycle states, JTAG/SWD access policies, secure-boot and anti-rollback configuration, golden bitstream handling, board layouts and test points, conformal coat practices, and acceptance test procedures with allowable tolerances. Knowledge of substitute/alternate parts, counterfeit screening thresholds, and waiver histories reveals where counterfeit insertion or parametric “near-miss” parts might evade detection. For programmable logic, attackers target synthesis/place-and-route toolchains, IP core versions, and bitstream encryption keys to enable hardware Trojans or debug backdoors that survive functional test. Logistics artifacts (packing lists, RMA workflows, depot addresses) expose moments when custody is thin and tamper opportunities expand. | |
| REC-0008.02 | Software Recon | Threat actors enumerate the software factory: where source lives, how dependencies are pulled, how artifacts are built, signed, stored, and promoted to flight. They inventory repos and access models, CI/CD orchestrators, build containers and base images, package registries, signing services/HSMs, update channels, and the policies that gate promotion (tests, reviews, attestations). With this, an adversary can plan dependency confusion or typosquatting attacks, modify build scripts, poison cached artifacts, or swap binaries at distribution edges (mirrors, CDN, ground station staging). | |
| REC-0008.04 | Business Relationships | Threat actors map contractual and operational relationships to identify the weakest well-connected node. They enumerate primes and subs (bus, payload, ground, launch), managed service providers, ground-network operators, cloud/SaaS tenants, testing and calibration labs, logistics and customs brokers, and warranty/repair depots, plus who holds remote access, who moves money, and who approves changes. Public artifacts (press releases, procurement records, org charts, job postings, conference bios) and technical traces (email MX/DMARC, shared SSO/IdP providers, cross-domain service accounts) reveal trust bridges between enclaves. Shipment paths and integration schedules expose when and where hardware and sensitive data concentrate. Understanding these ties enables tailored phishing, invoice fraud, credential reuse, and supply-chain insertion timed to integration milestones. | |
| REC-0009 | Gather Mission Information | Adversaries compile a CONOPS-level portrait of the mission to predict priorities, constraints, and operational rhythms. They harvest stated needs, goals, and performance measures; enumerate key elements/instruments and their duty cycles; and extract mode logic, operational constraints (pointing, keep-outs, contamination, thermal/power margins), and contingency concepts. They mine the scientific and engineering basis, papers, algorithms, calibration methods, to anticipate data value, processing chains, and where integrity or availability attacks would have maximal effect. They correlate physical and support environments (ground networks, cloud pipelines, data distribution partners, user communities) and public schedules (campaigns, calibrations, maneuvers) to identify periods of elevated workload or reduced margin. The aim is not merely understanding but timing: choosing moments when authentication might be relaxed, monitoring is saturated, or rapid-response authority is invoked. | |
| RD-0001 | Acquire Infrastructure | Adversaries assemble the people, platforms, and plumbing they will later use to observe, reach, or impersonate mission components. Infrastructure spans RF and optical ground assets (antennas, modems, timing sources, front-ends), compute and storage (on-prem and cloud), network presence (leased ASNs/IP space, VPS fleets, CDN relays), identity fabric (burner accounts, domains, certificates), and fabrication/test environments for hardware and software. They favor assets that are inexpensive, deniable, and geographically diverse, mixing self-hosted gear with commercial services and compromised third-party systems. To support spacecraft operations, they may build SDR-based labs that replicate waveforms and framing, stage command/telemetry tooling behind traffic mixers, and pre-position data pipelines for collection and analysis. The objective is persistence and flexibility: the ability to pivot between reconnaissance, delivery, and command with minimal attribution risk. | |
| RD-0001.01 | Ground Station Equipment | Rather than compromising existing stations, adversaries may acquire or assemble their own RF ground stack. Typical building blocks include: steerable mounts with auto-track, time/frequency standards, band-appropriate antennas and feeds, LNAs and filters at the feed, low-loss IF chains, T/R switching, medium/high-power amplifiers with protection and telemetry, and weather protection. Baseband equipment often mixes SDRs with commercial modems to generate/capture mission waveforms and framing; signal generators and spectrum analyzers support calibration and banner-grabbing. On the digital side, ground data processors translate captured frames to packetized formats for analysis and rehearsal. With this kit, an actor can passively collect, actively probe, or attempt spoofing if link-layer authentication is weak. | |
| RD-0001.02 | Commercial Ground Station Services | Instead of building dishes, adversaries may rent time on commercial ground networks or cloud-integrated “ground-station-as-a-service.” Access can be obtained legitimately (front companies, weak vetting) or via compromised customer accounts, allowing schedule requests, RF front-end configuration, and data egress through reputable providers. The appeal is speed, global reach, and plausible deniability; the risk to defenders is that traffic originates from expected stations and IP ranges. Misuse may include reconnaissance (passive capture), selective denial (misconfiguration or saturation attempts), or, where authentication is weak, unauthorized commanding. | |
| RD-0001.03 | Spacecraft | A well-resourced actor may field their own spacecraft or hosted payload to gain proximity, visibility, or RF leverage. Small satellites can be launched into nearby planes or phasing orbits to observe emissions, perform spectrum measurements, or test spoofing and denial techniques at short range. Hosted payloads on commercial buses provide co-location without full spacecraft development. Proximity also enables on-orbit relay, crosslink probing, or attempts to exploit weak segmentation between payload and bus on rideshares. Regulatory and tracking regimes complicate overt misuse, but shell companies, benign-seeming mission declarations, or flags of convenience can mask intent. | |
| RD-0001.04 | Launch Facility | In practice, adversaries are far more likely to purchase launch services (rideshare slots, hosted-payload opportunities) than to “acquire a launch facility.” Nevertheless, understanding and exploiting launch infrastructure, pads, integration cells, range networks, and control centers, could support resource development (e.g., positioning an asset, staging equipment near range telemetry). The realistic objective is influence over access to orbit, schedule, or integration touchpoints rather than ownership of a pad. Shell entities might book benign-sounding rides, insert dual-use payloads, or seek special handling that relaxes controls. | |
| RD-0002 | Compromise Infrastructure | Rather than purchasing or renting assets, adversaries compromise existing infrastructure, mission-owned, third-party, or shared, to obtain ready-made reach into space, ground, or cloud environments with the benefit of plausible attribution. Targets range from physical RF chains and timing sources to mission control servers, automation/scheduling systems, SLE/CSP gateways, identity providers, and cloud data paths. Initial access often comes via stolen credentials, spear-phishing of operators and vendors, exposed remote-support paths, misconfigured multi-tenant platforms, or lateral movement from enterprise IT into operations enclaves. Once resident, actors can pre-position tools, modify configurations, suppress logging, and impersonate legitimate stations or operators to support later Execution, Exfiltration, or Denial. | |
| RD-0002.03 | 3rd-Party Spacecraft | By compromising another operator’s spacecraft, or a hosted payload, an adversary can gain proximity, sensing, and relay capabilities that are costly to build from scratch and difficult to attribute. With control of an on-orbit asset, the actor may conduct local spectrum measurement and traffic analysis, attempt selective interference or spoofing at short range, or probe crosslinks and gateways where payload networks bridge to buses. In rideshare or hosted-payload contexts, weak segmentation and shared ground paths can provide insight into neighboring missions. More aggressive scenarios include remote proximity operations (RPO) to achieve advantageous geometry; however, physical grappling, docking, or exposure of debug/test interfaces is highly specialized and rare, with significant safety, legal, and tracking implications. Realistic attacker goals emphasize adjacency for RF leverage, covert relay, or data theft rather than mechanical capture. | |
| RD-0003 | Obtain Cyber Capabilities | Adversaries acquire ready-made tools, code, and knowledge so they can move faster and with lower attribution when operations begin. Capabilities span commodity malware and loaders, bespoke implants for mission control mission control and ground enclaves, privilege-escalation and lateral-movement kits, SDR/codec stacks for TT&C and payload links, fuzzers and protocol harnesses, exploit chains for RTOS/middleware and ground services, and databases of configuration playbooks from prior intrusions. Actors prefer modular kits that can be re-skinned (new C2, new certs) and exercised in flatsat or SIL/HIL labs before use. They also collect operational “how-tos”, procedures, scripts, and operator macros, that convert technical access into mission effects. | |
| RD-0003.01 | Exploit/Payload | Threat actors obtain or adapt exploits (the trigger) and payloads (the action after exploitation) for space, ground, and cloud components. Targets include flight software parsers and table loaders, bootloaders and patch/update handlers, bus gateways, payload controllers, and ground services. Payloads may be binaries, scripts, or command/procedure sequences that alter modes, bypass FDIR, or stage follow-on access; they can also be “data payloads” that exploit weak validation (malformed tables, ephemeris, or calibration products). Acquisition paths mirror the broader market, brokered N-day/0-day packages, open-source exploits re-tooled for mission stacks, and theft from vendors or researchers. Actors tune timing, size/rate limits, and anti-replay nuances so delivery fits pass windows and link budgets, and they rehearse on flatsats to achieve deterministic outcomes. | |
| RD-0003.02 | Cryptographic Keys | Adversaries seek any cryptographic material that confers command or decryption authority: uplink authentication/MAC keys and counters, link-encryption/session keys and KEKs, loading/transfer keys for HSMs, PN/spreading codes, modem credentials, and station or crosslink keys. Acquisition routes include compromised ground systems and laptops, misconfigured repositories and ticket systems, memory/core dumps, training datasets and screenshots, contractor support channels, and poorly controlled key-loading or recovery procedures. Because some missions authenticate uplink without encrypting it, possession of the right keys/counters may be sufficient to inject accepted commands outside official channels or to desynchronize anti-replay. | |
| RD-0004 | Stage Capabilities | Before execution, adversaries prepare the ground, literally and figuratively. They upload tooling, exploits, procedures, and datasets to infrastructure they own or have compromised, wire up C2 and telemetry pipelines, and pre-configure RF/baseband chains and protocol stacks to match mission parameters. Staging often uses cloud object stores, VPS fleets, or CI/CD runners masquerading as benign automation; artifacts are containerized or signed with hijacked material to blend in. For RF operations, actors assemble demod/encode flowgraphs, precompute CRC/MAC fields and timetags, and script rate/size pacing to fit pass windows. For ground/cloud, they stage credentials, macros, and schedule templates that can push changes or exfiltrate data quickly during handovers or safing. Dry-runs on flatsats/HIL rigs validate timing and error paths; OPSEC measures (rotating domains, domain fronting, traffic mixers) reduce attribution. | |
| RD-0004.01 | Identify/Select Delivery Mechanism | Adversaries select the pathway that best balances effect, risk, bandwidth, and attribution. Options include over-the-air telecommand injection on TT&C links, manipulation of payload downlinks or user terminals, abuse of crosslinks or gateways, pivoting through commercial ground networks, or pushing malicious updates via supply-chain paths (software, firmware, bitstreams). Selection considers modulation/coding, Doppler and polarization, anti-replay windows, pass geometry, rate/size limits, and expected operator workload (handover, LEOP, safing exits). For ground/cloud paths, actors account for identity boundaries, automation hooks, and change-control cadence. The “delivery mechanism” is end-to-end: RF front-end (antenna, converters, HPAs), baseband/SDR chain, protocol/framing, authentication/counter handling, scheduling, and fallbacks if detection occurs. Rehearsal artifacts, test vectors, mock dictionaries, ephemerides, are built alongside. | |
| RD-0004.02 | Upload Exploit/Payload | Having chosen a path, adversaries pre-position the specific packages and procedures they intend to use: binary exploits, malicious tables and ephemerides, patch images, modem profiles, and operator macros that chain actions. On compromised or leased infrastructure, they stage these items where execution will be fastest, provider portals, scheduler queues, ground station file drops, or automation repos, with triggers tied to pass start, beacon acquisition, or operator shift changes. Artifacts are formatted to mission protocols (framing, CRC/MAC, timetags), chunked to meet rate/size constraints, and signed or wrapped to evade superficial checks. Anti-forensics (timestamp tampering, log suppression, ephemeral storage) reduce audit visibility, while fallback payloads are kept for alternate modes (safe-mode dictionaries, recovery consoles). | |
| RD-0005 | Obtain Non-Cyber Capabilities | Adversaries may pursue non-cyber counterspace means to create access, leverage, or effects that complement cyber operations. These capabilities span kinetic physical (e.g., direct-ascent or co-orbital interceptors and attacks on ground segments), non-kinetic physical (e.g., lasers, high-power microwave/EMP), and electronic warfare (jamming and spoofing). Each class differs in required resources, detectability, attribution, and the permanence of effects, from reversible interference to irreversible destruction. A pragmatic actor mixes methods: electronic attack to mask or distract, directed energy to blind sensors or upset electronics, and, at the top end, kinetic capabilities to hold assets at risk. Resource development may involve acquisition, partnering, or covert access to such systems; rehearsals are often framed as testing or calibration. | |
| RD-0005.01 | Launch Services | Rather than “owning a pad,” a realistic path is purchasing launch services (rideshare, hosted payload) to place inspection or relay assets where they confer RF, optical, or proximity advantage. Launch providers deliver integration, testing, and scheduling; an actor can use benign mission covers to field small satellites that measure local spectrum, perform on-orbit characterization of target emissions, or support later rendezvous and proximity operations. The resource being developed is access to vantage points, not just spaceflight hardware. | |
| RD-0005.02 | Non-Kinetic Physical ASAT | Non-kinetic physical ASATs damage or degrade without contact, typically via directed energy or intense electromagnetic effects. Ground- or space-based lasers can dazzle or blind optical sensors; high-power microwave or related electromagnetic systems can disrupt or permanently damage susceptible electronics; some concepts aim to generate broader electromagnetic effects. These attacks propagate at light speed, can be tuned for reversible or lasting impact, and may leave limited forensic residue, complicating verification and attribution. Actors who obtain or partner for such systems can pair them with cyber operations (e.g., blind a star tracker while injecting misleading commands) to amplify effect. | |
| RD-0005.03 | Kinetic Physical ASAT | Kinetic capabilities physically strike space or ground elements. In space, direct-ascent systems launch from Earth to intercept a satellite on orbit; co-orbital systems maneuver in space to approach and impact a target. On the ground, kinetic attacks can target stations or support infrastructure. These actions are generally easier to detect and attribute and often produce persistent, hazardous debris in orbit, especially at higher altitudes, making them strategically escalatory. Actors developing or accessing such capabilities gain credible coercive power but at significant political and operational cost. | |
| RD-0005.04 | Electronic ASAT | Electronic ASAT attacks target the communications lifelines of space systems rather than their structures: jamming raises the noise floor to deny service; spoofing crafts believable but false signals (navigation, timing, or control). These effects are usually transient and can be difficult to attribute quickly, yet they are operationally useful and comparatively inexpensive. Actors may obtain portable or fixed jammers, high-gain antennas with agile waveforms, and specialized signal-processing toolchains; from orbit, a nearby asset can deliver highly selective interference. | |
| 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-0003 | Crosslink via Compromised Neighbor | Where spacecraft exchange data over inter-satellite links (RF or optical), a compromise on one vehicle can become a bridgehead to others. Threat actors exploit crosslink trust: shared routing, time distribution, service discovery, or gateway functions that forward commands and data between vehicles and ground. With knowledge of crosslink framing, addressing, and authentication semantics, an adversary can craft traffic that appears to originate from a trusted neighbor, injecting control messages, malformed service advertisements, or payload tasking that propagates across the mesh. In tightly coupled constellations, crosslinks may terminate on gateways that also touch the C&DH or payload buses, providing additional pivot opportunities. Because crosslink traffic is expected and often high volume, attacker activity can be timed to blend with synchronization intervals, ranging exchanges, or scheduled data relays. | |
| 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.01 | Ground Station | Threat actors may target the backup ground segment, standby MOC sites, alternate commercial stations, or contingency chains held in reserve. Threat actors establish presence on the backup path (operator accounts, scheduler/orchestration, modem profiles, antenna control) and then exploit moments when operations shift: planned exercises, maintenance at the primary site, weather diversions, or failover during anomalies. They may also shape conditions so traffic is re-routed, e.g., by saturating the primary’s RF front end or consuming its schedules, without revealing their involvement. Once on the backup, prepositioned procedures, macros, or configuration sets allow command injection, manipulation of pass timelines, or quiet collection of downlink telemetry. | |
| 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-0005 | Rendezvous & Proximity Operations | Adversaries may execute a sequence of orbital maneuvers to co-orbit and approach a target closely enough for local sensing, signaling, or physical interaction. Proximity yields advantages that are difficult to achieve from Earth: high signal-to-noise for interception, narrowly targeted interference or spoofing, observation of attitude/thermal behavior, and, if interfaces exist, opportunities for mechanical mating. The approach typically unfolds through phasing, far-field rendezvous, relative navigation (e.g., vision, lidar, crosslink cues), and closed-loop final approach. At close distances, an attacker can monitor side channels, stimulate acquisition beacons, test crosslinks, or prepare for contact operations such as capture or docking. Contact itself is not the endpoint: mating and grappling expose data and power umbilicals, standardized payload ports, service and checkout connectors, and device programming interfaces that are unreachable by any other means. | |
| IA-0005.02 | Docked Vehicle / OSAM | Docking, berthing, or service capture during on-orbit servicing, assembly, and manufacturing (OSAM) creates a high-trust bridge between vehicles. Threat actors exploit this moment, either by pre-positioning code on a servicing vehicle or by manipulating ground updates to it, so that, once docked, lateral movement occurs across the mechanical/electrical interface. Interfaces may expose power and data umbilicals, standardized payload ports, or gateways into the target’s C&DH or payload networks (e.g., SpaceWire, Ethernet, 1553). Service tools that push firmware, load tables, transfer files, or share time/ephemeris become conduits for staged procedures or implants that execute under maintenance authority. Malware can be timed to activation triggers such as “link up,” “maintenance mode entered,” or specific device enumerations that only appear when docked. Because OSAM operations are scheduled and well-documented, the adversary can align preparation with published timelines, ensuring that the first point of execution coincides with the brief window when cross-vehicle trust is intentionally elevated. | |
| IA-0005.03 | Proximity Grappling | In this variant, the attacker employs a capture mechanism (robotic arm, grappling fixture, magnetic or mechanical coupler) to establish physical contact without full docking. Once grappled, covers can be manipulated, temporary umbilicals attached, or exposed test points engaged; if design provisions exist (service ports, checkout connectors, external debug pads), these become direct pathways to device programming interfaces (e.g., JTAG/SWD/UART), mass-storage access, or maintenance command sets. Grappling also enables precise attitude control relative to the target, allowing contact-based sensors to read buses inductively or capacitively, or to inject signals onto harness segments reachable from the exterior. Initial access arises when a maintenance or debug path, normally latent in flight, is electrically or logically completed by the grappled connection, allowing authentication-bypassing actions such as boot-mode strapping, image replacement, or scripted command ingress. The operation demands accurate geometry, approach constraints, and fixture knowledge, but yields a transient, high-privilege bridge tailored for short, decisive actions that leave minimal on-orbit RF signature. | |
| 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-0007.02 | Malicious Commanding via Valid GS | Adversaries may use a compromised, mission-owned ground system to transmit legitimate-looking commands to the target spacecraft. Because the ground equipment is already configured for the mission, correct waveforms, framing, dictionaries, and scheduling, the attacker’s traffic blends with routine operations. Initial access unfolds by inserting commands or procedures into existing timelines, modifying rate/size limits or command queues, or invoking maintenance dictionaries and rapid-response workflows that accept broader command sets. Pre-positioned scripts can chain actions across multiple passes and stations, while telemetry routing provides immediate feedback to refine follow-on steps. Exfiltration can be embedded in standard downlink channels or forwarded through gateways as ordinary mission data. The distinguishing feature is that command origin appears valid, transmitted from approved apertures using expected parameters, so the first execution event is not a protocol anomaly but a misuse of legitimate command authority obtained through the compromised ground system. | |
| IA-0008 | Rogue External Entity | Adversaries obtain a foothold by interacting with the spacecraft from platforms outside the authorized ground architecture. A “rogue external entity” is any actor-controlled transmitter, platform, or node, ground, maritime, airborne, or space-based. Most interact by radiating or exchanging traffic using mission-compatible waveforms, framing, or crosslink protocols. Others carry no mission-compatible capability at all, and instead apply interference, directed energy, or physical proximity to shape the conditions under which access becomes possible. The technique exploits the fact that many vehicles must remain commandable and discoverable over wide areas and across multiple modalities. Using public ephemerides, pass predictions, and knowledge of acquisition procedures, the actor times transmissions to line-of-sight windows, handovers, or maintenance periods. Initial access stems from presenting traffic that the spacecraft will parse or prioritize, such as syntactically valid telecommands, crafted ranging/acquisition exchanges, crosslink service advertisements, or payload/user-channel messages that bridge into the command/data path, or, for entities operating by effect rather than by protocol, from the contingency behavior those effects induce. | |
| IA-0008.01 | Rogue Ground Station | Adversaries may field their own ground system, transportable or fixed, to transmit and receive mission-compatible signals. A typical setup couples steerable apertures and GPS-disciplined timing with SDR/modems configured for the target’s bands, modulation/coding, framing, and beacon structure. Using pass schedules and Doppler/polarization predictions, the actor crafts over-the-air traffic that appears valid at the RF and protocol layers. | |
| IA-0008.02 | Rogue Spacecraft | Adversaries may employ their own satellite or hosted payload to achieve proximity and a privileged RF geometry. After phasing into the appropriate plane or drift orbit, the rogue vehicle operates as a local peer: emitting narrow-beam or crosslink-compatible signals, relaying user-channel traffic that the target will honor, or advertising services that appear to originate from a trusted neighbor. Close range reduces path loss and allows highly selective interactions, e.g., targeted spoofing of acquisition exchanges, presentation of crafted routing/time distribution messages, or injection of payload tasking that rides established inter-satellite protocols. The rogue platform can also perform spectrum and protocol reconnaissance in situ, refining message formats and timing before attempting first execution. | |
| IA-0008.03 | ASAT/Counterspace Weapon | Adversaries leverage counterspace platforms to create conditions under which initial execution becomes possible or to impose effects directly. Electronic warfare systems can jam or spoof links so that the target shifts to contingency channels or accepts crafted navigation/control signals; directed-energy systems can dazzle sensors or upset electronics, shaping mode transitions and autonomy responses; kinetic or contact-capable systems can enable mechanical interaction that exposes maintenance or debug paths. In each case, the counterspace asset is an external actor-controlled node that interacts with the spacecraft outside authorized ground pathways. Initial access may be the immediate result of accepted spoofed traffic, or it may be secondary, arising when the target enters states with broader command acceptance, alternative receivers, or service interfaces that the adversary can then exploit. | |
| IA-0009 | Trusted Relationship | Adversaries obtain first execution by riding connections that the mission already trusts, formal interconnections with partners, vendors, and user communities. Once a third party is compromised, the actor inherits that entity’s approved routes into mission enclaves: VPNs and jump hosts into ground networks, API keys into cloud tenants, automated file drops that feed command or update pipelines, and collaboration spaces where procedures and dictionaries circulate. Because traffic, credentials, and artifacts originate from known counterparts, the initial execution event can appear as a routine payload task, scheduled procedure, or software update promoted through established processes. | |
| IA-0009.01 | Mission Collaborator (academia, international, etc.) | Missions frequently depend on distributed teams, instrument builders at universities, science operations centers, and international partners, connected by data portals, shared repositories, and federated credentials. A compromise of a collaborator yields access to telescience networks, analysis pipelines, instrument commanding tools, and file exchanges that deliver ephemerides, calibration products, procedures, or configuration tables into mission workflows. Partners may operate their own ground elements or payload gateways under delegated authority, creating additional entry points whose authentication and logging differ from the prime’s. Initial access emerges when attacker-modified artifacts or commands traverse these sanctioned paths: a revised calibration script uploaded through a science portal, a configuration table promoted by a cross-org CI job, or a payload task submitted via a collaboration queue and forwarded by the prime as routine work. Variations in process rigor, identity proofing, and toolchains across institutions amplify the attacker’s options while preserving the appearance of legitimate partner activity. | |
| IA-0009.02 | Vendor | Vendors that design, integrate, or support mission systems often hold elevated, persistent routes into operations: remote administration of ground software and modems, access to identity providers and license servers, control of cloud-hosted services, and authority to deliver firmware, bitstreams, or patches. Attackers who compromise a vendor’s enterprise or build environment can assume these roles, issuing commands through approved consoles, queuing updates in provider-operated portals, or invoking maintenance procedures that the mission expects the vendor to perform. Some vendor pathways terminate directly on RF equipment or key-management infrastructure; others ride cross-account cloud roles or managed SaaS backends that handle mission data and scheduling. | |
| IA-0009.03 | User Segment | The “user segment” encompasses end users and their equipment that interact with mission services, SATCOM terminals, customer ground gateways, tasking portals, and downstream processing pipelines for delivered data. Where these environments interconnect with mission cores, a compromised user domain becomes a springboard. Attackers can inject malformed tasking requests that propagate into payload scheduling, craft user-plane messages that traverse gateways into control or management planes, or seed data products that flow back to mission processing systems and automation. In broadband constellations and hosted services, user terminals may share infrastructure with TT&C or provider management networks, creating opportunities to pivot from customer equipment into provider-run nodes that the spacecraft trusts. | |
| IA-0010 | Unauthorized Access During Safe-Mode | Adversaries time their first execution to coincide with safe-mode, when the vehicle prioritizes survival and recovery. In many designs, safe-mode reconfigures attitude, reduces payload activity, lowers data rates, and enables contingency dictionaries or maintenance procedures that are dormant in nominal operations. Authentication, rate/size limits, command interlocks, and anti-replay handling may differ; some implementations reset counters, relax timetag screening, accept broader command sets, or activate alternate receivers and beacons to improve commandability. Ground behavior also shifts: extended passes, emergency scheduling, and atypical station use create predictable windows. An attacker who understands these patterns can present syntactically valid traffic that aligns with safe-mode expectations, maintenance loads, recovery scripts, table edits, or reboot/patch sequences, so the first accepted action appears consistent with fault recovery rather than intrusion. | |
| 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-0001 | Replay | Replay is the re-transmission of previously captured traffic, over RF links, crosslinks, or internal buses, to elicit the same processing and effects a second time. Adversaries first observe and record authentic exchanges (telecommands, ranging/acquisition frames, housekeeping telemetry acknowledgments, bus messages), then resend them within acceptance conditions that the system recognizes, matching link geometry, timetags, counters, or mode states. The aim can be functional (re-triggering an action such as a mode change), observational (fingerprinting how the vehicle reacts at different states), or disruptive (saturating queues and bandwidth to crowd out legitimate traffic). Because replays preserve valid syntax and often valid context, they can blend with normal operations, especially during periods with reduced monitoring or when counters and windows reset (e.g., handovers, safing entries). On encrypted links, metadata replays (acquisition beacons, schedule requests) may still yield informative responses. | |
| EX-0001.01 | Command Packets | Threat actors may resend authentic-looking telecommands that were previously accepted by the spacecraft. Captures may include whole command PDUs with framing, CRC/MAC, counters, and timetags intact, or they may be reconstructed from operator tooling and procedure logs. When timing, counters, and mode preconditions align, the replayed packet can cause the same effect: toggling relays, initiating safing or recovery scripts, adjusting tables, commanding momentum dumps, or scheduling delta-v events. Even when outright execution fails, repeated “near-miss” injections can map acceptance windows, rate/size limits, and interlocks by observing the spacecraft’s acknowledgments and state changes. At scale, streams of valid-but-stale commands can congest command queues, delay legitimate activity, or trigger nuisance FDIR responses. | |
| EX-0001.02 | Bus Traffic Replay | Instead of the RF path, the attacker targets internal command/data handling by injecting or retransmitting messages on the spacecraft bus (e.g., 1553, SpaceWire, custom). Because many subsystems act on the latest message or on message rate rather than on uniqueness, a flood of historical yet well-formed frames can consume bandwidth, starve critical publishers, or cause subsystems to perform the same action repeatedly. Secondary effects include stale sensor values being re-consumed, watchdog timers being reset at incorrect intervals, and autonomy rules misclassifying the situation due to out-of-order but valid-looking events. On time-triggered or scheduled buses, replaying at precise offsets can collide with or supersede legitimate messages, steering system state without changing software. The goal is to harness the bus’s determinism, repeating prior internal stimuli to recreate prior effects or to induce resource exhaustion. | |
| 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-0005.02 | Malicious Use of Hardware Commands | Threat actors may issue low-level device or maintenance commands that act directly on hardware, bypassing much of the high-level command mediation. These may be memory-mapped register writes forwarded over the bus, vendor-specific instrument/control opcodes, built-in-test and calibration modes, boot-mode or fuse-programming sequences, file/sector operations to on-board non-volatile stores, or actuator primitives for wheels, thrusters, motors, heaters, and RF chains. Because these interfaces exist to configure sensors, zero momentum, switch power domains, tune gains, or adjust clocks, they can also be sequenced to produce harmful effects: over-driving mechanisms, altering persistent calibration, disabling watchdogs, or switching timing sources. Some hardware command sets are only exposed in maintenance or contingency modes, while others are always reachable through gateway processors that translate high-level telecommands into device-level operations. By crafting orders that respect expected framing and rate/size limits, the adversary can induce mechanical, electrical, or logical state changes with immediate, high-privilege impact, all while appearing to exercise legitimate device capabilities. | |
| EX-0006 | Disable/Bypass Encryption | The adversary alters how confidentiality or integrity is applied so traffic or data is processed in clear or with weakened protection. Paths include toggling configuration flags that place links or storage into maintenance/test modes; forcing algorithm “fallbacks” or null ciphers; downgrading negotiated suites or keys; manipulating anti-replay/counter state so checks are skipped; substituting crypto libraries or tables during boot/update; and selecting alternate routes that carry the same content without encryption. On some designs, distinct modes handle authentication and confidentiality separately, allowing an actor who obtains authentication material to request unencrypted service or to switch to legacy profiles. The end state is that command, telemetry, or data products traverse a path the spacecraft accepts while cryptographic protection is absent, weakened, or inconsistently applied, enabling subsequent tactics such as inspection, manipulation, or exfiltration. | |
| EX-0007 | Trigger Single Event Upset | The attacker induces or opportunistically exploits a single-event upset (SEU), a transient bit flip or latch disturbance in logic or memory, so that software executes in a state advantageous to the attack. SEUs arise when charge is deposited at sensitive nodes by energetic particles or intense electromagnetic stimuli. An actor may time operations to coincide with natural radiation peaks or use artificial means from close range. Outcomes include corrupted stacks or tables, altered branch conditions, flipped configuration bits in FPGAs or controllers, and transient faults that push autonomy/FDIR into recovery modes with broader command acceptance. SEU exploitation is probabilistic; the technique couples repeated stimulation with careful observation of mode transitions, watchdogs, and error counters to land the system in a desired but nominal-looking state from which other actions can proceed. | |
| 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-0011 | Exploit Reduced Protections During Safe-Mode | The adversary times on-board actions to the period when the vehicle is in safe-mode and operating with altered guardrails. In many designs, safe-mode enables contingency command dictionaries, activates alternate receivers or antennas, reduces data rates, and prioritizes survival behaviors (sun-pointing, thermal/power conservation). Authentication checks, anti-replay windows, rate/size limits, and interlocks may differ from nominal; counters can be reset, timetag screening relaxed, or maintenance procedures made available for recovery. Ground cadence also changes, longer passes, emergency scheduling, atypical station selection, creating predictable windows for interaction. Using knowledge of these patterns, an attacker issues maintenance-looking loads, recovery scripts, parameter edits, or boot/patch sequences that the spacecraft is primed to accept while safed. Because responses (telemetry beacons, acknowledgments, mode bits) resemble normal anomaly recovery, the first execution event blends with expected behavior, allowing unauthorized reconfiguration, software modification, or state manipulation to occur under the cover of fault response. | |
| 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.01 | Registers | Threat actors may target the internal registers of the victim spacecraft in order to modify specific values as the FSW is functioning or prevent certain subsystems from working. Most aspects of the spacecraft rely on internal registers to store important data and temporary values. By modifying these registers at certain points in time, threat actors can disrupt the workflow of the subsystems or onboard payload, causing them to malfunction or behave in an undesired manner. | |
| EX-0012.02 | Internal Routing Tables | Threat actors may rewrite the maps that tell software where to send and receive things. In publish/subscribe or message-queued flight frameworks, tables map message IDs to subscribers, opcodes to handlers, and pipes to processes; at interfaces, address/port maps define how traffic traverses bridges and gateways (e.g., SpaceWire node/port routes, 1553 RT/subaddress mappings, CAN IDs). By altering these structures, commands can be misdelivered, dropped, duplicated, or routed through unintended paths; telemetry can be redirected or blackholed; and handler bindings can be swapped so an opcode triggers the wrong function. Schedule/routing hybrids, used to sequence activities and distribute results, can be edited to reorder execution or to create feedback loops that occupy bandwidth and processor time. The result is control over who hears what and when, achieved by changing the lookup tables that underpin command/telemetry distribution rather than the code that processes them. | |
| EX-0012.03 | Memory Write/Loads | The adversary uses legitimate direct-memory commands or load services to place chosen bytes at chosen addresses. Many spacecraft support raw read/write operations, block loads into RAM or non-volatile stores, and table/file loaders that copy content into working memory. With knowledge of address maps and data structures, an attacker can patch function pointers or vtables, alter limit and configuration records, seed scripts or procedures into interpreter buffers, adjust DMA descriptors, or overwrite portions of executable images resident in RAM. Loads may be sized and paced to fit link and queue constraints, then activated by a subsequent command, mode change, or natural reference by the software. | |
| EX-0012.04 | App/Subscriber Tables | In publish/subscribe flight frameworks, applications and subsystems register interest in specific message classes via subscriber (or application) tables. These tables map message IDs/topics to subscribers, define delivery pipes/queues, and often include filters, priorities, and rate limits. By altering these mappings, an adversary can quietly reshape information flow: critical consumers stop receiving health or sensor messages; non-critical tasks get flooded; handlers are rebound so an opcode or message ID reaches the wrong task; or duplicates create feedback loops that consume bandwidth and CPU. Because subscription state is usually read at init or refreshed on command, subtle edits can persist across reboots or take effect at predictable times. Similar effects appear in legacy MIL-STD-1553 deployments by modifying Remote Terminal (RT), subaddress, or mode-code configurations so that messages are misaddressed or dropped at the bus interface. The net result is control-by-misdirection: the software still “works,” but the right data no longer reaches the right recipient at the right time. | |
| EX-0012.05 | Scheduling Algorithm | Spacecraft typically rely on real-time scheduling, fixed-priority or deadline/periodic schemes, driven by timers, tick sources, and per-task parameters. Threat actors target these parameters and associated tables to skew execution order and timing. Edits may change priorities, periods, or deadlines; adjust CPU budgets and watchdog thresholds; alter ready-queue disciplines; or reconfigure timer tick rates and clock sources. They may also modify task affinities, message-queue depths, and interrupt masks so preemption and latency characteristics shift. Small changes can have large effects: high-rate control loops see added jitter, estimator updates miss deadlines, command/telemetry handling starves, or low-priority maintenance tasks monopolize cores due to mis-set periods. Manipulated schedules can create intermittent, state-dependent malfunctions that are hard to distinguish from environmental load. The essence of the technique is to weaponize time, reshaping when work happens so that otherwise correct code produces unsafe or exploitable behavior. | |
| EX-0012.06 | Science/Payload Data | Payload data, and the metadata that gives it meaning, can be altered in place to steal value, mislead users, or degrade mission outputs. Targets include raw detector frames, packetized Level-0 streams, onboard preprocessed products, and file catalogs/directories on mass memory. Adjacent metadata such as timestamps, pointing/attitude tags, calibration coefficients, compression settings, and quality flags are equally potent; slight bias in a calibration table or time tag can skew entire downlink campaigns while appearing routine. An adversary may rewrite frame headers, reorder packets, substitute segments from prior passes, or flip quality bits so ground pipelines silently discard or misclassify products. Recorder index manipulation can orphan files or cause downlinks to serve stale or fabricated content. Because many missions perform some processing or filtering onboard, tampering upstream of downlink propagates forward as “authoritative” truth, jeopardizing mission objectives without obvious protocol anomalies. | |
| EX-0012.07 | Propulsion Subsystem | Propulsion relies on parameters and sensed values that govern burns, pressure management, and safing. Editable items include thruster calibration and minimum impulse bit, valve timing and duty limits, inhibit masks, delta-V tables, plume keep-out constraints, tank pressure/temperature thresholds, leak-detection limits, and momentum-management coupling with attitude control. By modifying these, an adversary can provoke over-correction, waste propellant through repeated trims, bias orbit maintenance, or trigger protective sequences at inopportune times. False pressure or temperature readings can cause autonomous venting or lockouts; tweaked alignment matrices or misapplied gimbal limits can yield off-axis thrust and attitude excursions; altered desaturation rules can induce frequent wheel unloads that sap resources. Because consumables are finite and margins tight, even modest parameter drift can shorten mission life or violate keep-out and conjunction constraints while presenting as “normal” control activity. | |
| EX-0012.08 | Attitude Determination & Control Subsystem | ADCS depends on tightly coupled models and parameters: star-tracker catalogs and masks, sensor alignments and bias terms, gyro scale factors and drift rates, estimator covariances and process/measurement noise, controller gains and saturation limits, wheel/CMG torque constants, magnetic torquer maps, and sun sensor thresholds. Editing these values skews estimation or control, producing slow bias, limit cycles, loss of lock, or abrupt safing triggers. For example, a small change to a star-tracker mask can force frequent dropouts; an inflated gyro bias drives the filter away from truth; softened actuator limits or mis-set gains let disturbances accumulate; altered sun-point entry criteria cause unnecessary mode switches. Secondary impacts propagate to power, thermal, and communications because pointing and geometry underpin array generation, radiator view factors, and antenna gain. The technique turns the spacecraft against itself by nudging the parameters that close the loop between what the vehicle believes and how it responds. | |
| EX-0012.09 | Electrical Power Subsystem | Adversaries alter parameters and sensed values that govern power generation, storage, and distribution so the spacecraft draws or allocates energy in harmful ways. Editable items include bus voltage/current limits, MPPT setpoints and sweep behavior, array and SADA modes, battery charge/discharge thresholds and temperature derates, state-of-charge estimation constants, latching current limiter (LCL) trip/retry settings, load-shed priorities, heater duty limits, and survival/keep-alive rules. By changing these, a threat actor can drive excess consumption (e.g., disabling load shed, raising heater floors), misreport remaining energy (skewed SoC), or push batteries outside healthy ranges, producing brownouts, repeated safing, or premature capacity loss. Manipulating thresholds and hysteresis can also create oscillations where loads repeatedly drop and re-engage, wasting energy and stressing components. The effect is accelerated depletion or misallocation of finite power, degrading mission operations and potentially preventing recovery after eclipse or anomalies. | |
| EX-0012.10 | Command & Data Handling Subsystem | C&DH relies on tables and runtime values that define how commands are parsed, queued, and dispatched and how telemetry is collected, stored, and forwarded. Targets include opcode-to-handler maps, argument limits and schemas, queue depths and priorities, message ID routing, publish/subscribe bindings, timeline/schedule entries, file catalog indices, compression and packetization settings, and event/telemetry filters. Edits to these artifacts reshape control and visibility: commands are delayed, dropped, or misrouted; telemetry is suppressed or redirected; timelines slip; and housekeeping/data products are repackaged in ways that confuse ground processing. Because many frameworks treat these values as authoritative configuration, small changes can silently propagate across subsystems, degrading responsiveness, creating backlogs, or severing the logical pathways that keep the vehicle coordinated, without modifying the underlying code. | |
| EX-0012.11 | Watchdog Timer (WDT) | Watchdogs supervise liveness by requiring software to “pet” within defined windows or the system resets. Threat actors manipulate WDT behavior by changing timeout durations, windowed-WDT bounds, reset actions, enable/mask bits, or the source that performs the petting (e.g., moving it into a low-level ISR so higher layers can be stalled indefinitely). Software WDTs can be disabled or starved; hardware WDTs are influenced via control registers, strap pins, or supervisor commands that alter prescalers and reset ladders. Outcomes include preventing intended resets so runaway tasks consume power and bandwidth, or forcing repeated resets at tactically chosen moments, e.g., during updates or handovers, to keep the system in a degraded or easily predictable state. The technique converts a safety mechanism into a tool for either unbounded execution or rhythmic disruption, depending on how the WDT parameters are rewritten. | |
| EX-0012.12 | System Clock | Spacecraft maintain multiple time bases and distribute time to schedule sequences, validate timetags, manage anti-replay counters, and align navigation/attitude processing. By writing to clock registers, altering time-distribution services, switching disciplining sources, or biasing oscillator parameters, an adversary can skew these references. Effects include reordering or prematurely firing stored command sequences, invalidating timetag checks, desynchronizing counters used by authentication or ranging, misaligning estimator windows, and corrupting timestamped payload data. Even small offsets can accumulate into observable misbehavior when autonomy and scheduling depend on tight temporal guarantees. The result is execution that happens at the wrong moment, or not at all, because the system’s notion of “now” has been shifted. | |
| 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. | |
| EX-0013 | Flooding | Flooding overwhelms a communication or processing path by injecting traffic at rates or patterns the system cannot comfortably absorb. In space contexts this can occur across layers: RF/optical links (continuous carriers, wideband noise, or protocol-shaped bursts); link/protocol layers (valid-looking frames at excessive cadence); application layers (command and telemetry messages that saturate parsers and queues); and internal vehicles buses where repeated messages starve critical publishers. Effects range from outright denial of service, dropped commands, lost telemetry, missed windows, to subtler corruption, such as out-of-order processing, watchdog trips, or autonomy entering protective modes due to backlogged health data. Secondary impacts include power and thermal strain as decoders, modems, or software loops spin at maximum duty, storage filling from retries, and control loops jittering when their messages are delayed. Timing matters: floods during handovers, maneuvers, or safing transitions can magnify consequences because margins are thinnest. | |
| EX-0013.01 | Valid Commands | Here the adversary saturates paths with legitimate telecommands or bus messages so the spacecraft burns scarce resources honoring them. Inputs may be innocuous (no-ops, time queries, telemetry requests) or low-risk configuration edits, but at scale they consume command handler cycles, fill queues, generate events and logs, trigger acknowledgments, and provoke downstream work in subsystems (e.g., repeated state reports, mode toggles, or file listings). On internal buses, valid actuator or housekeeping messages replayed at high rate can starve higher-priority publishers or cause control laws to chase stale stimuli. Because the traffic is syntactically correct, and often contextually plausible, the system attempts to process it rather than discard it early, increasing CPU usage, memory pressure, and power draw. Consequences include delayed or preempted legitimate operations, transient loss of commandability, and knock-on FDIR activity as deadlines slip and telemetry appears inconsistent. | |
| EX-0013.02 | Erroneous Input | In this variant, the attacker injects non-useful energy or data, noise, malformed frames, or near-valid messages, so receivers and parsers labor to acquire, decode, and reject it. At the RF layer, wideband or protocol-shaped interference drives AGC and clock recovery to hunt, elevates BER, and forces repeated acquisitions; at the link layer, frames with correct preambles but bad CRCs keep decoders busy while yielding no payload; at the application layer, malformed packets force parse/validate/deny cycles that still consume CPU and fill error logs. On internal buses, collisions or bursts of misaddressed traffic reduce effective bandwidth and reorder legitimate messages. Even though little of the injected content passes semantic checks, the effort of dealing with it crowds out real work and may trigger retransmission storms or fallback modes that further increase load. The hallmark is volumetric invalid activity, crafted to engage front ends and parsers just long enough, that degrades integrity and availability without relying on privileged or authenticated commands. | |
| EX-0014 | Spoofing | The adversary forges inputs that subsystems treat as trustworthy truth, time tags, sensor measurements, bus messages, or navigation signals, so onboard logic acts on fabricated reality. Because many control loops and autonomy rules assume data authenticity once it passes basic sanity checks, carefully shaped spoofs can trigger mode transitions, safing, actuator commands, or payload behaviors without touching flight code. Spoofing may occur over RF (e.g., GNSS, crosslinks, TT&C beacons), over internal networks/buses (message injection with valid identifiers), or at sensor/actuator interfaces (electrical/optical stimulation that produces plausible readings). Effects range from subtle bias (drifting estimates, skewed calibrations) to acute events (unexpected slews, power reconfiguration, recorder re-indexing), and can also pollute downlinked telemetry or science products so ground controllers interpret a false narrative. The hallmark is that the spacecraft chooses the adversary’s action path because the forged data passes through normal processing chains. | |
| EX-0014.01 | Time Spoof | Time underpins sequencing, anti-replay, navigation filtering, and data labeling. An attacker that forges or biases the time seen by onboard consumers can reorder stored command execution, break timetag validation, desynchronize counters, and misalign estimation windows. Spoofing vectors include manipulating the distributed time service, introducing a higher-priority/cleaner time source (e.g., GNSS-derived time), or crafting messages that cause clock discipline to slew toward attacker-chosen values. Once time shifts, autonomous routines keyed to epochs, wheel unloads, downlink starts, heater schedules, fire early/late or not at all, and telemetry appears inconsistent to ground analysis. The signature is correct-looking time metadata that steadily or abruptly departs from truth, driving downstream logic to act at the wrong moment. | |
| EX-0014.02 | Bus Traffic Spoofing | Here the adversary forges messages on internal command/data paths (e.g., 1553, SpaceWire, CAN, custom). By emitting frames with valid identifiers, addresses, and timing, the attacker can make subscribers accept actuator setpoints, power switch toggles, mode changes, or housekeeping values that originated off-path. Because many consumers act on “latest value wins” or on message cadence, forged traffic can mask real publishers, starve critical topics, or force handlers to execute unintended branches. Gateways that translate between networks amplify impact: a spoofed message on one side can propagate to multiple domains as legitimate payload. Outcomes include misdelivered commands, silent configuration drift, and control loops chasing phantom stimuli, all while bus monitors show protocol-conformant traffic. In architectures where component identity is derived solely from message identifiers, an adversary may suppress the genuine component and fully assume its identity by publishing under the same identifiers at the expected cadence. This sustained impersonation differs from transient injection because the attacker becomes the sole authoritative source for that subsystem's telemetry, housekeeping, and command responses, while ground systems that rely on message-ID-based attribution cannot distinguish spoofed output from legitimate data. Internal suppression commands remain invisible in ground logs, making the replacement potentially forensically undetectable. | |
| EX-0014.03 | Sensor Data | The attacker presents fabricated or biased measurements that estimation and control treat as ground truth. Targets include attitude/position sensors (star trackers, gyros/IMUs, sun sensors, magnetometers, GNSS), environmental and health sensors (temperatures, currents, voltages, pressures), and payload measurements used in autonomy. Spoofs may be injected electrically at interfaces, optically (blinding/dazzling trackers or sun sensors), magnetically, or by crafting packets fed into sensor gateways. Even small, consistent biases can drive filters to incorrect states; stepwise changes can trigger fault responses or mode switches. Downstream, timestamps, quality flags, and derived products inherit the deception, creating uncertainty for operators and potentially inducing temporary loss of service as autonomy reacts to a world that never existed. | |
| EX-0014.04 | Position, Navigation, and Timing (PNT) Spoofing | The adversary transmits GNSS-like signals (or manipulates crosslink-distributed time/ephemeris) so the spacecraft’s navigation solution reflects attacker-chosen states. With believable code phases, Doppler, and navigation messages, the victim can be pulled to a false position/velocity/time, causing downstream functions, attitude pointing limits, station visibility prediction, eclipse timing, antenna pointing, and anti-replay windows, to misbehave. Even when GNSS is not the primary navigation source, spoofed PNT can bias timekeeping or seed filters that fuse multiple sensors, leading to mis-scheduling and errant control. The defining feature is externally provided navigation/time that passes validity checks yet encodes a crafted trajectory or epoch. | |
| EX-0014.05 | Ballistic Missile Spoof | In this variant, attackers deploy decoys or emitters designed to mimic ballistic-missile signatures so early-warning and missile-defense systems allocate interceptors and attention to false targets. Decoys can shape radar cross-section and thermal profiles, stage deployment to simulate staging events, or use cooling/heating to emulate plume and body signatures, while coordinated timing and trajectories reinforce plausibility. The objective is resource depletion and distraction: saturate tracking, cueing, and discrimination so defenses are preoccupied prior to an actual strike or are left with reduced capacity afterward. Although the immediate target is the defense architecture, space-based sensors and their ground processing are integral to the effect; spoofed scenes enter the normal detection and tracking pipelines and propagate as authoritative truth until later discrimination overturns them. | |
| EX-0015 | Side-Channel Attack | Adversaries extract secrets or steer execution by observing or perturbing physical byproducts of computation rather than the intended interfaces. Passive channels include timing, power draw, electromagnetic emissions, acoustic/optical leakage, and thermal patterns correlated with operations such as key use, counter updates, or parser activity. Active channels deliberately induce faults during runtime, e.g., voltage or clock glitches, electromagnetic/laser injection, or targeted radiation, to flip bits, skip checks, or bias intermediate values. On spacecraft, prime targets include crypto modules, SDR/FPGA pipelines, bootloaders, and bus controllers whose switching behavior or error handling reveals protocol state or key material. With sufficient samples, or with repeated fault attempts, statistical features emerge that reduce entropy of the sensitive variable under study; in effect, a successful fault campaign turns into information leakage comparable to a passive side channel. Collection vantage points range from on-orbit proximity (for EM/optical), to ATLO and ground test (for direct probing), to instrumented compromised hardware already in the signal path. | |
| EX-0016 | Jamming | Jamming is an electronic attack that uses radio frequency energy to deny the use of a signal, whether that signal carries communications, navigation, or timing. A jammer must operate in the same frequency band and within the field of view of the antenna it is targeting. Unlike physical attacks, the interference itself is completely reversible: once the jammer is disengaged, reception can be restored. Second-order effects may persist, however, where the outage has already caused a clock to drift, a schedule to slip, or a synchronization state to be lost. Attribution of jamming can be tough because the source can be small and highly mobile, and users operating on the wrong frequency or pointed at the wrong satellite can jam friendly communications.* Similar to intentional jamming, accidental jamming can cause temporary signal degradation. Accidental jamming refers to unintentional interference with communication signals, and it can potentially impact spacecraft in various ways, depending on the severity, frequency, and duration of the interference. *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0016.01 | Uplink Jamming | The attacker transmits toward the spacecraft’s uplink receive antenna, within its main lobe or significant sidelobes, at the operating frequency and sufficient power spectral density to drive the uplink Eb/N₀ below the demodulator’s threshold. Uplink jamming prevents acceptance of telecommands and ranging/acquisition traffic, delaying or blocking scheduled operations. Because the receiver resides on the spacecraft, the jammer must be located within the spacecraft’s receive footprint and match its polarization and Doppler conditions well enough to couple energy into the front end. | |
| EX-0016.02 | Downlink Jamming | Downlink jammers target the users of a satellite by creating noise in the same frequency as the downlink signal from the satellite. A downlink jammer only needs to be as powerful as the signal being received on the ground and must be within the field of view of the receiving terminal’s antenna. This limits the number of users that can be affected by a single jammer. Since many ground terminals use directional antennas pointed at the sky, a downlink jammer typically needs to be located above the terminal it is attempting to jam. This limitation can be overcome by employing a downlink jammer on an air or space-based platform, which positions the jammer between the terminal and the satellite. This also allows the jammer to cover a wider area and potentially affect more users. Ground terminals with omnidirectional antennas, such as many GPS receivers, have a wider field of view and thus are more susceptible to downlink jamming from different angles on the ground.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0016.03 | Position, Navigation, and Timing (PNT) Jamming | The attacker raises the noise floor in GNSS bands so satellite navigation signals are not acquired or tracked. Loss of PNT manifests as degraded or unavailable position/velocity/time solutions, which in turn disrupts functions that depend on them, time distribution, attitude aiding, scheduling, anti-replay windows, and visibility prediction. Because GNSS signals at the receiver are extremely weak, modest jammers within the antenna field of view can produce outsized effects; mobile emitters can create intermittent outages aligned with the attacker’s objectives. | |
| EX-0017 | Kinetic Physical Attack | The adversary inflicts damage by physically striking space assets or their supporting elements, producing irreversible effects that are generally visible to space situational awareness. Kinetic attacks in orbit are commonly grouped into direct-ascent engagements, launched from Earth to intercept a target on a specific pass, and co-orbital engagements, in which an on-orbit vehicle maneuvers to collide with or detonate near the target. Outcomes include structural breakup, loss of attitude control, sensor or antenna destruction, and wholesale mission termination; secondary effects include debris creation whose persistence depends on altitude and geometry. Because launches and on-orbit collisions are measurable, these actions tend to be more attributable and offer near–real-time confirmation of effect compared to non-kinetic methods. | |
| EX-0017.01 | Direct Ascent ASAT | A direct-ascent ASAT is often the most commonly thought of threat to space assets. It typically involves a medium- or long-range missile launching from the Earth to damage or destroy a satellite in orbit. This form of attack is often easily attributed due to the missile launch which can be easily detected. Due to the physical nature of the attacks, they are irreversible and provide the attacker with near real-time confirmation of success. Direct-ascent ASATs create orbital debris which can be harmful to other objects in orbit. Lower altitudes allow for more debris to burn up in the atmosphere, while attacks at higher altitudes result in more debris remaining in orbit, potentially damaging other spacecraft in orbit.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0017.02 | Co-Orbital ASAT | A co-orbital ASAT uses a spacecraft already in space to conduct a deliberate collision or near-field detonation. After insertion, often well before any hostile action, the vehicle performs rendezvous and proximity operations to achieve the desired relative geometry, then closes to impact or triggers a kinetic or explosive device. Guidance relies on relative navigation (optical, lidar, crosslink cues) and precise timing to manage closing speeds and contact angle. Compared with direct-ascent shots, co-orbital approaches can loiter, shadow, or “stalk” a target for extended periods, masking as inspection or servicing until the terminal maneuver. Effects include mechanical disruption, fragmentation, or mission-ending damage, with debris characteristics shaped by the chosen altitude, closing velocity, and collision geometry. | |
| EX-0018 | Non-Kinetic Physical Attack | The adversary inflicts physical effects on a satellite without mechanical contact, using energy delivered through the environment. Principal modalities are electromagnetic pulse (EMP), high-power laser (optical/thermal effects), and high-power microwave (HPM). These methods can be tuned for reversible disruption (temporary sensor saturation, processor upsets) or irreversible damage (component burnout, optics degradation), and may be executed from ground, airborne, or space platforms given line-of-sight and power/aperture conditions. Forensics are often ambiguous: signatures may resemble environmental phenomena or normal degradations, and confirmation of effect is frequently limited to what the operator observes in telemetry or performance loss. | |
| EX-0018.01 | Electromagnetic Pulse (EMP) | An EMP delivers a broadband, high-amplitude electromagnetic transient that couples into spacecraft electronics and harnesses, upsetting or damaging components over wide areas. In space, the archetype is a high-altitude nuclear event whose prompt fields induce immediate upsets and whose secondary radiation environment elevates dose and charging for an extended period along affected orbits. Consequences include widespread single-event effects, latch-ups, permanent degradation of sensitive devices, and accelerated aging of solar arrays and materials. The effect envelope is large and largely indiscriminate: multiple satellites within view can experience simultaneous anomalies consistent with intense electromagnetic stress and enhanced radiation. | |
| EX-0018.02 | High-Powered Laser | A high-powered laser can be used to permanently or temporarily damage critical satellite components (i.e. solar arrays or optical centers). If directed toward a satellite’s optical center, the attack is known as blinding or dazzling. Blinding, as the name suggests, causes permanent damage to the optics of a satellite. Dazzling causes temporary loss of sight for the satellite. While there is clear attribution of the location of the laser at the time of the attack, the lasers used in these attacks may be mobile, which can make attribution to a specific actor more difficult because the attacker does not have to be in their own nation, or even continent, to conduct such an attack. Only the satellite operator will know if the attack is successful, meaning the attacker has limited confirmation of success, as an attacked nation may not choose to announce that their satellite has been attacked or left vulnerable for strategic reasons. A high-powered laser attack can also leave the targeted satellite disabled and uncontrollable, which could lead to collateral damage if the satellite begins to drift. A higher-powered laser may permanently damage a satellite by overheating its parts. The parts most susceptible to this are satellite structures, thermal control panels, and solar panels.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0018.03 | High-Powered Microwave | High-powered microwave (HPM) weapons can be used to disrupt or destroy a satellite’s electronics. A “front-door” HPM attack uses a satellite’s own antennas as an entry path, while a “back-door” attack attempts to enter through small seams or gaps around electrical connections and shielding. A front-door attack is more straightforward to carry out, provided the HPM is positioned within the field of view of the antenna that it is using as a pathway, but it can be thwarted if the satellite uses circuits designed to detect and block surges of energy entering through the antenna. In contrast, a back-door attack is more challenging, because it must exploit design or manufacturing flaws, but it can be conducted from many angles relative to the satellite. Both types of attacks can be either reversible or irreversible; however, the attacker may not be able to control the severity of the damage from the attack. Both front-door and back-door HPM attacks can be difficult to attribute to an attacker, and like a laser weapon, the attacker may not know if the attack has been successful. A HPM attack may leave the target satellite disabled and uncontrollable which can cause it to drift into other satellites, creating further collateral damage.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| 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. | |
| PER-0004 | Replace Cryptographic Keys | The adversary cements control by changing the cryptographic material the spacecraft uses to authenticate or protect links and updates. Targets include uplink authentication keys and counters, link-encryption/session keys and key-encryption keys (KEKs), key identifiers/selectors, and algorithm profiles. Using authorized rekey commands or key-loading procedures, often designed for over-the-air use, the attacker installs new values in non-volatile storage and updates selectors so subsequent traffic must use the attacker’s keys to be accepted. Variants desynchronize anti-replay by advancing counters or switching epochs, or strand operators by flipping profiles to a mode for which only the adversary holds parameters. Once replaced, the new material persists across resets and mode changes, turning the spacecraft into a node that recognizes the adversary’s channel while rejecting former controllers. | |
| PER-0005 | Credentialed Persistence | Threat actors may acquire or leverage valid credentials to maintain persistent access to a spacecraft or its supporting command and control (C2) systems. These credentials may include system service accounts, user accounts, maintenance access credentials, cryptographic keys, or other authentication mechanisms that enable continued entry without triggering access alarms. By operating with legitimate credentials, adversaries can sustain access over extended periods, evade detection, and facilitate follow-on tactics such as command execution, data exfiltration, or lateral movement. Credentialed persistence is particularly effective in environments lacking strong credential lifecycle management, segmentation, or monitoring allowing threat actors to exploit trusted pathways while remaining embedded in mission operations. | |
| DE-0001 | Disable Fault Management | The adversary suppresses or alters fault detection, isolation, and recovery (FDIR) so unauthorized actions proceed without triggering safing or alerts. Targets include watchdogs and heartbeat monitors; limit and sanity checks on sensor/command values; command interlocks and inhibit masks; voting and redundancy-management logic; and event/alert generation and routing. Techniques range from patching or bypassing checks in flight code, to rewriting parameter/limit tables, to muting publishers that report faults. More subtle variants desensitize thresholds, freeze counters, or delay responses just long enough for a malicious sequence to complete. With FDIR dulled or offline, anomalous states resemble nominal behavior and automated mitigations do not engage, masking the attack from ground oversight. | |
| DE-0002 | Disrupt or Deceive Downlink | Threat actors may target any point in the telemetry chain, onboard generation and transmission, the downlink path itself, or ground-side reception, processing, and display, to disrupt the operator’s visibility into spacecraft health and activity. This may involve denial-based attacks that prevent the spacecraft from transmitting telemetry to the ground (e.g., disabling telemetry links or crashing telemetry software), or more subtle deception-based attacks that manipulate telemetry content to conceal unauthorized actions. Since telemetry is the primary method ground controllers rely on to monitor spacecraft status, any disruption or manipulation can delay or prevent detection of malicious activity, suppress automated or manual mitigations, or degrade trust in telemetry-based decision support systems. | |
| DE-0002.01 | Inhibit Ground System Functionality | Threat actors may utilize access to the ground system to inhibit its ability to accurately process, render, or interpret spacecraft telemetry, effectively leaving ground controllers unaware of the spacecraft’s true state or activity. This may involve traditional denial-based techniques, such as disabling telemetry software, corrupting processing pipelines, or crashing display interfaces. In addition, more subtle deception-based techniques may be used to falsify telemetry data within the ground system , such as modifying command counters, acknowledgments, housekeeping data, or sensor outputs , to provide the appearance of nominal operation. These actions can suppress alerts, mask unauthorized activity, or prevent both automated and manual mitigations from being initiated based on misleading ground-side information. Because telemetry is the primary method by which ground controllers monitor the health, behavior, and safety of the spacecraft, any disruption or falsification of this data directly undermines situational awareness and operational control. Architectural limitations in ground station software can also enable deception without requiring direct compromise of the ground system. In publish-subscribe spacecraft architectures, ground tools typically attribute telemetry solely by Message ID rather than by producing application. This design assumes that Message IDs reliably identify the originating component. When a malicious onboard application publishes telemetry under a legitimate subsystem's Message ID, ground logs permanently record the spoofed data as genuine with no indication of the true source. Similarly, internal spacecraft bus commands may not be downlinked or logged by ground systems, rendering suppression events forensically invisible. This attribution gap allows onboard component impersonation to succeed without any ground system compromise: the ground infrastructure functions as designed, yet cannot distinguish authentic telemetry from architecturally valid spoofing. | |
| DE-0002.03 | Inhibit Spacecraft Functionality | In this variant, telemetry is suppressed at the source by manipulating on-board generation or transmission. Methods include disabling or pausing telemetry publishers, altering packet filters and rates, muting event/report channels, reconfiguring recorder playback, retuning/muting transmitters, or switching to modes that emit only minimal beacons. The spacecraft continues operating, but the downlink no longer reflects true activity or arrives too sparsely to support monitoring. By constraining what is produced or transmitted, the adversary reduces opportunities for detection while other actions proceed. | |
| 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.01 | Vehicle Command Counter (VCC) | The VCC tracks how many commands the spacecraft has accepted. An adversary masks activity by zeroing, freezing, or selectively decrementing the VCC, or by steering actions through paths that do not increment it (maintenance dictionaries, alternate receivers, hidden handlers). They may also overwrite the telemetry field that reports the VCC so ground displays show a lower or steady count while high volumes of commands are processed. This breaks simple “command volume” heuristics and makes bursty activity look normal. | |
| DE-0003.02 | Rejected Command Counter | This counter records commands that failed checks or were refused. To hide probing and trial-and-error, the adversary suppresses increments, periodically clears the value, or forges the downlinked field so rejection rates appear benign. Variants also tamper with associated reason codes or event entries, replacing them with innocuous outcomes. Analysts reviewing telemetry see no evidence of failed attempts even as the system is being exercised aggressively. | |
| DE-0003.03 | Command Receiver On/Off Mode | By toggling receiver enable states (per-receiver, per-antenna, or per-band), the adversary creates deliberate “quiet windows” in which outside intervention cannot arrive. Turning a command receiver off, or shifting to a configuration that ignores the primary path, allows queued actions or onboard procedures to run without interruption, while operators perceive a transient loss of commandability consistent with geometry or environment. Brief, well-timed toggles can also desynchronize counters and handovers, complicating reconstruction of what occurred. | |
| DE-0003.04 | Command Receivers Received Signal Strength | Threat actors may target the on-board command receivers received signal parameters (i.e., automatic gain control (AGC)) in order to stop specific commands or signals from being processed by the spacecraft. For ground controllers to communicate with spacecraft in orbit, the on-board receivers need to be configured to receive signals with a specific signal to noise ratio (ratio of signal power to the noise power). Targeting values related to the antenna signaling that are modifiable can prevent the spacecraft from receiving ground commands. | |
| DE-0003.05 | Command Receiver Lock Modes | Receivers advertise acquisition states, bit lock, frame lock, and command lock, that indicate readiness to accept telecommands. Adversaries leverage these indicators in two ways: (1) use command-lock tests to validate geometry, power, Doppler, and polarization without risking visible command execution; and (2) tamper with the values that report lock status so ground views never show that lock was achieved. Techniques include freezing or clearing lock flags and counters, raising/lowering internal thresholds so lock occurs without being reported (or vice versa), and timing brief lock intervals between telemetry samples. The result is a window where the spacecraft is receptive to commands while downlinked status suggests otherwise. | |
| DE-0003.06 | Telemetry Downlink Modes | Spacecraft expose modes that control what telemetry is sent and how, real-time channels, recorder playback, beacon/summary only, event-driven reporting, and per-virtual-channel/APID selections. By switching modes or editing the associated parameters (rates, filters, playback queues, index ranges), an adversary can thin, defer, or reroute observability. Typical effects include suppressing high-rate engineering streams in favor of minimal beacons, delaying playback of time periods of interest, replaying benign segments, or redirecting packets to alternate virtual channels that are not routinely monitored. Telemetry continues to flow, but it no longer reflects the activity the operators need to see. | |
| DE-0003.07 | Cryptographic Modes | Many missions separate authentication from confidentiality and allow on-orbit selection of algorithms, keys, profiles, or “crypto off/clear” states. Adversaries manipulate these mode controls and selectors to desynchronize ground and space or to hide content: flipping to a profile that the ground is not using, requesting clear telemetry while maintaining authenticated uplink, or rotating key IDs so frames validate internally but appear undecodable to external tools. Mode indicators and status words can also be biased so ground displays show expected settings while the link actually operates under attacker-chosen parameters, masking command and data exchanges within normal-looking traffic. | |
| DE-0003.08 | Received Commands | Spacecraft typically maintain histories of accepted, rejected, and executed commands, buffers, logs, or file records that can be downlinked on demand or periodically. An adversary conceals activity by editing or pruning these artifacts: removing entries, altering opcodes or arguments, rewriting timestamps and source identifiers, rolling logs early, or repopulating with benign-looking commands to balance counters. Related acknowledgments and event records may be suppressed or reclassified so cross-checks appear consistent. After manipulation, the official command history shows a plausible narrative that omits or mischaracterizes the adversary’s actions. | |
| DE-0003.09 | System Clock for Evasion | The adversary biases the spacecraft’s authoritative time so that telemetry, event logs, and command histories appear shifted or inconsistent. By writing clock registers, altering disciplining sources (e.g., GNSS vs. free-running oscillator), or tweaking distribution services and offsets, they can make stored commands execute “earlier” or “later” on the timeline and misalign acknowledgments with actual actions. Downlinked frames still carry plausible timestamps near packet headers, but those stamps no longer reflect when data was produced, complicating reconstruction of sequences and masking causality during incident analysis. | |
| DE-0003.10 | GPS Ephemeris | A satellite with a GPS receiver can use ephemeris data from GPS satellites to estimate its own position in space. A hostile actor could spoof the GPS signals to cause erroneous calculations of the satellite’s position. The received ephemeris data is often telemetered and can be monitored for indications of GPS spoofing. Reception of ephemeris data that changes suddenly without a reasonable explanation (such as a known GPS satellite handoff), could provide an indication of GPS spoofing and warrant further analysis. Threat actors could also change the course of the vehicle and falsify the telemetered data to temporarily convince ground operators the vehicle is still on a proper course. | |
| DE-0003.11 | Watchdog Timer (WDT) for Evasion | By modifying watchdog parameters or who “pets” them, an adversary shapes what evidence survives. Extending or disabling timeouts allows long-running processes to operate without forced resets that would expose abnormal CPU or power usage; conversely, shortening windows or relocating the petting source to a low-level ISR can induce frequent resets that wipe volatile traces, break correlation in logs, and explain anomalies as “spurious reboots.” In both directions, the watchdog becomes a timing tool for hiding activity rather than a guardrail against it. | |
| 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-0003.13 | Trusted Process Reporting Suppression | Adversaries may leverage process injection methods to execute malicious functionality within trusted onboard software processes in order to suppress, delay, filter, or selectively conceal telemetry and operational reporting associated with unauthorized activity. By operating inside legitimate telemetry handlers, flight software tasks, middleware, or operating system services, attackers can interfere with the generation, aggregation, or transmission of monitoring data before it is downlinked or processed by onboard monitoring systems. Unlike direct modification of individual operational values, this technique focuses on manipulating the reporting path itself to prevent malicious activity from being observed, correlated, or reconstructed by operators or autonomy systems. Examples may include suppressing telemetry associated with unauthorized commands, filtering fault events prior to downlink, selectively disabling event reporting during malicious operations, delaying housekeeping updates, or preventing monitoring services from publishing anomalous state information. | |
| DE-0004 | Masquerading | The adversary presents themselves as an authorized origin so activity appears legitimate across RF, protocol, and organizational boundaries. Techniques include crafting telecommand frames with correct headers, counters, and dictionaries; imitating station “fingerprints” such as Doppler, polarization, timing, and framing; replaying or emulating crosslink identities; and using insider-derived credentials or roles to operate mission tooling. Masquerading can also target metadata, virtual channel IDs, APIDs, source sequence counts, and facility identifiers, so logs and telemetry attribute actions to expected entities. The effect is that commands, file transfers, or configuration changes are processed as if they came from approved sources, reducing scrutiny and delaying detection. | |
| DE-0005 | Subvert Protections via Safe-Mode | The adversary exploits the spacecraft’s recovery posture to bypass controls that are stricter in nominal operations. During safe-mode, vehicles often accept contingency dictionaries, relax rate/size and timetag checks, activate alternate receivers or antennas, and emit reduced or summary telemetry. By timing actions to this state, or deliberately inducing it, the attacker issues maintenance-looking edits, loads, or mode changes that proceed under broadened acceptance while downlink visibility is thinned. Unauthorized activity blends with anomaly response, evading both automated safeguards and operator suspicion. | |
| DE-0006 | Modify Whitelist | Threat actors may target whitelists on the spacecrafts as a means to execute and/or hide malicious processes/programs. Whitelisting is a common technique used on traditional IT systems but has also been used on spacecrafts. Whitelisting is used to prevent execution of unknown or potentially malicious software. However, this technique can be bypassed if not implemented correctly but threat actors may also simply attempt to modify the whitelist outright to ensure their malicious software will operate on the spacecraft that utilizes whitelisting. | |
| 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-0009 | Camouflage, Concealment, and Decoys (CCD) | The adversary exploits the physical and operational environment, or manipulates the sensing and processing on which observers depend, to reduce detectability, mislead, or provoke a response. Tactics include signature management (minimizing RF/optical/thermal/RCS), controlled emissions timing, deliberate power-down/dormancy, geometry choices that hide within clutter or eclipse, and the deployment of decoys that generate convincing tracks. CCD can also leverage naturally noisy conditions, debris-rich regions, auroral radio noise, solar storms, to mask proximity operations or to provide plausible alternate explanations for anomalies. The unifying theme is perception management: shape what sensors and their processing chains perceive so surveillance and attribution lag, misclassify, or look elsewhere. This may be achieved through the environment, through decoys and signatures presented to distant observers, or through deception directed at a particular vehicle’s onboard sensing or a particular ground processing pipeline. The same methods may be used to provoke a defender into committing limited resources prematurely. | |
| DE-0009.03 | Trigger Premature Intercept | Decoys and deceptive signatures are used to provoke defenders into committing limited resources early, inspection vehicles, interceptors, laser dwell time, maneuver fuel, or analyst attention. The attacker deploys objects or emissions that mimic credible threats (trajectories, RCS/brightness, modulation) so tracking and discrimination systems prioritize the decoy. While defenses engage, the true operation proceeds with reduced scrutiny, or follows shortly after when defensive capacity and timelines are depleted. The effect is resource exhaustion and timeline compression on the defender’s side, increasing the success window for the actual action. | |
| DE-0009.04 | Targeted Deception of Onboard SSA/SDA Sensors | The attacker aims at the spacecraft’s own proximity-awareness stack, cameras, star-tracker side products, lidar/radar, RF transponders, and the onboard fusion that estimates nearby objects. Methods include optical dazzling or reflective camouflage that confuses centroiding and detection, RCS management to fall below radar gate thresholds, intermittent or misleading transponder replies, and presentation of spoofed fiducials or optical patterns tuned to the vehicle’s detection algorithms. By biasing these local sensors and their fusion logic, the adversary hides approach, distorts relative-state estimates, or induces the target to classify a nearby object as benign clutter, masking proximity operations without relying on external catalog errors. | |
| DE-0009.05 | Corruption or Overload of Ground-Based SDA Systems | The adversary targets terrestrial space-domain awareness pipelines, sensor networks, tracking centers, catalogs, and their data flows, to blind or confuse broad-area monitoring. Paths include compromising or spoofing observational feeds (radar/optical returns, TLE updates, ephemeris exchanges), injecting falsified or time-shifted tracks, tampering with fusion/association parameters, and saturating ingestion and alerting with noisy or adversarial inputs. Where SDA employs AI/ML for detection and correlation, the attacker can degrade models by flooding them with ambiguous scenes or crafted features that increase false positives/negatives and consume analyst cycles. Unlike onboard deception, this approach skews the external decision-support picture across many assets at once, delaying detection of real maneuvers and providing cover for concurrent operations. | |
| DE-0010 | Overflow Audit Log | The adversary hides activity by exhausting finite on-board logging and telemetry buffers so incriminating events are overwritten before they can be downlinked. Spacecraft typically use ring buffers with severity filters, per-subsystem quotas, and scheduled dump windows; by generating bursts of benign but high-frequency events (file listings, status queries, low-severity housekeeping, repeated mode toggles) or by provoking chatter from chatty subsystems, the attacker accelerates rollover. Variants target recorder indexes and event catalogs so new entries displace older ones, or they align floods with known downlink gaps and pass handovers when retention is shortest. To analysts on the ground, logs appear present but incomplete, showing a plausible narrative that omits the very interval when unauthorized commands or updates occurred. | |
| DE-0011 | Credentialed Evasion | Threat actors may leverage valid credentials to conduct unauthorized actions against a spacecraft or related system in a way that conceals their presence and evades detection. By using trusted authentication mechanisms attackers can blend in with legitimate operations and avoid triggering access control alarms or anomaly detection systems. This technique enables evasion by appearing authorized, allowing adversaries to issue commands, access sensitive subsystems, or move laterally within spacecraft or constellation architectures without exploiting software vulnerabilities. When credential use is poorly segmented or monitored, this form of access can be used to maintain stealthy persistence or facilitate other tactics under the guise of legitimate activity. | |
| 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. | |
| LM-0002 | Exploit Lack of Bus Segregation | On flat architectures, where remote terminals, subsystems, and payloads share a common bus with minimal partitioning, any node that can transmit may influence many others. An attacker leverages this by forging message IDs or terminal addresses, replaying actuator/sensor frames, seizing or imitating bus-controller roles, or abusing gateway bridges that forward traffic between links (e.g., 1553↔SpaceWire/CAN). Because consumers often act on the latest valid-looking message, crafted traffic from one compromised device can reconfigure peers, toggle power domains, or write persistent parameters. Weak role enforcement and broadcast semantics allow privilege escalation from a peripheral to effective system-wide influence, turning the shared medium into a highway for further compromise. | |
| LM-0003 | Constellation Hopping via Crosslink | In networks where vehicles exchange data over inter-satellite links, a compromise on one spacecraft becomes a springboard to others. The attacker crafts crosslink traffic, routing updates, service advertisements, time/ephemeris distribution, file or tasking messages, that appears to originate from a trusted neighbor and targets gateway functions that bridge crosslink traffic into command/data paths. Once accepted, those messages can queue procedures, deliver configuration/table edits, or open file transfer sessions on adjacent vehicles. In mesh or hub-and-spoke constellations, this enables “hop-by-hop” spread: a single foothold uses shared trust and protocol uniformity to reach additional satellites without contacting the ground segment. | |
| LM-0004 | Visiting Vehicle Interface(s) | Docking, berthing, or short-duration attach events create high-trust, high-bandwidth connections between vehicles. During these operations, automatic sequences verify latches, exchange status, synchronize time, and enable umbilicals that carry data and power; maintenance tools may also push firmware or tables across the interface. An attacker positioned on the visiting vehicle can exploit these handshakes and service channels to inject commands, transfer files, or access bus gateways on the host. Because many actions are expected “just after dock,” malicious traffic can ride the same procedures that commission the interface, allowing lateral movement from the visiting craft into the target spacecraft’s C&DH, payload, or support subsystems. | |
| LM-0005 | Virtualization Escape | The adversary pivots across partitions by abusing the mechanisms a separation kernel or hypervisor exposes for inter-partition communication and device sharing. Paths include message ports/queues, shared-memory windows, virtual NICs and bridges, hypercalls, and common driver backends (e.g., storage or DMA engines without strict IOMMU bounds). A foothold in a less-trusted partition, often a payload or guest OS, can be turned into access to a higher-privilege domain by crafting traffic that exploits parser flaws in port services, racing management channels, or coercing backend drivers to perform out-of-bounds operations. Once the boundary is crossed, the actor can reach bus gateways, file systems, or control applications hosted in adjacent partitions and continue movement under the guise of permitted inter-partition exchanges. | |
| LM-0006 | Launch Vehicle Interface | During integration and ascent, payloads and the launch vehicle exchange power, discrete lines, and data via umbilicals, separation avionics, and shared EGSE networks. Protections can be reduced or heterogeneous because timelines are tight and responsibilities cross organizations. An attacker positioned on either side (vehicle or payload) can use these commissioning links, health/status queries, time distribution, inhibit lines, separation commands, or telemetry gateways, to inject messages, transfer files, or alter configuration that propagates across the interface. Before fairing close and prior to separation, this brief but high-trust coupling provides a route to move from one platform to the other and to seed artifacts that persist after deployment. | |
| LM-0006.01 | Rideshare Payload | In shared launches, multiple independent payloads cohabit common infrastructure until separation. If isolation is incomplete (e.g., shared data buses, mispartitioned deployer controllers, common logging/telemetry collectors, or cross-connected laptops and recorders), a compromise in one payload’s domain can be leveraged to observe or influence another’s traffic before release. Threat actors exploit these transient but real connections to read configuration, pivot through deployer control paths, or stage data/commands that execute as neighboring payloads power and check out, enabling cross-payload access or tampering prior to independent flight. | |
| LM-0007 | Credentialed Traversal | Movement is achieved by reusing legitimate credentials and keys to cross boundaries that rely on trust rather than strict isolation. Using operator or service accounts, maintenance logins, station certificates, or spacecraft-recognized crypto, the adversary invokes gateways that bridge domains, C&DH to payload, crosslink routers to onboard networks, or constellation management planes to individual vehicles. Because the traversal occurs through approved interfaces (file services, table loaders, remote procedure calls, crosslink tasking), actions appear as routine operations while reaching progressively more privileged subsystems or neighboring spacecraft. Where roles and scopes are broad or reused, the same credential opens multiple enclaves, turning authorization itself into the lateral path. | |
| EXF-0001 | Replay | The adversary re-sends previously valid commands or procedures to cause the spacecraft to transmit data again, then captures the resulting downlink. Typical targets are recorder playbacks, payload product dumps, housekeeping snapshots, or file directory listings. By aligning replays with geometry (e.g., when the satellite is in view of actor-controlled apertures) and with acceptance conditions (counters, timetags, mode), the attacker induces legitimate transmissions that appear routine to operators. Variants include selectively replaying index ranges to fetch only high-value intervals, reissuing subscription/telemetry-rate changes to increase data volume, or queueing playbacks that fire during later passes when interception is feasible. | |
| EXF-0002 | Side-Channel Exfiltration | Information is extracted not by reading files or decrypting frames but by observing physical or protocol byproducts of computation, power draw, electromagnetic emissions, timing, thermal signatures, or traffic patterns. Repeated measurements create distinctive fingerprints correlated with internal states (key use, table loads, parser branches, buffer occupancy). Matching those fingerprints to models or templates yields sensitive facts without direct access to the protected data. In space systems, vantage points span proximity assets (for EM/thermal), ground testing and ATLO (for direct probing), compromised on-board modules that can sample rails or sensors, and remote observation of link-layer timing behaviors. | |
| EXF-0002.01 | Power Analysis Attacks | The attacker infers secrets by measuring instantaneous power consumption of target devices, often crypto engines or controllers, and correlating traces with hypothesized internal operations. Simple power analysis (SPA) extracts structure (operation sequences, key-dependent branches); differential/correlation power analysis (DPA/CPA) uses many traces and statistics to recover key bits from tiny data-dependent variations. Practically, measurements may come from instrumented rails during I&T, from a compromised payload monitoring local supplies, or from co-located hardware that senses current/voltage fluctuations. With sufficient traces and alignment (triggering on command/crypto invocation), internal values become observable through their power signatures. | |
| EXF-0002.02 | Electromagnetic Leakage Attacks | Switching activity in chips, buses, and clocks radiates EM energy that can be captured and analyzed to reveal internal computation. Near-field probes (in test) or proximity receivers (on-orbit assets) can observe harmonics and modulation tied to cipher rounds, key schedules, or protocol framing, sometimes with finer granularity than power analysis. Coupling paths include packages, harnesses, SDR front ends, and poorly shielded enclosures. By training on known operations and comparing spectra or time-domain signatures, an adversary can recover keys or reconstruct processed data without touching logical interfaces. | |
| EXF-0002.03 | Traffic Analysis Attacks | In a terrestrial environment, threat actors use traffic analysis attacks to analyze traffic flow to gather topological information. This traffic flow can divulge information about critical nodes, such as the aggregator node in a sensor network. In the space environment, specifically with relays and constellations, traffic analysis can be used to understand the energy capacity of spacecraft node and the fact that the transceiver component of a spacecraft node consumes the most power. The spacecraft nodes in a constellation network limit the use of the transceiver to transmit or receive information either at a regulated time interval or only when an event has been detected. This generally results in an architecture comprising some aggregator spacecraft nodes within a constellation network. These spacecraft aggregator nodes are the sensor nodes whose primary purpose is to relay transmissions from nodes toward the ground station in an efficient manner, instead of monitoring events like a normal node. The added functionality of acting as a hub for information gathering and preprocessing before relaying makes aggregator nodes an attractive target to side channel attacks. A possible side channel attack could be as simple as monitoring the occurrences and duration of computing activities at an aggregator node. If a node is frequently in active states (instead of idle states), there is high probability that the node is an aggregator node and also there is a high probability that the communication with the node is valid. Such leakage of information is highly undesirable because the leaked information could be strategically used by threat actors in the accumulation phase of an attack. | |
| EXF-0003 | Signal Interception | The adversary captures mission traffic in transit, on ground networks or over the space link, so that payload products, housekeeping, and command/ack exchanges can be reconstructed offline. Vantage points include tapped ground LANs/WANs between MOC and stations, baseband interfaces (IF/IQ), RF/optical receptions within the antenna field of view, and crosslink monitors. Depending on protection, the haul ranges from plaintext frames to encrypted bitstreams whose headers, rates, and schedules still yield valuable context (APIDs, VCIDs, pass timing, file manifest cues). Intercepted sessions can guide later replay, cloning, or targeted downlink requests. | |
| EXF-0003.01 | Uplink Exfiltration | Here the target is command traffic from ground to space. By receiving or tapping the uplink path, the adversary collects telecommand frames, ranging/acquisition exchanges, and any file or table uploads. If confidentiality is weak or absent, opcode/argument content, dictionaries, and procedures become directly readable; even when encrypted, session structure, counters, and acceptance timing inform future command-link intrusion or replay. Captured material can reveal maintenance windows, contingency dictionaries, and authentication schemes that enable subsequent exploitation. | |
| EXF-0003.02 | Downlink Exfiltration | The attacker records spacecraft-to-ground traffic, real-time telemetry, recorder playbacks, payload products, and mirrored command sessions, to obtain mission data and health/state information. With sufficient signal quality and protocol knowledge, frames and packets are demodulated and extracted for offline use; where protection exists only on uplink or is inconsistently applied, downlink content may still be in clear. Downlinked command echoes, event logs, and file catalogs can expose internal activities and aid follow-on targeting while the primary objective remains data capture at scale. | |
| EXF-0004 | Out-of-Band Communications Link | Some missions field secondary links, separate frequencies and hardware, for limited, purpose-built functions (e.g., rekeying, emergency commanding, beacons, custodial crosslinks). Adversaries co-opt these channels as covert data paths: embedding content in maintenance messages, beacon fields, or low-rate housekeeping; initiating vendor/service modes that carry file fragments; or switching to contingency profiles that bypass normal routing and monitoring. Because these paths are distinct from the main TT&C and may be sparsely supervised, they provide discreet avenues to move data off the spacecraft or to external relays without altering the primary link’s traffic patterns. | |
| 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-0007 | Compromised Ground System | The adversary resides in mission ground infrastructure and uses its trusted position to siphon data at scale. With access to operator workstations, mission control servers, baseband/modem chains, telemetry processing pipelines, or archive databases, the attacker can mirror real-time streams, scrape recorder playbacks, export payload products, and harvest procedure logs and command histories. Because exfiltration rides normal paths, file staging areas, data distribution services, cloud relays, or cross-site links, it blends with routine dissemination. Compromise of scheduling tools and pass plans also lets the actor time captures to high-value downlinks and automate bulk extraction without touching the spacecraft. | |
| 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. | |
| EXF-0009 | Compromised Partner Site | The adversary leverages third-party infrastructure connected to the mission, commercial ground stations, relay networks, operations service providers, data processing partners, to capture or relay mission data outside official channels. From these footholds, the attacker can mirror TT&C and payload feeds, scrape shared repositories, and man-in-the-middle cross-organization links (e.g., between partner stations and the primary MOC). Because partner environments vary in segmentation and monitoring, exfiltration can affect multiple missions or operators simultaneously, with stolen data exiting through the partner’s routine distribution mechanisms. | |
| EXF-0010 | Payload Communication Channel | Many payloads maintain communications separate from the primary TT&C, direct downlinks to user terminals, customer networks, or experimenter VPNs. An adversary who implants code in the payload (or controls its gateway) can route host-bus data into these channels, embed content within payload products (e.g., steganographic fields in imagery/telemetry), or schedule covert file transfers alongside legitimate deliveries. Because these paths are expected to carry high-rate mission data and may bypass TT&C monitoring, they provide a discreet conduit to exfiltrate payload or broader spacecraft information without altering the primary command link’s profile. | |