Protocol Update / Refactoring

Communication and data exchange protocols governing spacecraft, ground system, and inter-system interfaces may contain specification-level vulnerabilities that cannot be resolved through implementation hardening alone, requiring updates to or refactoring of the protocol itself to eliminate the underlying weakness. Protocol vulnerabilities may arise from design flaws in the original specification, from advances in adversarial capability that render previously adequate security assumptions insufficient, or from emerging threats such as quantum computing that threaten the cryptographic primitives upon which protocol security depends. Protocol update or refactoring encompasses the deliberate modification of the rules, formats, and procedures governing system communications to address known vulnerabilities, improve security properties, or maintain adequate protection against the evolving threat environment over the mission's operational lifetime. Because space system protocols are often tightly coupled to hardware interfaces, flight software implementations, and ground system processing pipelines, protocol changes carry significant integration risk and must be managed through rigorous engineering change processes; this complexity makes proactive protocol security assessment and planned update capability more cost-effective than reactive refactoring under operational urgency.

Sources

CCSDS 130.0-G-4 — Overview of Space Communications Protocols

CCSDS 350.0-G-3 — The Application of Security to CCSDS Protocols

https://csrc.nist.gov/glossary/term/protocol

https://www.feistyduck.com/ssl-tls-and-pki-history/

ID: CM0072

Tier: I

Onboard SV CM Ground CM

Created: 2022/12/08

Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should mandate formal protocol security assessment as part of the system security engineering process for all communications and data exchange protocols used in spacecraft and ground systems, with assessments identifying specification-level vulnerabilities, cryptographic primitive adequacy over the projected mission lifetime, and susceptibility to emerging threats including quantum computing-enabled attacks on asymmetric cryptography. Requirements should address cryptographic agility as a design requirement, specifying that protocol implementations support the replacement of cryptographic algorithms without requiring full protocol or software redesign, enabling the mission to adapt to algorithm deprecations or quantum-related threats without a disruptive system-wide refactoring effort. Contract language should require that protocol security assessments be documented as controlled deliverables and that the update or refactoring procedures for each protocol be documented and verified before the mission enters operations, ensuring that the capability to implement protocol changes exists before it is operationally needed. Evaluation criteria should assess offerors' proposed protocols for known specification vulnerabilities, their cryptographic agility design approach, and their demonstrated experience managing protocol updates in space systems with long operational lifetimes. Verification should demonstrate the approved cryptographic transition process under representative operating conditions, including the period in which communicating systems may support different protocol or algorithm versions. Testing must confirm that the transition preserves required communications capability or follows the approved outage and recovery plan and that an adversary cannot force continued use of a deprecated algorithm.

Pre-Operations Developer/Supplier

Protocol selection during system design must include security evaluation of the candidate protocol's specification, examining it for known vulnerabilities, deprecated security mechanisms, and cryptographic dependencies that may become inadequate over the projected mission lifetime, with protocols carrying known unresolved specification vulnerabilities avoided or accompanied by a documented risk acceptance and compensating control plan. Cryptographic agility must be designed into protocol implementations from the outset so that approved cryptographic algorithms and parameter sets can be replaced without redesigning the complete protocol architecture. The design must account for changes in key and message sizes, processing and memory requirements, protocol versioning, interoperability, and protection against unauthorized downgrade. Externalizing algorithm identifiers and parameters is useful but does not guarantee that an algorithm transition can be performed solely as a configuration change. Protocol interface control documents must be maintained as version-controlled artifacts with explicit security change history, ensuring that protocol updates are tracked with the same rigor as software updates and that all systems exchanging data under the protocol are updated consistently to avoid version mismatch vulnerabilities. Protocol refactoring plans must define the testing, deployment, compatibility, recovery, and operational transition approach before an urgent change is required. Rollback may be included only when the prior protocol version remains approved for use; recovery procedures must not silently restore a version containing an unacceptable vulnerability or deprecated cryptographic mechanism. Protocol security assessments should be repeated at defined intervals during the development lifecycle, as the threat environment may evolve between initial design and launch in ways that affect the security adequacy of selected protocols.

Sustainment & Maintenance Government

