Implement non-persistent [Assignment: organization-defined system components and services] that are initiated in a known state and terminated [Selection (one or more): upon end of session of use; periodically at [Assignment: organization-defined frequency]
].
Non-persistence in a space context involves designing spacecraft components to avoid storing long-lived sensitive data or residual states that might be exploited over time. This could mean ephemeral session keys that reset after each command pass or memory partitions that automatically zero after usage, preventing adversaries from gleaning leftover data once a session ends. For instance, if a satellite uses a patching interface, non-persistent storage can load the patch into volatile memory, validate it, and discard the buffer without permanently storing potential attack vectors. Further, after each boot cycle, the system can revert to a minimal “golden” baseline and only load ephemeral data necessary for current operations. These practices help limit the attack surface by giving malware or latent threats fewer places to hide and survive across reboots, especially important for satellites that operate in contested or highly classified environments.
Persistent sessions increase exposure to hijacking and replay attacks. Automatic termination limits session lifetime and reduces unauthorized reuse. Idle timeout reduces attack surface in unattended conditions. Explicit closure supports session state integrity.
SPR-498
The [spacecraft] shall minimize persistence of sensitive data and cryptographic material by using ephemeral session keys stored only in volatile memory and purging them upon session end, mode change, or power cycle.{SV-AC-3}{SI-14}
The [spacecraft] shall avoid storing sensitive operational data in nonvolatile memory unless required by mission, and if stored, it shall be encrypted and retained only for [organization]-defined durations.{SV-AC-3,SV-IT-2}{SI-14}