Cloaking Safe-mode

Safe-mode entry represents a high-risk transition point at which a spacecraft enters a reduced-capability state to preserve vehicle safety and support anomaly recovery. This transition must not create a less secure command, telemetry, or onboard processing environment. To the extent permitted by mission safety and recovery requirements, the spacecraft should avoid unnecessary or uniquely identifying changes in transmission characteristics, beacon content, communication cadence, and externally observable behavior that would allow an adversary to reliably identify and exploit the safe-mode state. Safe-mode shall preserve the mission-defined minimum security posture for every communication path and command mechanism that remains active. This posture should include authentication, data integrity, anti-replay protection, command authorization, command validation, cryptographic key protection, security-relevant logging, and encryption where confidentiality is required. The spacecraft shall not enter a crypto-bypass or unauthenticated command state solely because safe-mode has been activated. The safe-mode software and configuration baseline shall explicitly define the security controls, command dictionaries, alternate receivers, contingency communication paths, rate and size limits, command counters, time tag requirements, interlocks, logging functions, and monitoring capabilities that remain active during safe-mode. These protections shall be designed and verified as part of the safe-mode baseline rather than treated as discretionary functions that may be removed without security impact analysis.

ID: CM0006
Tier: I
Onboard SV CM 
Created: 2022/10/19
Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should explicitly address safe-mode security behavior as a distinct design requirement, separate from general safe-mode functionality requirements, to prevent safe-mode designs that treat security features as discretionary loads to be shed during contingency operations. Requirements should mandate that all enabled nominal, alternate, backup, contingency, and maintenance communication paths preserve the mission-defined minimum security posture during safe-mode. At a minimum, requirements should address authentication, integrity protection, anti-replay handling, command authorization, command validation, key protection, security-relevant logging, and encryption where confidentiality is required. The spacecraft shall not employ a safe-mode command path that permits unauthenticated commanding or intentional cryptographic bypass. Any difference between nominal-mode and safe-mode security enforcement should be explicitly identified, justified through risk analysis, and approved by the appropriate technical and cybersecurity authorities. Contract language should require contractors to demonstrate, through analysis and test, that safe-mode entry, operation, and exit do not create unauthorized intervals during which required security controls are inactive, bypassed, incorrectly initialized, or operating with stale security state. Verification should include fault injection and mode-transition testing initiated by watchdog resets, processor resets, brownout conditions, loss of communication, corrupted telemetry, malformed commands, resource exhaustion, and other representative fault or adversarial conditions. Testing should verify continuity or secure reinitialization of cryptographic keys, command counters, anti-replay windows, time tag processing, command authorization rules, logging, alternate receiver configurations, communication rate limits, and command interlocks. Test results and any approved exceptions should be reviewed by government technical and cybersecurity authorities before launch authorization.

Pre-Operations Developer/Supplier

Safe-mode architecture must be designed from the outset to preserve a defined minimum set of security functions throughout the transition to contingency operations. Authentication, integrity verification, anti-replay processing, command authorization, command validation, key protection, security logging, and required confidentiality protections should be implemented in architectural layers that remain available or fail securely when the spacecraft transitions to safe-mode. The safe-mode software and firmware baseline should be a discrete, configuration-controlled, and independently verified configuration. It should explicitly identify the communication links, command paths, receivers, antennas, cryptographic functions, command dictionaries, counters, interlocks, and monitoring capabilities available during safe-mode. This requirement should not be interpreted as requiring every nominal security service to remain active; rather, the minimum safe-mode security posture should be formally defined, justified, and verified. Safe-mode power, processing, memory, timing, thermal, and link-budget analyses should account for the resources required to maintain the defined minimum security posture. This analysis should include cryptographic processing, authentication and integrity verification, anti-replay state management, command validation, security logging, and transmission of security-relevant status telemetry. Resource constraints should be addressed during design rather than used after implementation as justification for an undocumented crypto-bypass or reduced-authentication mode. Signature reduction measures applicable in safe-mode, such as minimizing beacon transmission frequency or reducing non-essential telemetry, should be identified during design and incorporated into the safe-mode configuration rather than left as ad hoc operator decisions. Mode-transition testing should include adversarial scenarios in which safe-mode entry is induced under simulated attack conditions to verify that the transition does not create exploitable windows of reduced security.