Operational protocol management requires active monitoring of vulnerability disclosures affecting the protocols in use across the mission, including both implementation-level vulnerabilities in the software that processes the protocol and specification-level vulnerabilities that affect all compliant implementations regardless of software quality. When a protocol vulnerability is disclosed, the mission team must assess whether the vulnerability is exploitable in the mission's specific deployment context, considering the access an adversary would need to exploit the flaw and the compensating controls already in place, before deciding whether an urgent protocol update is required or whether existing controls provide adequate interim protection. Protocol updates must use a coordinated transition plan covering all communicating systems. Where simultaneous deployment is not operationally feasible, the protocol must support a bounded compatibility period or another approved transition mechanism. Version negotiation and fallback behavior must be protected so that an adversary cannot force use of the older protocol after the updated version is available. Post-quantum transition planning must begin during acquisition and system design for missions whose operational lifetime or protected-data lifetime extends into applicable migration periods. Sustainment activities must maintain the cryptographic inventory, reassess transition priorities, and execute the approved migration plan as standards, requirements, and mission conditions evolve.

Sustainment & Maintenance Developer/Supplier

Techniques Addressed by Countermeasure

ID		Name	Description
REC-0005		Eavesdropping	Adversaries seek to capture mission communications across terrestrial networks and RF/optical links to reconstruct protocols, extract telemetry, and derive operational rhythms. Collection is most often passive, but may be semi-passive or actively elicited, where the adversary transmits probes or crafted exchanges to provoke identifiable responses from the target rather than waiting to observe them. On networks, packet captures, logs, and flow data from ground stations, mission control, and cloud backends can expose service boundaries, authentication patterns, and automation. In the RF domain, wideband recordings, spectrograms, and demodulation of TT&C and payload links, spanning VHF/UHF through S/L/X/Ka and, increasingly, optical, enable identification of modulation/coding, framing, and beacon structures. Even when links are encrypted, metadata such as carrier plans, symbol rates, polarization, and cadence can support traffic analysis, timing attacks, or selective interference. Community capture networks and open repositories amplify the reach of a modest adversary.
	.01	Uplink Intercept Eavesdropping	Uplink reconnaissance focuses on capturing the command path from ground to spacecraft to learn telecommand framing, authentication fields, timing, and anti-replay behavior. Valuable artifacts include emission designators, symbol rates, polarization sense, Doppler profiles, and any preambles or ranging tones that gate command acceptance. Even if payload and TT&C share spectrum, their authentication postures often differ, knowledge an adversary can exploit. Partial captures, console screenshots, or training recordings reduce the effort needed to build an SDR pipeline that “looks right” on the air. Where missions authenticate without encrypting the uplink, traffic analysis can reveal command cadence and maintenance windows.
	.02	Downlink Intercept	Downlink collection aims to harvest housekeeping telemetry, event logs, ephemerides, payload data, and operator annotations that reveal system state and procedures. Even when payload content is encrypted, ancillary channels (beacons, health/status, low-rate engineering downlink) can disclose mode transitions, battery and thermal margins, safing events, and next-pass predictions. Community ground networks and public dashboards may inadvertently provide stitched datasets that make trend analysis trivial. Captured framing and coding parameters also help an adversary build testbeds and refine timing for later actions.
	.03	Proximity Operations	In proximity scenarios, an adversary platform (or co-located payload) attempts to observe emissions and intra-vehicle traffic at close range, RF side-channels, optical/lasercom leakage, and, in extreme cases, electromagnetic emanations consistent with TEMPEST/EMSEC concerns. Physical proximity can expose harmonics, intermodulation products, local oscillators, and bus activity that are undetectable from the ground, enabling reconstruction of timing, command acceptance windows, or even limited protocol content. In hosted-payload or rideshare contexts, a poorly segregated data path may permit passive observation of TT&C gateways, crosslinks, or payload buses.
