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.
Acquisition requirements for prepared or cooperative spacecraft intended to receive OSAM services should mandate dual-authorization of servicer spacecraft as a threshold mission security requirement, with specifications covering the authentication factors required of the servicing spacecraft, the independent authorization process required from both the ground station and the serviced asset, and the conditions under which authorization may be granted or withheld. For legacy, disabled, unprepared, or non-cooperative clients that cannot independently authorize servicing, the program must document that CM0065 cannot be fully implemented and define compensating ground authorization, proximity-operations, monitoring, and interface-protection controls.
For cooperative clients, authorization by the serviced asset must be technically enforced by a trusted onboard mechanism capable of validating the required servicer identity and authorization state before enabling client-controlled servicing functions. Failure or absence of authorization must prevent activation of designated docking, data, power, fluid, robotic, command, maintenance, or other servicing interfaces and must place the client in the mission-approved hold, inhibit, or safe configuration. This capability does not by itself prevent an unauthorized vehicle from entering physical proximity. Contract language should require that the OSAM authorization architecture be documented as a security engineering deliverable before servicing mission design is finalized, including the authentication mechanisms, the communication protocols used to exchange authorization between the servicing spacecraft, the serviced asset, and the ground station, and the procedures for handling authorization failures or contested engagements. Evaluation criteria should assess offerors' proposed OSAM authorization architecture, their experience with proximity operations security, and their demonstrated approach to implementing multi-factor authentication under the communication constraints of the on-orbit servicing environment. Verification should include scenario-based testing that confirms dual-authorization requirements are enforced and that simulated spoofed or unauthorized servicer attempts are correctly rejected by both the ground station and the serviced asset.
Pre-Operations Developer/Supplier
For cooperative servicing, the servicing and serviced-asset missions must jointly define the authentication, authorization, communication, interface-control, fault-response, and operational-state architecture. The parties must establish interoperable trust anchors, credential-validation methods, protocol profiles, data formats, authorization semantics, and interface behavior. The missions need not share a common credential authority or cryptographic key hierarchy, but each must be able to validate the other’s approved credentials and authorization messages through an agreed trust arrangement. Servicer entity authentication must use a cryptographically protected mechanism that establishes the identity of the servicing spacecraft and provides message integrity, freshness, and replay protection. The mission should corroborate that identity using independent mission attributes or sensor observations. These contextual observations strengthen confidence and authorization decisions but must not automatically be characterized as separate authentication factors. Human operators accessing systems that issue OSAM approvals must use mission-approved multi-factor authentication. The authorization architecture must function under the mission’s anticipated ground-contact availability, communication delay, proximity-link characteristics, autonomy level, and fault conditions. Required approvals must be completed before the servicer crosses the applicable authorization-controlled hold point or before the client enables the associated servicing interface. If authorization cannot be completed, validated, or synchronized within the available opportunity, the vehicles must remain at the approved hold point or execute the defined retreat or abort response rather than implicitly proceeding. Authorization messages and state must be authenticated, integrity-protected, replay-resistant, and bound to the identities of the servicer and client, the approved service, mission phase or hold point, permitted interfaces and actions, applicable trajectory or proximity constraints, and a defined validity period or event sequence. Changes to these bound conditions, expiration, state disagreement, communication interruption, or resumption after an abort or extended hold must invalidate the affected authorization or require re-authorization. Failure behavior must withhold client cooperation and invoke the mission-approved hold, retreat, inhibit, or safe response. The authentication credentials and protocols used for OSAM authorization should be treated as sensitive mission security information and protected under the program's information handling requirements from design through operations.
Sustainment & Maintenance Government
Operational OSAM authorization management requires that the authentication credentials and cryptographic material used by both the serviced asset and the ground station be maintained with active lifecycle management, including rotation at defined intervals and immediate revocation and replacement if compromise is suspected, so that the authorization infrastructure remains trustworthy throughout the mission's operational period. Pre-servicing checklists must include explicit verification steps confirming that the dual-authorization mechanism is operational and that both the ground station and the serviced asset are prepared to execute their respective authorization roles before the servicing spacecraft is permitted to begin approach. Authorization logs should be monitored for anomalies, including unexpected authorization requests, repeated failed authentication attempts from a servicing spacecraft, and authorization exchanges that do not follow the expected protocol sequence, with each anomaly investigated before the servicing engagement proceeds. Post-servicing reviews should include assessment of the authorization exchange record to confirm that dual-authorization was correctly executed and that no anomalies occurred during the servicing engagement that could indicate unauthorized access or activities during the servicing window.
Sustainment & Maintenance Developer/Supplier
Operational OSAM authorization management requires that the authentication credentials and cryptographic material used by both the serviced asset and the ground station be maintained with active lifecycle management, including rotation at defined intervals and immediate revocation and replacement if compromise is suspected, so that the authorization infrastructure remains trustworthy throughout the mission's operational period. Pre-servicing checklists must include explicit verification steps confirming that the dual-authorization mechanism is operational and that both the ground station and the serviced asset are prepared to execute their respective authorization roles before the servicing spacecraft is permitted to begin approach. Authorization logs should be monitored for anomalies, including unexpected authorization requests, repeated failed authentication attempts from a servicing spacecraft, and authorization exchanges that do not follow the expected protocol sequence, with each anomaly investigated before the servicing engagement proceeds. Post-servicing reviews should include assessment of the authorization exchange record to confirm that dual-authorization was correctly executed and that no anomalies occurred during the servicing engagement that could indicate unauthorized access or activities during the servicing window.
Docking, berthing, or short-duration attach events create high-trust, high-bandwidth connections between vehicles. During these operations, automatic sequences verify latches, exchange status, synchronize time, and enable umbilicals that carry data and power; maintenance tools may also push firmware or tables across the interface. An attacker positioned on the visiting vehicle can exploit these handshakes and service channels to inject commands, transfer files, or access bus gateways on the host. Because many actions are expected “just after dock,” malicious traffic can ride the same procedures that commission the interface, allowing lateral movement from the visiting craft into the target spacecraft’s C&DH, payload, or support subsystems.
Three main parts of S/C. CPU, memory, I/O interfaces with parallel and/or serial ports. These are connected via busses (i.e., 1553) and need segregated. Supply chain attack on CPU (FPGA/ASICs), supply chain attack to get malware burned into memory through the development process, and rogue RTs on 1553 bus via hosted payloads are all threats. Security or fault management being disabled by non-mission critical or payload; fault injection or MiTM into the 1553 Bus - China has developed fault injector for 1553 - this could be a hosted payload attack if payload has access to main 1553 bus; One piece of FSW affecting another. Things are not containerized from the OS or FSW perspective;
Attempting access to an access-controlled system resulting in unauthorized access
Sample Requirements
SPARTA ID
Requirement
Rationale/Additional Guidance/Notes
SPR-3
The [spacecraft] shall enforce approved authorizations for controlling the flow of information within the platform and between interconnected systems so that information does not leave the platform boundary unless it is encrypted. Flow control shall be implemented in conjunction with protected processing domains, security‑policy filters with fully enumerated formats, and a default‑deny communications baseline.{SV-AC-6}{AC-3(3),AC-3(4),AC-4,AC-4(2),AC-4(6),AC-4(21),CA-3,CA-3(6),CA-3(7),CA-9,IA-9,SA-8(19),SC-8(1),SC-16(3)}
Spacecraft operate in constrained and deterministic environments where uncontrolled data flows can enable data exfiltration, cross-domain leakage, or lateral movement between subsystems. Enforcing approved authorizations with enumerated formats and a default-deny posture ensures only explicitly permitted communications occur. Encryption enforcement at platform boundaries prevents unauthorized disclosure of telemetry or state information.