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.
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.
CM0021 Software Digital Signature Each software or firmware image subject to installation or update control shall be verified using an approved digital signature and an approved trust anchor before installation or activation. The trust anchor may be represented by a certificate or by a directly provisioned verification key, depending on the approved trust architecture. Successful verification establishes that the image was signed by an authorized signing identity and has not been modified since signing; it does not establish that the signed code is non-malicious, vulnerability-free, or operationally safe. Signature verification confirms the integrity and approved origin of the software but does not, by itself, prevent installation of an older validly signed version; update authorization and rollback protections must be enforced separately.
The verification mechanism must be implemented such that it cannot be bypassed through operational commands, configuration changes, or software updates, and must reject any component whose signature is absent or invalid, or whose signing certificate or trust anchor is not recognized and approved by the mission. Digital signature enforcement complements but is distinct from the boot-time chain of trust established through secure boot; it applies to software installation and update events throughout the operational lifecycle, not only at system startup.
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.
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.
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.