Docking, berthing, or service capture during on-orbit servicing, assembly, and manufacturing (OSAM) creates a high-trust bridge between vehicles. Threat actors exploit this moment, either by pre-positioning code on a servicing vehicle or by manipulating ground updates to it, so that, once docked, lateral movement occurs across the mechanical/electrical interface. Interfaces may expose power and data umbilicals, standardized payload ports, or gateways into the target’s C&DH or payload networks (e.g., SpaceWire, Ethernet, 1553). Service tools that push firmware, load tables, transfer files, or share time/ephemeris become conduits for staged procedures or implants that execute under maintenance authority. Malware can be timed to activation triggers such as “link up,” “maintenance mode entered,” or specific device enumerations that only appear when docked. Because OSAM operations are scheduled and well-documented, the adversary can align preparation with published timelines, ensuring that the first point of execution coincides with the brief window when cross-vehicle trust is intentionally elevated.
| ID | Name | Tiering | Description | NIST Rev5 | ISO 27001 | Onboard SV | Ground | |
| CM0077 | Space Domain Awareness | Space domain awareness (SDA) enables mission owners to detect and characterize objects, behaviors, environmental conditions, and anomalous events that may affect their space systems. When correlated with other intelligence and mission data, SDA can also support assessment of possible threats and attribution. SDA encompasses the tracking and cataloging of space objects, prediction of future object positions, monitoring of the space environment and space weather, and characterization of the capabilities and behaviors of on-orbit objects. SDA data must provide the accuracy, timeliness, coverage, and characterization needed for the mission’s defined decisions. Publicly available data may support general awareness but may be insufficient for time-sensitive conjunction, proximity, or threat assessment; appropriate government, commercial, partner, or owner-operator data should be obtained where required. SDA is generated by a diverse sensor architecture spanning terrestrial optical, infrared, and radar systems and space-based sensors including inspector satellites capable of close-approach observation. The SDA landscape is increasingly populated by national space agencies, military programs, allied partners, commercial providers, and amateur tracking communities, making the space environment progressively more transparent and creating opportunities for mission owners to leverage diverse data sources to build a more complete operational picture. | CP-13 CP-2(3) CP-2(5) CP-2(7) PE-20 PE-6 PE-6(1) PE-6(2) PE-6(4) RA-6 SI-4(17) | A.5.29 A.7.4 A.8.16 A.7.4 A.7.4 A.5.10 | ||||
| CM0079 | Maneuverability | Spacecraft maneuverability provides an active physical defense capability against kinetic and certain directed energy threats by enabling the satellite to relocate from a predicted intercept trajectory when a threat is detected with sufficient warning time. Against unguided projectiles, maneuvering out of the predicted impact trajectory can be effective, requiring only sufficient delta-v and warning time to execute a displacement maneuver before impact. Against guided threats, including direct-ascent anti-satellite (ASAT) weapons and co-orbital ASAT platforms equipped with onboard sensors, maneuverability is significantly more constrained in its effectiveness; evasion requires displacing the satellite beyond the seeker or sensor acquisition range of the guided warhead, which demands larger delta-v margins and more precise threat characterization than unguided intercept scenarios. The effectiveness of maneuverability as a countermeasure is therefore strongly dependent on the warning time provided by space domain awareness (SDA) capabilities, the propulsion capacity of the spacecraft, the fidelity of threat trajectory characterization, and whether the threat employs passive or active terminal guidance. Maneuverability also provides operational flexibility for avoiding predictable orbital slots that adversaries may have targeted in advance, complicating targeting planning even in the absence of an active threat event. | CP-10(6) CP-13 CP-2 CP-2(1) CP-2(3) CP-2(5) PE-20 PE-21 | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 A.5.29 A.5.10 | ||||
| CM0080 | Stealth Technology | Spacecraft stealth encompasses design and operational techniques that reduce a satellite's detectability and trackability by adversary space surveillance systems, increasing the cost and difficulty of adversary targeting, tracking, and characterization efforts. Design-based approaches include reducing physical size to decrease radar cross-section (RCS), applying radar-absorbing coatings, using radar-deflecting geometric shapes, and controlling the emission or reflection of radar, optical, and infrared (IR) energy to minimize the observable signatures that surveillance sensors rely upon. Operational stealth techniques include optimizing maneuver profiles to avoid detection by known ground-based or space-based tracking sensors, executing maneuvers at unexpected times or with trajectories that complicate orbit determination, and employing active measures such as radar jamming or spoofing to degrade tracking accuracy. These approaches collectively raise the adversary's intelligence collection burden, degrade the accuracy of targeting solutions, and reduce the predictability of the spacecraft's future position, complicating the planning and execution of both kinetic and directed energy counterspace attacks. Stealth is a design philosophy and operational discipline that must be balanced against mission functional requirements, as size reductions and coating applications that reduce observability may affect payload capacity, thermal management, and power generation. | CP-10(6) CP-13 SC-30 SC-30(5) | A.5.29 | ||||
| CM0081 | Defensive Jamming and Spoofing | Defensive jamming and spoofing are active electronic countermeasures that may disrupt or deceive the terminal guidance sensors of an incoming kinetic anti-satellite weapon. When combined with evasive maneuvering, these measures may reduce the accuracy of the threat’s targeting solution and lower the probability of a successful intercept. Effectiveness depends on timely threat detection, knowledge of the relevant sensor characteristics, available transmit power and geometry, and the threat’s ability to recognize or overcome the countermeasure. Development, testing, and employment of these capabilities must occur only under applicable governmental authorization, spectrum authority, rules of engagement, and information-protection requirements. The design must limit unintended interference and account for effects on friendly, civil, and safety-related radio services. | CP-10(6) CP-13 CP-2 CP-2(1) CP-2(5) CP-2(7) PE-20 | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 A.5.29 A.5.10 | ||||
| CM0082 | Deception and Decoys | Deception and decoy techniques can reduce the accuracy or confidence of adversary assessments concerning spacecraft location, capability, operational status, mission type, or constellation robustness. Ground segment honeypots, such as HoneySat, extend deception into the cyber domain by simulating realistic satellite ground infrastructure and mission control systems to attract, deceive, and collect intelligence on adversaries attempting network-based compromise of satellite operations. Their effectiveness depends on whether the deception remains credible when evaluated across the observable signatures and intelligence sources available to the adversary. Strategic deception encompasses information operations approaches such as controlled public messaging and launch announcements that limit disclosure or actively introduce uncertainty about satellite capabilities, as well as operational practices that conceal spacecraft functions through careful management of observable behaviors and emissions. On-orbit capability deception, enabled by swappable payload modules and on-orbit servicing vehicles that periodically transfer payloads between satellites, creates persistent uncertainty in the adversary's intelligence picture about which capabilities are resident on which platform at any given time, directly complicating targeting calculus. Tactical decoys provide active point defense by creating false targets that confuse the sensors of anti-satellite (ASAT) weapons and space domain awareness (SDA) surveillance systems; physical decoys, such as deployable inflatable devices that replicate a satellite's size and radar cross-section, and electromagnetic decoys that mimic a spacecraft's radio frequency (RF) signature, can each divert adversary attention and degrade the reliability of tracking and targeting solutions. Multiple decoys stored onboard for sequential deployment extend the utility of the capability across engagement scenarios. Cyber-layer deception through satellite honeypots represents an emerging defensive capability that complements physical and electromagnetic deception techniques. Systems like HoneySat simulate complete satellite missions, including ground segment software, mission control interfaces, orbital pass timing, and realistic telemetry generation, to create high-fidelity decoys accessible over network protocols commonly used in satellite operations. By mimicking the communication patterns, telecommand structures, and subsystem behaviors of operational small satellites, these honeypots can successfully deceive adversaries conducting reconnaissance or attempting unauthorized access via Internet-exposed ground infrastructure. The intelligence collected from honeypot interactions provides visibility into adversary TTPs targeting space systems, enabling defenders to characterize threat actor capabilities, refine attribution assessments, and develop countermeasures based on observed attack patterns. Integration of honeypots into satellite mission architectures, whether as standalone decoy systems or as protective layers around operational ground segments, adds depth to cyber defense postures while imposing costs on adversaries who must expend resources distinguishing genuine targets from sophisticated simulations. | SC-26 SC-30 | None | ||||
| CM0083 | Antenna Nulling and Adaptive Filtering | Antenna nulling and adaptive filtering are complementary electronic protection techniques that reduce the effects of jamming on spacecraft communication and sensing links while preserving access to legitimate signals. Antenna nulling dynamically adjusts the receive antenna pattern to reduce sensitivity in the estimated direction of arrival of a jammer. For terrestrial interference, the affected geographic region depends on the spacecraft’s position and attitude, antenna geometry, and uncertainty in the jammer’s location. Nulling is most effective against a limited number of discrete, detectable interference sources, but it may also attenuate legitimate signals arriving from the same or a nearby direction. Adaptive filtering suppresses interference based on its spectral or signal characteristics, such as by placing adaptive notches around narrowband or slowly varying interference. It can preserve operation within unaffected portions of the received bandwidth but may also remove or distort legitimate signal energy that overlaps the rejected frequencies. Its effectiveness decreases against wideband, rapidly changing, or multiple simultaneous jammers when too little usable bandwidth remains to support mission requirements. Used together, antenna nulling and adaptive filtering can address a broader range of jamming conditions than either technique alone. Both techniques depend on the interference remaining within the operating range of the antenna and receiver chain. If a jammer saturates or damages the low-noise amplifier, analog front end, or analog-to-digital converter, downstream digital processing may be unable to recover the legitimate signal. Receiver dynamic range and front-end protection must therefore be incorporated into the overall electronic protection design. | SC-40 SI-4(14) | None | ||||
| CM0084 | Physical Seizure | Physical seizure capability employs spacecraft equipped with docking, manipulation, or proximity maneuvering systems to counter space-based threats and mitigate post-attack effects through direct physical interaction with other on-orbit objects. Primary applications include seizing or neutralizing a threatening satellite actively attacking or endangering other spacecraft, capturing a satellite that has been disabled or hijacked and is being operated for hostile purposes, and collecting and disposing of harmful orbital debris resulting from a kinetic attack. The effectiveness of a physical seizure system is fundamentally constrained by propellant and time: a seizure asset stored in a particular orbital regime cannot efficiently reach objects in significantly different orbits due to the delta-v required for large orbital plane changes or altitude transfers, making geostationary Earth orbit (GEO) assets poorly positioned to respond to threats in low Earth orbit (LEO) and vice versa. This constraint drives a basing trade between pre-positioned on-orbit assets and ground-based responsive-launch assets. On-orbit assets may provide shorter response times but remain limited by their current orbit, propellant reserves, and readiness state. Ground-based assets may be launched closer to the required orbital plane and altitude but remain constrained by launch readiness, vehicle performance, launch-site geometry, and the time required to reach and rendezvous with the target. | CP-13 PE-20 | A.5.29 A.5.10 | ||||
| CM0087 | Defensive Dazzling/Blinding | Defensive dazzling and blinding employs directed laser energy to degrade or defeat the optical or infrared (IR) sensors of adversary systems, providing an active countermeasure against kinetic anti-satellite (ASAT) weapons and adversary reconnaissance platforms in the space domain. Against kinetic ASAT threats, laser energy directed toward the terminal guidance sensor of an incoming weapon may temporarily saturate, disrupt, or damage the sensor and reduce the accuracy of terminal guidance. When coordinated with evasive maneuvering, this capability may reduce the probability of a successful intercept. Effectiveness depends on timely threat detection, target-sensor characteristics, engagement geometry, laser performance, pointing accuracy, dwell time, and the threat’s ability to maintain or recover guidance. Against adversary inspector satellites or SDA collection platforms, defensive dazzling may temporarily degrade or deny optical or infrared collection of the protected spacecraft. Permanent sensor damage is a materially different effect that requires separate authorization, targeting criteria, and escalation analysis. Dazzling generally produces temporary sensor degradation, while blinding produces permanent sensor damage. Both effects carry legal, policy, safety, and escalation implications, but their legal characterization depends on the target, circumstances, intended effect, actual consequences, and applicable national and international authorities. Employment authorities and prohibited target or effect categories must be established before the capability is operationally relied upon. | CP-10(6) CP-13 CP-2 CP-2(1) CP-2(5) CP-2(7) PE-20 SC-30(5) | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 A.5.29 A.5.10 | ||||
| CM0002 | COMSEC | Communications security (COMSEC) denies unauthorized parties access to information derived from telecommunications while ensuring the authenticity of those communications. COMSEC is commonly defined as a broad discipline that may encompass cryptographic security, transmission security, emissions security, cryptographic key management, traffic-flow security, and physical security of COMSEC material. Within SPARTA, these areas are further broken down through separate countermeasures, including CM0029 | TRANSEC, CM0030 | Crypto Key Management, CM0003 | TEMPEST/EMSEC, and CM0073 | Traffic Flow Analysis Defense. CM0002 provides the overarching communications-security context and supports the coordinated application of these specialized countermeasures. All mission links, particularly telemetry, tracking, and commanding (TT&C) links, should employ communications-security protections appropriate to the sensitivity, criticality, operational environment, and threat exposure of the information being exchanged. These protections may include cryptographic protection, transmission security, emissions security, traffic-flow protection, secure key management, and physical protection of COMSEC material, as addressed by the applicable specialized countermeasures. Spacecraft should not provide an operational mode that permits required cryptographic protection or command authentication on TT&C links to be bypassed or disabled. Operational, maintenance, test, recovery, and contingency modes should be considered when evaluating whether communications-security protections can be unintentionally or improperly circumvented. Communication receivers and associated signal-processing or TRANSEC mechanisms should detect and, when mission-defined criteria are met, reject or otherwise safely handle transmissions exhibiting anomalous signal characteristics consistent with communications deception. Cryptographic mechanisms should authenticate and integrity-check received content but should not be treated as RF-deception detectors. | AC-17 AC-17(1) AC-17(10) AC-17(2) AC-18 AC-18(1) AC-2(11) AC-3(10) CA-3 IA-4(9) IA-5 IA-5(7) IA-7 PL-8 PL-8(1) SA-8(18) SA-8(19) SA-9(6) SC-10 SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-13 SC-16(3) SC-28(1) SC-28(3) SC-7 SC-7(10) SC-7(11) SC-7(18) SC-7(5) SC-8(1) SC-8(3) SI-10 SI-10(3) SI-10(5) SI-10(6) SI-19(4) SI-3(8) | A.5.14 A.6.7 A.8.1 A.8.16 A.5.14 A.8.1 A.8.20 A.5.14 A.8.21 A.5.16 A.5.17 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.12 A.5.33 A.8.20 A.8.24 A.8.24 A.8.26 A.5.31 A.5.33 A.8.11 | ||||
| CM0031 | Authentication | All command-bearing sessions, frames, or messages involving spacecraft command links, crosslinks, or relay services shall provide cryptographic authentication of the command origin and integrity verification before commands are accepted. Mutual or bidirectional authentication shall be required where both endpoints must authenticate one another and the link and protocol architecture support that exchange. Acquisition requirements should mandate cryptographically based, bidirectional authentication for all command sessions across external links, including ground-to-spacecraft uplinks, spacecraft-to-spacecraft crosslinks, and any relay or intermediary ground station connections, with authentication required aBidirectional authentication enables both communicating entities to verify each other’s identity and helps prevent impersonation. Authentication establishes identity but does not by itself authorize a command, protect mission-data confidentiality, or prevent session hijacking. Command acceptance must also enforce authorization, and authenticated sessions or security associations must maintain integrity and replay resistance so that subsequent traffic remains bound to the authenticated entities. Beyond external links, authentication is strongly recommended for spacecraft internal bus communications and onboard inter-component connections, as an adversary with access to internal interfaces, whether through a compromised component or a physical access event, should face the same authentication barrier as an external adversary attempting to inject commands from outside the spacecraft. | AC-14 AC-17 AC-17(10) AC-17(2) AC-18 AC-18(1) IA-2 IA-3(1) IA-4 IA-4(9) IA-7 IA-9 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(1) SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) SI-7(6) | A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.5.16 A.5.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 | ||||
| CM0003 | TEMPEST / EMSEC | TEMPEST controls (i.e., emissions security (EMSEC)) protect spacecraft system components, internal data communications, and communication buses against side-channel and proximity-based attacks that exploit unintended electromagnetic, electrical, or acoustic emanations. Critical components must be enclosed within appropriate casings or shielding structures that attenuate unintended emissions to levels that deny adversaries the ability to reconstruct processed data or infer system state from externally observable signals. Shielding must extend to internal buses and data pathways, not only to individual processing elements, as inter-component communications represent a significant and often overlooked emanations surface. The physical enclosure strategy must be integrated with the broader system architecture so that shielding effectiveness is not degraded by penetrations, connectors, or cable routing that create unintended emissions paths. During sustainment & maintenance, Spacecraft TEMPEST and EMSEC protections are primarily established during design, fabrication, and integration, but sustainment remains applicable through configuration control, review of deployment-state or hardware changes, preservation of qualification evidence, assessment of relevant anomalies, and evaluation of refurbishment, replacement, or follow-on production changes. The guidance below addresses these spacecraft considerations as well as applicable ground-segment maintenance activities. | PE-19 PE-19(1) PE-21 SC-8(3) | A.7.5 A.7.8 A.8.12 | ||||
| CM0040 | Shared Resource Leakage | Shared system resources (e.g., processor registers, main memory, secondary storage, cache) may retain residual data or security-relevant state after a process releases them for reuse. If a subsequent process can access that residual information, it may obtain data from the prior process, including sensitive information or encrypted representations of information that were not intended to cross process or partition boundaries. This countermeasure requires that shared resources be sanitized, zeroed, or otherwise cleared of prior process data before being allocated to a new process, ensuring that information transfer between processes occurs only through explicitly authorized channels. The protection must apply to encrypted representations as well as plaintext because encrypted data remains information belonging to the prior process and must not be transferred to another process solely because its contents are not immediately readable. This is particularly significant in space system environments where multiple processes of varying criticality and trust levels may share the same hardware resources. | AC-4(23) AC-4(25) SA-8(19) SA-8(2) SA-8(5) SA-8(6) SC-2(2) SC-3(4) SC-32(1) SC-4 SC-49 SC-50 SC-7(29) | A.8.11 A.8.10 | ||||
| CM0050 | On-board Message Encryption | Authentication controls on the spacecraft internal bus verify the identity of communicating components but do not protect the confidentiality of the data in transit; an adversary with access to the bus, whether through a compromised component, a hardware implant, or a physical access event, can observe all unencrypted inter-component communications regardless of whether authentication is enforced. Encrypting data traversing the spacecraft internal bus protects the confidentiality of selected message content from entities that can observe the bus but do not possess authorization and the applicable cryptographic keys. The protection does not prevent disclosure to a compromised component that legitimately possesses the decryption key, and it may not conceal unencrypted protocol headers, addressing information, message timing, or traffic volume. Bus encryption should be considered for bus segments or message types carrying information whose unauthorized disclosure would create unacceptable mission, security, privacy, or operational risk. Criticality alone does not establish a confidentiality requirement. Where confidentiality is required, encryption must be combined with message integrity, source authentication, and replay protection through an approved authenticated-encryption mechanism or an appropriately composed set of cryptographic protections. | AC-4 AC-4(23) AC-4(24) AC-4(26) AC-4(31) AC-4(32) PL-8 PL-8(1) SA-3 SA-8 SA-8(18) SA-8(19) SA-8(9) SA-9(6) SC-13 SC-16 SC-16(1) SC-16(2) SC-16(3) SC-8(1) SC-8(3) SI-19(4) SI-4(10) SI-4(25) | A.5.14 A.8.22 A.8.23 A.8.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 A.8.24 A.8.26 A.5.31 A.8.11 | ||||
| CM0039 | Least Privilege | The principle of least privilege requires that every process, user account, service, and system component be granted only the permissions and access rights necessary to perform its defined function, with no additional privileges retained beyond what the assigned task requires. Applied to spacecraft and ground systems, this means that processes executing on flight computers, operating system services, ground system applications, and inter-system communication handlers are each confined to the minimum privilege level needed for their specific function, preventing a compromised or malfunctioning component from leveraging excess permissions to affect other system resources or functions. Separate execution domains should be used where supported to reinforce least privilege and contain process failures or compromise. Process isolation does not replace explicit access controls, because authorized communication and shared resources may still cross execution-domain boundaries. Least privilege is a foundational design principle that reduces the consequence of any individual component compromise by limiting what an adversary can accomplish within that component's execution context. | AC-2 AC-3(13) AC-3(15) AC-4(2) AC-6 CA-3(6) CM-7 CM-7(5) CM-7(8) PL-8 PL-8(1) SA-17(7) SA-3 SA-4(9) SA-8 SA-8(13) SA-8(14) SA-8(15) SA-8(19) SA-8(3) SA-8(4) SA-8(9) SC-2(2) SC-32(1) SC-49 SC-50 SC-7(29) | A.5.16 A.5.18 A.8.2 A.5.15 A.8.2 A.8.18 A.8.19 A.8.19 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | ||||
| 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 | ||||
| CM0037 | Disable Physical Ports | Physical data connection, debug, programming, and maintenance interfaces (e.g., joint test action group (JTAG)) that are not required for spacecraft operations must be disabled, removed, or otherwise made inaccessible before spacecraft operations begin. Interfaces required for operational functions must be explicitly identified and protected against unauthorized physical access and use. These interfaces, essential during development for programming, debugging, and testing, represent persistent attack surfaces in the operational environment: an adversary with physical access to the spacecraft before launch, during ground handling, or at a shared launch facility could exploit active debug interfaces to read memory, modify firmware, bypass security controls, or implant persistent malicious code without leaving detectable traces in software-visible logs. Disabling or removing unused physical interfaces closes a direct hardware-access pathway and reduces reliance on procedural controls or physical security alone. The capability to disable these interfaces must be designed into the system from the outset, as physical removal or reliable hardware-enforced disablement cannot be easily retrofitted into a completed board design. | AC-14 MA-7 PL-8 PL-8(1) SA-3 SA-4(5) SA-4(9) SA-8 SC-41 SC-7(14) | A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | ||||
| CM0038 | Segmentation | Segmentation establishes physical or logical isolation boundaries between spacecraft system components and functional domains to limit the propagation of compromise, contain the consequences of a security failure, and enforce controlled information flow across the mission architecture. Mission-critical functions must be isolated from non-mission-critical functions through enforced partition boundaries that control access to and protect the integrity of the hardware, software, and firmware implementing those functions. Information flow between partitioned components or applications must be explicitly authorized by security policy; any flow not affirmatively permitted is denied by default. Boundary protections must be implemented to separate spacecraft bus, communications, and payload components, preventing a compromise in one domain from directly affecting the others. Information crossing the spacecraft boundary shall receive confidentiality protection where required by its classification, sensitivity, or mission risk. Command-bearing and other security-critical exchanges shall receive the mission-required authentication, integrity, authorization, and anti-replay protections regardless of whether confidentiality is required. These controls collectively implement a defense-in-depth architecture in which an adversary who gains a foothold in one partition faces enforced barriers before reaching mission-critical assets. | AC-4 AC-4(14) AC-4(2) AC-4(24) AC-4(26) AC-4(31) AC-4(32) AC-4(6) AC-6 CA-3 CA-3(7) PL-8 PL-8(1) SA-3 SA-8 SA-8(13) SA-8(15) SA-8(18) SA-8(3) SA-8(4) SA-8(9) SC-16(3) SC-2(2) SC-3 SC-3(4) SC-32 SC-32(1) SC-39 SC-4 SC-49 SC-50 SC-6 SC-7(20) SC-7(21) SC-7(29) SC-7(5) SI-17 SI-4(7) | A.5.14 A.8.22 A.8.23 A.5.15 A.8.2 A.8.18 A.5.14 A.8.21 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | ||||
| 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. | CA-3(6) IA-2(1) IA-2(2) IA-2(6) | None | ||||