a. Enforce physical access authorizations at [Assignment: organization-defined entry and exit points to the facility where the system resides] by: 1. Verifying individual access authorizations before granting access to the facility; and 2. Controlling ingress and egress to the facility using [Selection (one or more): [Assignment: organization-defined physical access control systems or devices] ; guards]; b. Maintain physical access audit logs for [Assignment: organization-defined entry or exit points]; c. Control access to areas within the facility designated as publicly accessible by implementing the following controls: [Assignment: organization-defined physical access controls]; d. Escort visitors and control visitor activity [Assignment: organization-defined circumstances requiring visitor escorts and control of visitor activity]; e. Secure keys, combinations, and other physical access devices; f. Inventory [Assignment: organization-defined physical access devices] every [Assignment: organization-defined frequency]; and g. Change combinations and keys [Assignment: organization-defined frequency] and/or when keys are lost, combinations are compromised, or when individuals possessing the keys or combinations are transferred or terminated.
| ID | Name | Description | D3FEND | |
| CM0054 | Two-Person Rule | The two-person rule (TPR) requires that all access to and actions within systems possessing command-level authority over the spacecraft be conducted in the continuous presence of two separately authorized individuals, neither of whom alone can complete the access or action. This control reduces the opportunity for unauthorized, coerced, erroneous, or malicious commanding by requiring two independently authorized individuals to participate in the protected access or action. Its effectiveness depends on individual attribution, independent review, resistance to credential sharing or account misuse, and protection against collusion or bypass of the enforcement mechanism. The TPR requires two distinct, appropriately authorized individuals to participate in the same protected access or action. Participation may be physically co-located, remotely performed through authenticated technical controls, or implemented through a combination of physical and logical mechanisms, as defined by mission policy. The second individual must independently review and approve the specific access or action before it is completed. Under CM0054, the two-person rule applies to access and actions involving systems with command-level access to the spacecraft to include reprograming the flight computer/flight software. If the mission tailors the rule to selected commanding functions, the retained scope, excluded access and actions, compensating controls, and associated risk acceptance must be explicitly documented and approved. | D3-OAM D3-AM D3-ODM D3-OM D3-MFA | |
| CM0053 | Physical Security Controls | Physical security controls form the outermost defensive layer protecting systems that can command the spacecraft, limiting access to commanding infrastructure to personnel who are both identity-verified and specifically authorized to be in those environments. Unauthorized physical access may enable theft, tampering, connection to exposed interfaces, use of unattended sessions, or attempts to extract or alter protected information. Physical security must therefore complement authentication, encryption, session management, tamper protection, and other technical controls rather than assume those controls will remain sufficient without protection of the underlying equipment. Physical security measures for commanding facilities and infrastructure must use layered controls selected according to the facility threat environment, system criticality, site characteristics, and consequence of unauthorized access. Controls may include perimeter barriers, controlled entry points, interior protected areas, identity and authorization verification, locks, intrusion detection, surveillance, and security personnel. Access to the facility must not, by itself, authorize physical access to commanding systems. Physical security controls must be commensurate with the sensitivity and criticality of the commanding functions they protect, with the most sensitive commanding capabilities requiring the most stringent physical access restrictions. | D3-RFS D3-AM | |
| ID | Description | |
| SV-AC-4 |
Masquerading as an authorized entity in order to gain access/Insider Threat |
|
| SPARTA ID | Requirement | Rationale/Additional Guidance/Notes |
|---|---|---|
| SPR-97 | All [spacecraft] commands which have unrecoverable consequence must have dual authentication prior to command execution. The [spacecraft] shall verify two independent cryptographic approvals prior to execution and shall generate an audit record binding both approver identifiers to the command identifier, time, and outcome.{SV-AC-4,SV-AC-8,SV-AC-2}{AU-9(5),IA-3,IA-4,IA-10,PE-3,PM-12,SA-8(15),SA-8(21),SC-16(2),SC-16(3),SI-3(8),SI-3(9),SI-4(13),SI-4(25),SI-7(12),SI-10(6),SI-13} | Commands with irreversible impact require heightened assurance to prevent catastrophic mission loss. Dual independent cryptographic approvals mitigate insider threat, key compromise, and single-point credential abuse. Binding approver identifiers to the audit trail strengthens accountability and deterrence. This reduces the probability of unauthorized hazardous command execution. |
| SPR-98 | The [spacecraft] shall have a method to ensure the integrity of which have unrecoverable consequence and validate their authenticity before execution.{SV-AC-2,SV-IT-2,SV-IT-1}{AU-9(5),IA-3,IA-4,IA-10,PE-3,PM-12,SA-8(15),SA-8(21),SC-16(2),SC-16(3),SI-3(8),SI-3(9),SI-4(13),SI-4(25),SI-7(12),SI-10(6),SI-13} | Hazardous commands must be cryptographically protected and validated prior to execution. Integrity and authenticity checks prevent replay, modification, or injection of destructive instructions. Without validation, RF interception or command path compromise could result in mission-ending actions. This ensures critical commands are both authorized and unaltered. |
| SPR-356 | The [organization] shall have a two-man rule to achieve a high level of security for systems with command level access to the spacecraft.(Under this rule all access and actions require the presence of two authorized people at all times.) {SV-AC-4}{PE-3} | Note: These are not spacecraft requirements but important to call out but likely are covered under other requirements by the customer. |
| SPR-447 | The [organization] shall have physical security controls to prevent unauthorized access to the systems that have the ability to command the spacecraft.{SV-AC-4}{PE-3} | Note: These are not spacecraft requirements but important to call out but likely are covered under other requirements by the customer. |
| ID | Name | Description | |
|---|---|---|---|
| IA-0007 | Compromise Ground System | Compromising the ground segment gives an adversary the most direct path to first execution against a spacecraft. Ground systems encompass operator workstations and mission control mission control software, scheduling/orchestration services, front-end processors and modems, antenna control, key-loading tools and HSMs, data gateways (SLE/CSP), identity providers, and cloud-hosted mission services. Once inside, a threat actor can prepare on-orbit updates, craft and queue valid telecommands, replay captured traffic within acceptance windows, or manipulate authentication material and counters to pass checks. The same foothold enables deep reconnaissance: enumerating mission networks and enclaves, discovering which satellites are operated from a site, mapping logical topology between MOC and stations, identifying in-band “birds” reachable from a given aperture, and learning pass plans, dictionaries, and automation hooks. From there, initial access to the spacecraft is a matter of timing and presentation, injecting commands, procedures, or update packages that align with expected operations so the first execution event appears indistinguishable from normal activity. | |
| IA-0007.01 | Compromise On-Orbit Update | Adversaries may target the pipeline that produces and transmits updates to an on-orbit vehicle. Manipulation points include source repositories and configuration tables, build and packaging steps that generate images or differential patches, staging areas on ground servers, update metadata (versions, counters, manifests), and the transmission process itself. Spacecraft updates span flight software patches, FPGA bitstreams, bootloader or device firmware loads, and operational data products such as command tables, ephemerides, and calibration files, each with distinct formats, framing, and acceptance rules. An attacker positioned in the ground system can substitute or modify an artifact, alter its timing and timetags to match pass windows, and queue it through the same procedures operators use for nominal maintenance. Activation can be immediate or deferred: implants may lie dormant until a specific mode, safing entry, or table index is referenced. | |
| IA-0007.02 | Malicious Commanding via Valid GS | Adversaries may use a compromised, mission-owned ground system to transmit legitimate-looking commands to the target spacecraft. Because the ground equipment is already configured for the mission, correct waveforms, framing, dictionaries, and scheduling, the attacker’s traffic blends with routine operations. Initial access unfolds by inserting commands or procedures into existing timelines, modifying rate/size limits or command queues, or invoking maintenance dictionaries and rapid-response workflows that accept broader command sets. Pre-positioned scripts can chain actions across multiple passes and stations, while telemetry routing provides immediate feedback to refine follow-on steps. Exfiltration can be embedded in standard downlink channels or forwarded through gateways as ordinary mission data. The distinguishing feature is that command origin appears valid, transmitted from approved apertures using expected parameters, so the first execution event is not a protocol anomaly but a misuse of legitimate command authority obtained through the compromised ground system. | |
| DE-0004 | Masquerading | The adversary presents themselves as an authorized origin so activity appears legitimate across RF, protocol, and organizational boundaries. Techniques include crafting telecommand frames with correct headers, counters, and dictionaries; imitating station “fingerprints” such as Doppler, polarization, timing, and framing; replaying or emulating crosslink identities; and using insider-derived credentials or roles to operate mission tooling. Masquerading can also target metadata, virtual channel IDs, APIDs, source sequence counts, and facility identifiers, so logs and telemetry attribute actions to expected entities. The effect is that commands, file transfers, or configuration changes are processed as if they came from approved sources, reducing scrutiny and delaying detection. | |
| EXF-0007 | Compromised Ground System | The adversary resides in mission ground infrastructure and uses its trusted position to siphon data at scale. With access to operator workstations, mission control servers, baseband/modem chains, telemetry processing pipelines, or archive databases, the attacker can mirror real-time streams, scrape recorder playbacks, export payload products, and harvest procedure logs and command histories. Because exfiltration rides normal paths, file staging areas, data distribution services, cloud relays, or cross-site links, it blends with routine dissemination. Compromise of scheduling tools and pass plans also lets the actor time captures to high-value downlinks and automate bulk extraction without touching the spacecraft. | |
| EXF-0008 | Compromised Developer Site | By breaching development or integration environments (at the mission owner, contractor, or partner), the adversary gains access to source code, test vectors, telemetry captures, build artifacts, documentation, and configuration data, material that is often more complete than flight archives. Beyond theft of intellectual property, the attacker can embed telemetry taps, extended logging, or data “export” features into test harnesses, simulators, or flight builds so that, once fielded, the system produces extra observables or forwards content to non-mission endpoints. This activity typically occurs pre-launch during software production and ATLO, positioning exfiltration mechanisms to activate later in flight. | |