Threat actors may issue low-level device or maintenance commands that act directly on hardware, bypassing much of the high-level command mediation. These may be memory-mapped register writes forwarded over the bus, vendor-specific instrument/control opcodes, built-in-test and calibration modes, boot-mode or fuse-programming sequences, file/sector operations to on-board non-volatile stores, or actuator primitives for wheels, thrusters, motors, heaters, and RF chains. Because these interfaces exist to configure sensors, zero momentum, switch power domains, tune gains, or adjust clocks, they can also be sequenced to produce harmful effects: over-driving mechanisms, altering persistent calibration, disabling watchdogs, or switching timing sources. Some hardware command sets are only exposed in maintenance or contingency modes, while others are always reachable through gateway processors that translate high-level telecommands into device-level operations. By crafting orders that respect expected framing and rate/size limits, the adversary can induce mechanical, electrical, or logical state changes with immediate, high-privilege impact, all while appearing to exercise legitimate device capabilities.
| ID | Name | Tiering | Description | NIST Rev5 | ISO 27001 | Onboard SV | Ground | |
| CM0032 | On-board Intrusion Detection & Prevention | An on-board intrusion detection and prevention system (IDS/IPS) monitors mission-critical spacecraft components and systems, generates and stores audit records, and supports mission-approved responses to detected threats. Depending on the mission architecture, threat, and availability of ground support, responses may be autonomous, ground-directed, or a combination of both. The system should address both known attack patterns and previously unseen anomalous behavior through complementary signature-based and behavior- or anomaly-based detection methods. Machine learning or adaptive technologies may be used when their performance, resource consumption, and failure behavior have been validated for the mission environment. Detection and response coverage should address applicable adversary activities across the attack lifecycle, including initial access, execution, persistence, defense evasion, and exfiltration. The on-board IDS/IPS must be integrated with the spacecraft's traditional fault management system to provide a unified approach to anomaly response, ensuring that cyber-triggered responses are compatible with fault management logic and do not produce unintended effects or fratricide against the spacecraft's own systems; countermeasures that are incompatible with fault management are considered unsafe and must not be executed autonomously. The response hierarchy must prioritize vehicle safety and continued mission operations. Advanced containment or deception responses may be considered when they can be executed without unacceptable mission risk. The system should preserve evidence that supports post-event analysis, threat characterization, and potential attribution by authorized ground support. | AU-14 AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(2) AU-5(5) AU-6(1) AU-6(4) AU-8 AU-9 AU-9(2) AU-9(3) CA-7(6) CM-11(3) CP-10 CP-10(4) IR-4 IR-4(11) IR-4(12) IR-4(14) IR-4(5) IR-5 IR-5(1) PL-8 PL-8(1) RA-10 RA-3(4) SA-8(21) SA-8(22) SA-8(23) SC-16(2) SC-32(1) SC-5 SC-5(3) SC-7(10) SC-7(9) SI-10(6) SI-16 SI-17 SI-3 SI-3(10) SI-3(8) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(13) SI-4(16) SI-4(17) SI-4(2) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-4(7) SI-6 SI-7(17) SI-7(8) | A.8.15 A.8.15 A.8.6 A.8.17 A.5.33 A.8.15 A.8.15 A.5.29 A.5.25 A.5.26 A.5.27 A.5.8 A.5.7 A.8.12 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16 | ||||
| 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. | AC-14 CP-2 SA-3 SA-4(5) SA-8 SI-10 SI-10(3) SI-10(6) SI-3(8) | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | ||||