Diversified Architectures

A diversified mission architecture provides a capability through multiple systems, platforms, payloads, orbital regimes, or domains to reduce the mission impact of losing any individual element and increase the range of adversary capabilities required to achieve mission denial. Diversification differs from proliferation in that it employs heterogeneous systems, potentially across different orbits, domains, operators, and technologies, rather than deploying more units of the same design. This heterogeneity imposes asymmetric costs on adversaries: attacking systems across different orbital regimes requires different physical and electronic capabilities for each regime, and kinetic attacks on space assets in diverse orbits carry differentiated collateral debris consequences that increase the political and economic cost of a broad attack campaign. Domain diversification, extending mission capability delivery across space, airborne, and terrestrial layers, further reduces adversary incentive by ensuring that defeating the space layer alone does not deny the end user the underlying capability. Diversification can preserve minimum mission capability following the loss of individual elements when the remaining systems provide sufficient coverage, capacity, interoperability, and operational availability to compensate for the loss.

Sources

https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG

ID: CM0076

Tier: III

Onboard SV CM

Created: 2023/04/22

Last Modified: 2026/08/06

Pre-Operations Government

Acquisition strategies for missions requiring resilience against cyber or physical counterspace threats should evaluate architectural diversification across orbital regimes or domains as a design approach. Resilience analysis should identify the combinations of adversary actions and affected systems required to reduce the mission below defined capability thresholds and compare those results with a concentrated architecture. Requirements should specify the minimum number of independent delivery paths, across space, airborne, and terrestrial domains where applicable, that must remain capable of satisfying minimum mission requirements after defined adversary actions, with each path designed to be independent in its vulnerability to the threat scenarios identified in the mission's threat model. Contract language should require that the diversification architecture be documented as a mission resilience deliverable, including the analysis of adversary capability requirements for each element of the diversified architecture and the cross-domain interoperability requirements that enable seamless capability delivery across the diverse system set. Evaluation criteria should assess offerors' proposed diversification across orbital regimes and domains, the genuine independence of the proposed elements from common failure modes and adversary capabilities, and their demonstrated experience designing interoperable cross-domain mission architectures. Verification should include resilience modeling that evaluates mission performance under simulated attacks tailored to each element of the diversified architecture, confirming that the complementary elements can compensate for the simulated losses within defined operational timelines.

Pre-Operations Developer/Supplier

Diversified architecture design requires early engagement with the full mission ecosystem, as genuine diversification depends on interoperability agreements, data format compatibility, and operational handoff procedures between systems operated by different organizations, any of which may be complex to establish and sustain. The selection of complementary systems across orbits and domains must account for coverage geometry and capacity, ensuring that the alternative systems available when one element is degraded can actually satisfy mission requirements for the users, geographic regions, and operational timelines that the degraded element was serving, rather than providing nominal redundancy that does not map to the actual operational demand. Orbital regime selection for diversification should consider not only the technical coverage and capacity implications of each regime but also the attack capability requirements that different regimes impose on adversaries, recognizing that reaching assets in geostationary orbit (GEO), medium Earth orbit (MEO), and low Earth orbit (LEO) requires different adversary investments and produces different debris consequences that affect the adversary's calculus. Ground system and terminal architectures must support transition between contributing systems within the mission-defined continuity timeline. The transition may be automatic or operator-directed, but required changes to routing, configuration, credentials, or user equipment must be defined and tested before operations. Interoperability standards for cross-domain capability delivery should be established as contractual requirements with all contributing system operators before the diversified architecture enters operations, avoiding the discovery of incompatibilities under operational urgency.

Sustainment & Maintenance Government

Operational management of a diversified architecture requires coordination mechanisms across all contributing system operators, including shared situational awareness of element availability, preplanned capacity reallocation procedures, and tested handoff protocols that can be executed within operationally acceptable timelines when an element is degraded. Interoperability between contributing systems must be continuously validated through periodic cross-system exercises that verify end-to-end capability delivery across the full diversified architecture, confirming that format compatibility, routing, and handoff procedures remain functional as individual systems evolve through software updates and configuration changes. Degradation or loss of a contributing element must trigger assessment of the resulting mission impact. Predetermined capacity reallocation procedures should be executed when needed to maintain required capability, with monitoring confirming that the receiving systems can support the redirected demand without exceeding approved capacity or degrading other critical services. Changes to any contributing system that affect its interoperability with other elements of the diversified architecture must be coordinated across all affected operators before implementation, with joint testing confirming that the change does not disrupt cross-domain capability delivery.

Sustainment & Maintenance Developer/Supplier

Techniques Addressed by Countermeasure