EXF-0003		Signal Interception	The adversary captures mission traffic in transit, on ground networks or over the space link, so that payload products, housekeeping, and command/ack exchanges can be reconstructed offline. Vantage points include tapped ground LANs/WANs between MOC and stations, baseband interfaces (IF/IQ), RF/optical receptions within the antenna field of view, and crosslink monitors. Depending on protection, the haul ranges from plaintext frames to encrypted bitstreams whose headers, rates, and schedules still yield valuable context (APIDs, VCIDs, pass timing, file manifest cues). Intercepted sessions can guide later replay, cloning, or targeted downlink requests.
	.01	Uplink Exfiltration	Here the target is command traffic from ground to space. By receiving or tapping the uplink path, the adversary collects telecommand frames, ranging/acquisition exchanges, and any file or table uploads. If confidentiality is weak or absent, opcode/argument content, dictionaries, and procedures become directly readable; even when encrypted, session structure, counters, and acceptance timing inform future command-link intrusion or replay. Captured material can reveal maintenance windows, contingency dictionaries, and authentication schemes that enable subsequent exploitation.
	.02	Downlink Exfiltration	The attacker records spacecraft-to-ground traffic, real-time telemetry, recorder playbacks, payload products, and mirrored command sessions, to obtain mission data and health/state information. With sufficient signal quality and protocol knowledge, frames and packets are demodulated and extracted for offline use; where protection exists only on uplink or is inconsistently applied, downlink content may still be in clear. Downlinked command echoes, event logs, and file catalogs can expose internal activities and aid follow-on targeting while the primary objective remains data capture at scale.

ID	Description
SV-AC-7	Weak communication protocols. Ones that don't have strong encryption within it

Sample Requirements

