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.
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.
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.
CM0074 Distributed Constellations A distributed constellation architecture deploys mission capability across multiple spacecraft nodes operating collectively, such that the end user is not dependent on any single satellite to derive the intended capability. This architectural approach directly complicates adversary counterspace planning by multiplying the number of assets that must be successfully degraded or destroyed to achieve mission denial effects equivalent to those achievable against a concentrated, single-node architecture. The resilience benefit depends on how much mission capability remains available following the loss or degradation of specified nodes. A constellation that can satisfy defined minimum mission requirements through multiple combinations of surviving nodes generally requires an adversary to affect more assets or shared dependencies to achieve mission denial. GPS exemplifies this principle: a receiver generally uses signals from at least four healthy satellites with suitable geometry to determine three-dimensional position and time. Loss of one satellite does not ordinarily eliminate the service where sufficient healthy satellites remain visible; resilience to ground-system failures depends separately on the redundancy and distribution of the control segment. Distribution is a mission architecture decision that must be made early in the program lifecycle, as it fundamentally shapes spacecraft design, ground system architecture, launch strategy, and operational concepts.
CM0075 Proliferated Constellations Proliferated satellite constellations increase mission resilience by deploying a larger number of functionally equivalent satellites in similar orbits, expanding overall constellation capacity and raising the number of assets an adversary must successfully attack to achieve meaningful mission degradation. Unlike distribution, in which multiple satellites or payloads work together to provide a complete capability, proliferation increases the number of systems performing the same or substantially equivalent mission. Its resilience benefit is primarily derived from additional capacity and reduced dependence on any individual satellite rather than from architectural diversity. Proliferation also supports resilience through on-orbit spare maintenance, in which additional satellites are held in reserve or parked in accessible orbits to replace operational assets without requiring new launches. The cost implications of proliferation are significant and architecture-dependent. Designs optimized for repeatable production may achieve lower unit costs through learning and economies of scale, but those savings depend on design stability, production quantity, supplier capacity, and the amount of non-recurring change between production lots. The choice to proliferate must be made as a mission architecture decision early in the program, as it determines the spacecraft design philosophy, production strategy, launch architecture, and ground system scalability requirements.
CM0076 Diversified Architectures A diversified mission architecture provides a capability through multiple systems, platforms, payloads, orbital regimes, or domains to reduce the mission impact of losing any individual element and increase the range of adversary capabilities required to achieve mission denial. Diversification differs from proliferation in that it employs heterogeneous systems, potentially across different orbits, domains, operators, and technologies, rather than deploying more units of the same design. This heterogeneity imposes asymmetric costs on adversaries: attacking systems across different orbital regimes requires different physical and electronic capabilities for each regime, and kinetic attacks on space assets in diverse orbits carry differentiated collateral debris consequences that increase the political and economic cost of a broad attack campaign. Domain diversification, extending mission capability delivery across space, airborne, and terrestrial layers, further reduces adversary incentive by ensuring that defeating the space layer alone does not deny the end user the underlying capability. Diversification can preserve minimum mission capability following the loss of individual elements when the remaining systems provide sufficient coverage, capacity, interoperability, and operational availability to compensate for the loss.
CM0077 Space Domain Awareness Space domain awareness (SDA) enables mission owners to detect and characterize objects, behaviors, environmental conditions, and anomalous events that may affect their space systems. When correlated with other intelligence and mission data, SDA can also support assessment of possible threats and attribution. SDA encompasses the tracking and cataloging of space objects, prediction of future object positions, monitoring of the space environment and space weather, and characterization of the capabilities and behaviors of on-orbit objects. SDA data must provide the accuracy, timeliness, coverage, and characterization needed for the mission’s defined decisions. Publicly available data may support general awareness but may be insufficient for time-sensitive conjunction, proximity, or threat assessment; appropriate government, commercial, partner, or owner-operator data should be obtained where required. SDA is generated by a diverse sensor architecture spanning terrestrial optical, infrared, and radar systems and space-based sensors including inspector satellites capable of close-approach observation. The SDA landscape is increasingly populated by national space agencies, military programs, allied partners, commercial providers, and amateur tracking communities, making the space environment progressively more transparent and creating opportunities for mission owners to leverage diverse data sources to build a more complete operational picture.
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.
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.