ID		Name	Description
EX-0017		Kinetic Physical Attack	The adversary inflicts damage by physically striking space assets or their supporting elements, producing irreversible effects that are generally visible to space situational awareness. Kinetic attacks in orbit are commonly grouped into direct-ascent engagements, launched from Earth to intercept a target on a specific pass, and co-orbital engagements, in which an on-orbit vehicle maneuvers to collide with or detonate near the target. Outcomes include structural breakup, loss of attitude control, sensor or antenna destruction, and wholesale mission termination; secondary effects include debris creation whose persistence depends on altitude and geometry. Because launches and on-orbit collisions are measurable, these actions tend to be more attributable and offer near–real-time confirmation of effect compared to non-kinetic methods.
	.01	Direct Ascent ASAT	A direct-ascent ASAT is often the most commonly thought of threat to space assets. It typically involves a medium- or long-range missile launching from the Earth to damage or destroy a satellite in orbit. This form of attack is often easily attributed due to the missile launch which can be easily detected. Due to the physical nature of the attacks, they are irreversible and provide the attacker with near real-time confirmation of success. Direct-ascent ASATs create orbital debris which can be harmful to other objects in orbit. Lower altitudes allow for more debris to burn up in the atmosphere, while attacks at higher altitudes result in more debris remaining in orbit, potentially damaging other spacecraft in orbit.* *https://aerospace.csis.org/aerospace101/counterspace-weapons-101
	.02	Co-Orbital ASAT	A co-orbital ASAT uses a spacecraft already in space to conduct a deliberate collision or near-field detonation. After insertion, often well before any hostile action, the vehicle performs rendezvous and proximity operations to achieve the desired relative geometry, then closes to impact or triggers a kinetic or explosive device. Guidance relies on relative navigation (optical, lidar, crosslink cues) and precise timing to manage closing speeds and contact angle. Compared with direct-ascent shots, co-orbital approaches can loiter, shadow, or “stalk” a target for extended periods, masking as inspection or servicing until the terminal maneuver. Effects include mechanical disruption, fragmentation, or mission-ending damage, with debris characteristics shaped by the chosen altitude, closing velocity, and collision geometry.

Space Threats Addressed by Countermeasure

ID	Description
SV-AC-5	Proximity operations (i.e., grappling satellite)
SV-MA-8	Payload (or other component) is told to constantly sense or emit or run whatever mission it had to the point that it drained the battery constantly / operated in a loop at maximum power until the battery is depleted.
SV-AV-6	Complete compromise or corruption of running state
SV-MA-5	Not being able to recover from cyberattack
SV-AV-1	Communications system jamming resulting in denial of service and loss of availability and data integrity
SV-AV-7	The TT&C is the lead contributor to satellite failure over the first 10 years on-orbit, around 20% of the time. The failures due to gyro are around 12% between year one and 6 on-orbit and then ramp up starting around year six and overtake the contributions of the TT&C subsystem to satellite failure. Need to ensure equipment is not counterfeit and the supply chain is sound.
SV-MA-1	Space debris colliding with the spacecraft
SV-MA-6	Not planning for security on SV or designing in security from the beginning
SV-SP-5	Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused}

Sample Requirements