SPARTA ID	Requirement	Rationale/Additional Guidance/Notes
SPR-91	The [spacecraft] shall prevent the installation of Flight Software without verification that the component has been digitally signed.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-9}{CM-3,CM-3(8),CM-5,CM-5(3),CM-14,SA-8(8),SA-8(31),SA-10(2),SI-3,SI-7(12),SI-7(15)}	Requiring digital signature verification before installing flight software prevents unauthorized, malicious, or tampered code from being introduced into the spacecraft environment. Software supply chain compromise is a high-impact attack vector that can result in persistent control or loss of mission. Cryptographic validation ensures only approved and trusted binaries are executed. This maintains integrity of the trusted computing baseline.
SPR-107	The [spacecraft] shall have multiple uplink paths {SV-AV-1}{CP-8,CP-11,SA-8(18),SC-5,SC-47}	Redundant uplink paths preserve command capability during jamming, interference, or subsystem failure. Availability is a core mission assurance objective. Diverse communication channels reduce single-point failure risk. This enhances resiliency in contested RF environments.
SPR-245	The [organization] shall define processes and procedures to be followed when integrity verification tools detect unauthorized changes to software, firmware, and information.{SV-IT-2}{CM-3,CM-3(1),CM-3(5),CM-5(6),CM-6,CP-2,IR-6,IR-6(2),PM-30,SC-16(1),SC-51,SI-3,SI-4(7),SI-4(24),SI-7,SI-7(7),SI-7(10)}	Predefined response procedures reduce reaction time. Clear escalation paths improve containment. Consistent handling prevents confusion during incidents. Preparedness strengthens resilience.
SPR-257	The [organization] shall analyze changes to the spacecraft to determine potential security impacts prior to change implementation.{SV-MA-6,SV-SP-9}{CM-4,CM-3,CM-3(2),CM-3(7),CM-4(2),SA-10}	Changes to spacecraft configuration may introduce unintended vulnerabilities. Pre-implementation impact analysis prevents security regression. Structured review ensures modifications align with risk tolerance. Change control supports mission assurance.
SPR-265	The [organization] shall report identified systems or system components containing software affected by recently announced cybersecurity-related software flaws (and potential vulnerabilities resulting from those flaws) to [organization] officials with cybersecurity responsibilities.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-11}{IR-6,IR-6(2),SI-2,SI-3,SI-4(12),SR-4(4)}	Rapid reporting of vulnerable components enables proactive remediation. Awareness of newly disclosed flaws prevents exploitation. Coordination ensures mission-wide response. Visibility reduces systemic risk.
SPR-266	The [organization] shall determine the vulnerabilities/weaknesses that require remediation, and coordinate the timeline for that remediation, in accordance with the analysis of the vulnerability scan report, the mission assessment of risk, and mission needs.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-5,CM-3,RA-5,RA-7,SI-3,SI-3(10)}	Not all vulnerabilities carry equal mission impact. Risk-informed prioritization ensures critical flaws are addressed first. Coordinated timelines balance mission needs with security posture. Structured remediation strengthens governance.
SPR-320	The [organization] shall develop and document program-specific configuration management policies and procedures for the hardware and software for the spacecraft. {SV-SP-9,SV-MA-6}{CM-1,CM-3,CM-5(6),SA-10,SA-10(3)}	Clear configuration governance prevents unauthorized modification. Policy-backed processes ensure consistency. Lifecycle control supports traceability. Managed change reduces mission risk.
SPR-328	The [organization] shall ensure any update to on-board software, memory, or stored procedures has met high assurance standards before execution. {SV-SP-9,SV-SP-4}{AC-3(2),CM-3,SA-8(8),SA-8(31),SA-10(2),SR-4(4)}	On-orbit updates carry significant risk if not validated. High assurance standards prevent unauthorized or corrupted uploads from executing. Structured validation protects system integrity. Update governance reduces mission-ending configuration errors.
SPR-331	The [organization] shall test software and firmware updates related to flaw remediation for effectiveness and potential side effects on mission systems in a separate test environment before installation.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-3,CM-3(1),CM-3(2),CM-4(1),CM-4(2),CM-10(1),SA-8(31),SA-11(9),SI-2,SI-3,SI-3(10),SI-7(10),SI-7(12),SR-5(2)}	This requirement is focused on software and firmware flaws. If hardware flaw remediation is required, refine the requirement to make this clear.
SPR-345	The [organization] shall update the inventory of spacecraft components as an integral part of component installations, removals, and spacecraft updates.{SV-MA-4,SV-SP-4}{CM-8(1),CA-7,CM-2,CM-3}	Accurate inventory enables vulnerability tracking and incident response. Lifecycle updates prevent undocumented changes. Asset visibility strengthens security management. Configuration awareness reduces blind spots.
SPR-393	The [organization] shall confirm that the operational spacecrafts correspond to the baseline configuration. {SV-SP-9,SV-SP-4}{CM-2,CM-3,CM-3(7),CM-4(2),CM-6,SA-10}	Configuration drift undermines trust and auditability. Confirming alignment ensures deployed assets reflect approved design. Baseline validation supports recovery and compliance. Continuous verification reduces unknown risk.
SPR-401	The [organization] shall correct reported cybersecurity-related information system flaws.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SI-2}	* Although this requirement is stated to specifically apply to cybersecurity-related flaws, the Program office may choose to broaden it to all SV flaws. * This requirement is allocated to the Program, as it is presumed, they have the greatest knowledge of the components of the system and when identified flaws apply.
SPR-402	The [organization] shall identify, report, and coordinate correction of cybersecurity-related information system flaws.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SI-2}	Centralized reporting ensures timely remediation. Coordinated correction prevents repeated exposure. Documentation strengthens audit traceability. Rapid flaw management reduces exploitation window.
SPR-526	The [organization] shall tie go/no‑go authorizations to verified artifacts (flatsat/twin results, signed images, key ceremonies) and define how authorization boundaries adjust under contingency conditions; evidence shall be captured for A&A.{SV-MA-6,SV-SP-9}{CA-1,PL-2,CM-3}	Flight decisions must rely on validated artifacts. Evidence capture strengthens compliance. Contingency adjustments must remain controlled. Governance alignment supports mission safety.
SPR-528	The [organization] shall package each flight change (software, bitstreams, configuration tables) with a signed manifest, precondition checks (mode, power/thermal, link), explicit hold/commit points, and resumable procedures across AOS/LOS; the [spacecraft] shall enforce manifest checks prior to activation.{SV-SP-9,SV-IT-2}{CM-3,CM-3(2),SI-7,SA-10}	Manifest enforcement ensures integrity prior to activation. Precondition checks prevent unsafe changes. Resumable logic supports space contact constraints. Structured packaging strengthens update security.
SPR-529	The [organization] shall define freeze windows around launch/maneuvers/high‑risk events, specify exception criteria and approvers, and require chunking, rate limits, checksum/signature gates, and telemetry cues that confirm final state when changes occur within a freeze.{SV-MA-6,SV-SP-9}{CM-3,CM-3(5),CM-5}	Operational stability requires disciplined change control. Freeze periods reduce compounding risk. Defined exceptions preserve agility. Structured boundaries protect mission safety.

Protocol Update / Refactoring

Sources

Pre-Operations Government

Pre-Operations Developer/Supplier

Sustainment & Maintenance Government

Sustainment & Maintenance Developer/Supplier

NIST Rev5 Controls

D3FEND Techniques

D3FEND Artifacts

ISO 27001

NASA Best Practice Guide

ESA Space Shield Mitigation

Related MITRE EMB3D Mitigations

Related CSF 2.0

Related BSI Security Measures

Techniques Addressed by Countermeasure

Space Threats Addressed by Countermeasure

Sample Requirements