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.
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.
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.
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.
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.
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.
CM0054 Two-Person Rule The two-person rule (TPR) requires that all access to and actions within systems possessing command-level authority over the spacecraft be conducted in the continuous presence of two separately authorized individuals, neither of whom alone can complete the access or action. This control reduces the opportunity for unauthorized, coerced, erroneous, or malicious commanding by requiring two independently authorized individuals to participate in the protected access or action. Its effectiveness depends on individual attribution, independent review, resistance to credential sharing or account misuse, and protection against collusion or bypass of the enforcement mechanism. The TPR requires two distinct, appropriately authorized individuals to participate in the same protected access or action. Participation may be physically co-located, remotely performed through authenticated technical controls, or implemented through a combination of physical and logical mechanisms, as defined by mission policy. The second individual must independently review and approve the specific access or action before it is completed. Under CM0054, the two-person rule applies to access and actions involving systems with command-level access to the spacecraft to include reprograming the flight computer/flight software. If the mission tailors the rule to selected commanding functions, the retained scope, excluded access and actions, compensating controls, and associated risk acceptance must be explicitly documented and approved.
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.
CM0065 OSAM Dual Authorization Before a cooperative OSAM engagement enters a protected proximity, capture, docking, mating, or servicing phase, the servicing spacecraft must be authenticated and the specific engagement authorized by both the serviced asset’s mission control authority and, where technically capable, the serviced asset itself. Authentication establishes the identity of the servicer, while dual authorization requires two independent approval decisions for the proposed activity. The approvals may be sequential rather than simultaneous but must both remain valid and be bound to the same servicer, client, service scope, mission phase, interfaces, operational constraints, and validity period. Failure to obtain or maintain authorization must cause the serviced asset to withhold cooperation and interface enablement and must invoke the approved hold, retreat, or abort response. These controls reduce the risk of unauthorized servicing but cannot physically prevent a hostile or non-cooperative spacecraft from approaching the asset.