SPARTA ID	Requirement	Rationale/Additional Guidance/Notes
SPR-28	The [spacecraft] shall provide the capability to enter the platform into a known good, operational cyber-safe mode from a tamper-resistant, configuration-controlled (“gold”) image that is authenticated as coming from an acceptable supplier, and has its integrity verified. The [spacecraft] shall refresh only from cryptographically authenticated [organization]-approved sources.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4(3),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-13,SI-17}	Cyber-safe mode is an operating mode of a spacecraft during which all nonessential systems are shut down and the spacecraft is placed in a known good state using validated software and configuration settings. Within cyber-safe mode authentication and encryption should still be enabled. The spacecraft should be capable of reconstituting firmware and SW functions to preattack levels to allow for the recovery of functional capabilities. This can be performed by self-healing, or the healing can be aided from the ground. However, the spacecraft needs to have the capability to replan, based on available equipment still available after a cyberattack. The goal is for the vehicle to resume full mission operations. If not possible, a reduced level of mission capability should be achieved.
SPR-29	The [spacecraft] shall enter cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable.{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-17}
SPR-30	The [spacecraft] shall fail to a known secure state for failures during initialization, and aborts preserving information necessary to return to operations in failure.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(24),SC-24,SI-13,SI-17}
SPR-31	The [spacecraft] shall fail securely to a secondary device in the event of an operational failure of a primary boundary protection device (i.e., crypto solution).{SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2}{CP-13,SA-8(19),SA-8(24),SC-7(18),SI-13,SI-13(4)}	If a primary boundary protection device fails, the spacecraft must not revert to insecure operation. Secure failover ensures continuity of confidentiality and integrity protections. This prevents adversaries from inducing failure states to bypass encryption. Redundancy strengthens mission resilience.
SPR-32	The [spacecraft] shall provide or support the capability for recovery and reconstitution to a known state after a disruption, compromise, or failure.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-4(4),CP-10,CP-10(4),CP-10(6),CP-13,IR-4,IR-4(1),SA-8(16),SA-8(19),SA-8(24)}
SPR-62	The [spacecraft] shall enter a cyber-safe mode when conditions that threaten the platform are detected, enters a cyber-safe mode of operation with restrictions as defined based on the cyber-safe mode.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4,IR-4(1),IR-4(3),PE-10,RA-10,SA-8(16),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-13,SI-17}	Cyber-safe mode provides a deterministic fallback posture when compromise or anomalous conditions threaten mission integrity. Restricting non-essential functions reduces attack surface and prevents further propagation of malicious activity. Defined restrictions ensure predictable behavior under cyber stress conditions. This supports survivability and controlled recovery rather than uncontrolled degradation.
SPR-74	The [organization] shall define the security safeguards that are to be automatically employed when integrity violations are discovered.{SV-IT-2}{CP-2,SA-8(21),SI-3,SI-4(7),SI-4(12),SI-7(5),SI-7(8)}	Predefined safeguards ensure consistent and timely response to detected integrity violations. Ad hoc response increases uncertainty and recovery time. Automated actions may include isolation, reconstitution from gold images, or transition to cyber-safe mode. Defined response paths improve resilience and reduce operator burden during crisis.
SPR-99	The [spacecraft] shall recover from cyber-safe mode to mission operations within 20 minutes.{SV-MA-5}{CP-2(3),CP-2(5),IR-4,SA-8(24)}	Upon conclusion of addressing the threat, the system should be capable of recovering from the minimal survival mode back into a mission-ready state within defined timelines. The intent is to define the timelines and the capability to return back to mission operations.
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-108	The [organization] shall define the resources to be allocated to protect the availability of system resources.{SV-AC-6}{CP-2(2),SC-6}	Availability protections require deliberate allocation of compute, power, bandwidth, and monitoring capacity. Without predefined resource allocation, defensive measures may compete with mission operations. Planning ensures resilience mechanisms do not degrade core functionality. This supports continuity during denial-of-service conditions.
SPR-229	The [organization] shall protect documentation and Controlled Unclassified Information (CUI) as required, in accordance with the risk management strategy.{SV-CF-3,SV-SP-4,SV-SP-10}{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-10,SC-8(1),SC-28(3),SI-12}	Documentation may reveal architecture details exploitable by adversaries. Proper handling prevents leakage. Protection of CUI supports regulatory compliance. Information governance complements technical controls.
SPR-230	The [organization] shall identify and properly classify mission sensitive design/operations information and access control shall be applied in accordance with classification guides and applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-CF-3,SV-AV-5}{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-8(19),SC-8(1),SC-28(3),SI-12}	* Mission sensitive information should be classified as Controlled Unclassified Information (CUI) or formally known as Sensitive but Unclassified. Ideally these artifacts would be rated SECRET or higher and stored on classified networks. Mission sensitive information can typically include a wide range of candidate material: the functional and performance specifications, the RF ICDs, databases, scripts, simulation and rehearsal results/reports, descriptions of uplink protection including any disabling/bypass features, failure/anomaly resolution, and any other sensitive information related to architecture, software, and flight/ground /mission operations. This could all need protection at the appropriate level (e.g., unclassified, SBU, classified, etc.) to mitigate levels of cyber intrusions that may be conducted against the project’s networks. Stand-alone systems and/or separate database encryption may be needed with controlled access and on-going Configuration Management to ensure changes in command procedures and critical database areas are tracked, controlled, and fully tested to avoid loss of science or the entire mission.
SPR-231	The [organization] shall distribute documentation to only personnel with defined roles and a need to know.{SV-CF-3,SV-AV-5}{CM-12,CP-2,SA-5,SA-10}	Least privilege and need to know should be employed with the protection of all documentation. Documentation can contain sensitive information that can aid in vulnerability discovery, detection, and exploitation. For example, command dictionaries for ground and space systems should be handles with extreme care. Additionally, design documents for missions contain many key elements that if compromised could aid in an attacker successfully exploiting the system.
SPR-232	The [organization] shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design.{SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4}{CP-2,CP-2(8),PL-7,PM-11,PM-30(1),RA-3(1),RA-9,SA-8(9),SA-8(11),SA-8(25),SA-12,SA-14,SA-15(3),SC-7(29),SR-1}	During SCRM, criticality analysis will aid in determining supply chain risk. For mission critical functions/components, extra scrutiny must be applied to ensure supply chain is secured.
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-259	The [organization] shall develop an incident response and forensics plan that covers the spacecrafts.{SV-MA-5}{CP-2,IR-1,IR-3,IR-3(2),IR-4(12),IR-4(13),IR-8,SA-15(10),SI-4(24)}	A structured response plan enables coordinated containment and recovery. Forensics planning ensures evidence preservation. Defined procedures reduce confusion during crisis. Incident readiness enhances resilience.
SPR-292	The [organization] shall ensure that role-based security-related training is provided to personnel with assigned security roles and responsibilities: (i) before authorizing access to the system or performing assigned duties; (ii) when required by system changes; and (iii) at least annually thereafter.{SV-AC-4}{AT-3,CP-2}	Personnel must understand role-specific responsibilities. Tailored training reduces misuse. Continuous reinforcement maintains awareness. Human factors are central to defense.
SPR-293	The [organization] shall employ techniques to limit harm from potential adversaries identifying and targeting the [organization]s supply chain.{SV-SP-4,SV-SP-5,SV-SP-6}{CP-2,PM-30,SA-9,SA-12(5),SC-38,SR-3,SR-3(1),SR-3(2),SR-5(2)}	Adversaries often exploit supplier relationships. Protective measures reduce reconnaissance and manipulation. Supply chain resilience strengthens mission integrity. Proactive defense mitigates systemic exposure.
SPR-357	The [organization] defines the security safeguards to be employed to protect the availability of system resources.{CP-2(2),SC-6,SI-13,SI-17}
SPR-358	The [organization] shall plan for the transfer of essential ground-segment functions to alternate processing/storage site(s) (e.g.secondary ground terminal) with minimal or no loss of operational continuity until the primary ground terminal is fully restored (if the architecture supports it).{SV-MA-5}{CP-2(6)}	Redundant ground infrastructure enhances availability. Preplanning reduces disruption during outage. Distributed architecture strengthens resilience. Continuity planning supports mission assurance.
SPR-359	The [organization] shall plan for the transfer of essential space-segment functions to alternate processing platforms (e.g.proliferated/distributed constellations) with minimal or no loss of operational continuity until the primary node is fully restored (if the architecture supports it).{SV-MA-5}{CP-2(6)}	Proliferated or distributed space assets reduce single-node risk. Functional transfer ensures mission continuity. Planning anticipates hostile or environmental disruptions. Resilient architectures improve survivability.
SPR-461	The [spacecraft] shall fail over mission critical processing to a redundant onboard compute element while maintaining authentication, authorization, and cryptographic protections.{SV-MA-5}{CP-2(6),CP-10}	Redundant compute without preserved security controls introduces new risk. Failover must maintain authentication and cryptographic state. Secure redundancy prevents availability from undermining integrity. Resilience must not weaken protection.
SPR-462	The [spacecraft] shall support delegation of temporary data storage to [organization]-authorized alternate nodes or spacecraft and shall preserve confidentiality, integrity, and access controls for the delegated data.{SV-CF-1,SV-CF-2,SV-AC-1}{CP-2(6),SC-28,AC-3}	Delegated storage or processing expands trust boundaries. Maintaining CIA protections during delegation prevents exposure. Secure federation supports constellation-based architectures. Controlled delegation strengthens distributed resilience.
SPR-463	The [spacecraft] shall maintain configuration and cryptographic synchronization required to activate alternate processing or storage and shall verify the alternate before activation.{SV-SP-9,SV-AC-3}{CP-2(6),CM-2}	Activation of alternate nodes requires synchronized keys and configurations. Unsynchronized failover risks data corruption or exposure. Verification before activation prevents propagation of compromised states. Coordinated readiness supports secure recovery.
SPR-538	The [spacecraft] shall budget CPU/power/memory for security functions (crypto, logging, verification), implement graceful degradation (e.g., summarize logs, throttle verification) that preserves TT&C and safing, and expose telemetry showing throttling decisions and residual capacity.{SV-AV-1,SV-DCO-1}{PE-9,SA-8(8),SC-6,CP-2}	Security must not starve essential TT&C. Explicit resource budgeting ensures sustained enforcement. Graceful degradation preserves mission priority. Telemetry visibility supports oversight.

Diversified Architectures

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