The SPARTA Matrix: A Complete Guide to Space System Attack Tactics, Techniques, and Sub-Techniques

Key Takeaways

• SPARTA v3.2 maps 9 tactics, 85+ techniques, and hundreds of sub-techniques targeting spacecraft
• The framework spans cyber intrusions, electronic warfare, and kinetic counterspace methods
• Countermeasures, navigator tools, and D3FEND mappings make SPARTA actionable for defenders

What the Aerospace Corporation Built and Why

On March 11, 2026, The Aerospace Corporation released version 3.2 of the Space Attack Research and Tactic Analysis (SPARTA) matrix, updating a framework that had quietly become one of the most consequential documents in commercial and government space security. SPARTA didn’t emerge from a theoretical exercise. It was built to solve a specific, practical problem: the space industry had no shared, unclassified vocabulary for discussing how satellites and their supporting systems could be attacked. Without a common language, engineers at different organizations talked past each other. Threat briefings from government agencies often relied on classified channels, leaving commercial operators without the context they needed to build secure systems. SPARTA changed that.

The project draws direct inspiration from MITRE ATT&CK, the adversarial tactics, techniques, and procedures (TTP) framework that transformed enterprise cybersecurity by giving defenders and attackers a shared taxonomy. SPARTA applies that same logic to spacecraft: it catalogs the specific behaviors an adversary exhibits when compromising a satellite, ground station, supply chain, or supporting network, and it does so entirely in publicly releasable form. The matrix defines and categorizes activities that contribute to spacecraft compromises, covering both cyber intrusions and traditional counterspace means such as jamming, high-powered lasers, and kinetic antisatellite weapons.

The framework’s scope extends beyond the spacecraft bus. SPARTA accounts for the full ecosystem that keeps a satellite operational, including the ground segment, launch infrastructure, supply chain, third-party operators, and the cloud services that increasingly underpin mission operations. A satellite’s attack surface isn’t limited to its radio receivers and onboard computer; it includes every contractor laptop, ground station antenna, software repository, and logistics chain that touches the mission from design through decommissioning.

SPARTA is approved for public release under distribution statement A and was designated OTR 2022-01250. The Aerospace Corporation encourages the community to contribute new techniques, provide feedback on existing descriptions, and use the framework in threat analysis, security assessments, tabletop exercises, and systems engineering. Cross-references to companion Aerospace publications including TOR 2021-01333 REV A and the Space Segment Cybersecurity Profile TOR-2023-02161 Rev A provide deeper technical grounding for programs seeking to translate threat knowledge into security requirements.

How SPARTA Is Organized

The SPARTA matrix organizes adversarial behaviors into nine top-level tactics, each representing a phase or goal in an attack campaign. The nine tactics are Reconnaissance (ST0001), Resource Development (ST0002), Initial Access (ST0003), Execution (ST0004), Persistence (ST0005), Defense Evasion (ST0006), Lateral Movement (ST0007), Exfiltration (ST0008), and Impact (ST0009). Each tactic contains between five and 18 techniques, and many techniques include multiple sub-techniques that describe specific variations in how a threat actor achieves that particular goal.

Reconnaissance covers nine techniques with 27 sub-techniques in version 3.2. Resource Development contains five techniques with 14 sub-techniques. Initial Access contains 13 techniques with 11 sub-techniques. Execution, the most populated tactic by technique count, holds 18 techniques with 40 sub-techniques. Persistence contains five techniques with two sub-techniques. Defense Evasion holds 12 techniques with 17 sub-techniques. Lateral Movement holds seven techniques with one sub-technique. Exfiltration contains 10 techniques with seven sub-techniques. Impact holds six techniques with no sub-techniques.

The matrix structure was deliberately borrowed from MITRE ATT&CK. Each SPARTA tactic maps conceptually to an ATT&CK tactic, though the sub-categories differ significantly because space systems present unique attack surfaces. A spacecraft’s internal MIL-STD-1553 data bus behaves nothing like a corporate Ethernet network. Fault detection, isolation, and recovery (FDIR) autonomy has no equivalent in enterprise IT. Orbital mechanics, eclipse cycles, and radio frequency (RF) link geometry impose constraints that shape which techniques are feasible at which moments.

The framework doesn’t require an adversary to use every tactic in sequence. Sophisticated actors may compress or skip phases, entering at Initial Access by exploiting a supply chain compromise rather than spending weeks on reconnaissance. Simpler actors may confine themselves to jamming or signal spoofing without ever touching a flight computer. SPARTA represents the full menu of documented behaviors; which ones appear in a given campaign depends on the adversary’s goals, capabilities, and the vulnerability profile of the targeted mission.

Reconnaissance: Mapping a Spacecraft Before Striking

Reconnaissance (ST0001) is defined in SPARTA as the phase where a threat actor gathers information to plan future operations. It contains nine techniques that collectively describe how an adversary builds a working mental model of a target spacecraft, its operations, and its supporting ecosystem, before attempting any direct action. The intelligence gathered during this phase directly shapes which techniques succeed in later stages.

Collecting Design Documents and Engineering Knowledge

Gather Spacecraft Design Information (REC-0001) is the broadest reconnaissance technique and carries nine sub-techniques covering nearly every engineering domain of a spacecraft. Adversaries seek a coherent picture of the vehicle and its supporting ecosystem to reduce uncertainty and plan follow-on actions. Useful design information spans avionics architecture, command and data handling, communications and RF chains, power and thermal control, flight dynamics constraints, payload-to-bus interfaces, redundancy schemes, and ground segment dependencies.

The sources feeding this technique are numerous. Open sources include academic papers, patents, graduate theses, conference slides, procurement documents, FCC and ITU filings, and marketing sheets. Gray sources include leaked request-for-proposal appendices, vendor manuals, employee resumes, and social media posts. The combination can allow a patient adversary to infer single points of failure, unsafe modes, or poorly defended pathways between the space, ground, and supply chain segments. The output of this activity isn’t merely a document set; it’s a working mental model that enables rehearsal, timing studies, and failure-mode exploration.

Software Design (REC-0001.01) targets flight and ground software to identify exploitable seams and build high-fidelity emulators for rehearsal. Valuable details include real-time operating system (RTOS) selection and version, process layout, inter-process messaging patterns, memory maps and linker scripts, fault-detection and isolation and recovery logic, mode management and safing behavior, command handlers and table services, bootloaders, patch and update mechanisms, cryptographic libraries, device drivers, and test harnesses. Even partial disclosures shrink the search space for exploitation. A unit test name, an assert message, or a legacy application programming interface can reveal enough about internal structure to guide further probing.

Firmware (REC-0001.02) extends this focus to the lower layers of the software stack. Firmware intelligence covers microcontroller images, programmable logic bitstreams, boot ROM behavior, peripheral configuration blobs, and anti-rollback or secure-boot settings. Knowing device types, versions, and form factors enables inference of default passwords, debug interfaces such as JTAG and SWD, timing tolerances, and error handling under brownout or thermal stress. A threat actor may obtain firmware from vendor reference packages, public evaluation boards, leaked manufacturing files, over-the-air update images, or crash dumps.

Cryptographic Algorithms (REC-0001.03) focuses on the complete cryptographic picture of the mission: algorithms and modes, key types and lifecycles, authentication schemes, counter or time-tag handling, anti-replay windows, link-layer protections, and any differences between uplink and downlink policy. Programs should assume that partial disclosures, including MAC length, counter reset rules, or key rotation cadence, materially aid exploitation.

Data Bus (REC-0001.04) covers the protocols used on internal spacecraft buses such as MIL-STD-1553, SpaceWire, and custom implementations. Knowing controller roles, addressing, timings, arbitration, and the location of critical endpoints enables an adversary to craft frames that collide with or supersede legitimate traffic, to starve health monitoring, or to trigger latent behaviors in payload or power systems.

Thermal Control System (REC-0001.05) focuses on passive elements such as multi-layer insulation, coatings, radiators, heat pipes, and louvers alongside active control systems including survival and control heaters, thermostats, pumped loops, sensor placement, setpoints, deadbands, heater priority tables, and autonomy rules. Even small fragments such as louver hysteresis or a heater override can reveal opportunities to mask heating signatures or provoke nuisance safing.

Maneuver and Control (REC-0001.06) addresses the guidance, navigation, and control stack. Threat actors collect details of propulsion type and layout, reaction wheels and control moment gyroscopes and their desaturation logic, control laws and gains, estimator design, timing and synchronization, detumble and safe-mode behaviors, and the full sensor suite. Knowing when and how attitude holds, acquisition sequences, or wheel unloads occur helps an adversary choose windows where injected commands or bus perturbations have outsized effect.

Payload (REC-0001.07) investigates the spacecraft’s primary mission instrument or instruments, pursuing vendor and model information, operating constraints, mode transition logic, timing of calibrations, safety inhibits and interlocks, firmware and software update paths, data formatting and compression, and any differences in cryptographic posture between payload links and the main command link. Knowledge of duty cycles and scheduler entries enables timing attacks that coincide with high-power or high-rate operations to stress power and thermal margins or saturate storage and downlink.

Power (REC-0001.08) focuses on the electrical power subsystem, including solar array topology and solar array drive assembly behavior, maximum power point tracking algorithms, eclipse depth assumptions, battery chemistry and configuration, battery management system charge and discharge limits, power conditioning and distribution unit architecture, load-shed priorities, latching current limiters, and survival power rules. Correlating these with attitude plans and payload schedules lets a threat actor infer when state-of-charge runs tight, which loads are shed first, and how fast recovery proceeds after a brownout or safing entry.

Fault Management (REC-0001.09) addresses fault detection, isolation, and recovery materials directly. Adversaries seek trigger thresholds and persistence timers, voting logic, inhibit and recovery ladders, safe-mode entry and exit criteria, command authority in safed states, watchdog and reset behavior, and any differences between flight and maintenance builds. With these materials, a threat actor can craft inputs that remain just below detection thresholds, stack benign-looking events to cross safing boundaries at tactically chosen times, or exploit recovery windows when authentication, visibility, or redundancy is reduced.

Who the Spacecraft Is and Where It Operates

Gather Spacecraft Descriptors (REC-0002) compiles identity, organizational, and operational attributes about the spacecraft and mission. Adversaries harvest identity elements such as mission name, NORAD catalog number, COSPAR international designator, call signs, mission class and operator, country of registry, launch vehicle and date, orbit regime, and typical ephemerides. Even when each item appears benign, the aggregate picture enables precise timing, realistic social-engineering pretexts, and better targeting of ground or cloud resources.

Identifiers (REC-0002.01) enumerate all tags that uniquely tag the vehicle throughout its lifecycle. These identifiers allow cross-reference across public catalogs, tracking services, regulatory filings, and operator materials. Rideshare and hosted-payload contexts introduce additional ambiguity that an attacker can exploit to mask activity or misattribute traffic.

Organization (REC-0002.02) maps the human and institutional terrain surrounding the mission to find leverage for phishing, credential theft, invoice fraud, or supply chain compromise. Targeted details include the owner and operator, prime and subcontractors for bus, payload, ground, and launch services, key facilities and laboratories, cloud and software-as-a-service providers, organizational charts, distribution lists, and role and responsibility boundaries for operations, security, and engineering. Understanding decision chains reveals when change control boards meet, when operations handovers occur, and where a single compromised account could bridge enclaves.

Operations (REC-0002.03) collects high-level operational descriptors to predict when the mission will be busy, distracted, or temporarily less instrumented. Useful items include concept of operations overviews, daily and weekly activity rhythms, ground pass schedules, Deep Space Network or commercial network windows, calibration and maintenance timelines, planned wheel unloads or thruster burns, conjunction-assessment cycles, and anomaly response playbooks.

The Communications Surface

Gather Spacecraft Communications Information (REC-0003) assembles a detailed picture of the mission’s RF and networking posture across telemetry, tracking, and commanding (TT&C) and payload links. Useful elements include frequency bands and allocations, emission designators, modulation and coding schemes, data rates, polarization sense, Doppler profiles, timing and ranging schemes, link budgets, and expected signal-to-noise ratios. The outcome is a lab-replicable demodulation and decode chain and a calendar of advantageous windows for interception or interference.

Communications Equipment (REC-0003.01) inventories space and ground RF equipment to infer capabilities, limits, and attack surfaces. On the spacecraft, adversaries seek antenna type and geometry, placement and boresight constraints, polarization, RF front-end chains, transponder type, translation factors, gain control, saturation points, and protective features. On the ground, they collect dish size and aperture efficiency, feed and polarizer configuration, tracking modes, diversity sites, and backend modem settings.

Commanding Details (REC-0003.02) studies how commands are formed, authorized, scheduled, and delivered. High-value details include the telecommand protocol, framing and cyclic redundancy check and message authentication code fields, authentication scheme including keys, counters, and anti-replay windows, command dictionary and database formats, critical-command interlocks and enable codes, rate and size limits, time-tag handling, command queue semantics, and the roles of scripts or procedures that batch actions.

Mission-Specific Channel Scanning (REC-0003.03) extends beyond TT&C to additional RF or network surfaces such as high-rate payload downlinks, user terminals, inter-satellite crosslinks, and hosted-payload channels. Adversaries scan spectrum and public telemetry repositories, characterizing carrier plans, burst structures, access schemes, addressing, and gateway locations.

Valid Credentials (REC-0003.04) seeks any credential that would let an adversary authenticate as a legitimate actor in space, ground, or supporting cloud networks. Targets include TT&C authentication keys and counters, link-encryption keys, pseudonoise codes or spreading sequences, modem and gateway accounts, mission control user and service accounts, station control credentials, VPN and identity-provider tokens, Space Link Extension and commercial service provider credentials, maintenance backdoor accounts, and automation secrets embedded in scripts or continuous integration and continuous delivery pipelines.

Launch as a Reconnaissance Target

Gather Launch Information (REC-0004) collects structured launch intelligence to forecast when and how mission assets transition through their most time-compressed, change-prone phase. Useful elements include the launch date and time windows, launch site and range operator, participating organizations, vehicle family and configuration, fairing type, and upper-stage restart profiles. Flight Termination (REC-0004.01) looks at how the launch vehicle’s flight termination capability is architected and governed, including command-destruct versus autonomous flight termination, authority chains, cryptographic protections, arming interlocks, inhibit ladders, and range rules.

Passive Collection and Active Probing

Eavesdropping (REC-0005) seeks to passively and sometimes semi-passively capture mission communications across terrestrial networks and RF and optical links. Uplink Intercept Eavesdropping (REC-0005.01) focuses on capturing the command path from ground to spacecraft. Downlink Intercept (REC-0005.02) collects housekeeping telemetry, event logs, ephemerides, payload data, and operator annotations. Proximity Operations (REC-0005.03) uses an adversary platform at close range to observe emissions and intra-vehicle traffic at distances undetectable from the ground. Active Scanning (REC-0005.04) transmits or injects probes to elicit identifiable responses, performing what is effectively RF banner grabbing.

Software Development as a Vector

Gather FSW Development Information (REC-0006) collects a cradle-to-operations view of how flight software is built, tested, signed, and released. Development Environment (REC-0006.01) enumerates the exact environment used to produce flight builds including integrated development environments and plugins, cross-compilers and software development kits, container images, build systems, and private package registries. Security Testing Tools (REC-0006.02) studies how organizations test their software to learn what isn’t being tested, mapping gaps in static analyzers, dynamic tools, fuzzers targeted at command parsers, and property-based or formal methods.

Watching for Safe Mode

Monitor for Safe-Mode Indicators (REC-0007) watches for telltale signs that the spacecraft has entered a safed or survival configuration. Indicators include specific mode bits or beacon fields, changes in modulation and coding, distinctive event packets, elevated heater duty, altered load-shed states, and operator behaviors such as emergency DSN requests or longer ground passes. This reconnaissance helps time later actions to coincide with periods of reduced bandwidth, altered monitoring, or maintenance command availability.

Gather Supply Chain Information (REC-0008) maps the end-to-end pathway by which hardware, software, data, and people move from design through assembly, integration, and testing (AIT), launch, and on-orbit sustainment. Hardware Recon (REC-0008.01), Software Recon (REC-0008.02), Known Vulnerabilities (REC-0008.03), and Business Relationships (REC-0008.04) together build a prioritized list of chokepoints where compromise yields outsized effect.

Gather Mission Information (REC-0009) compiles a concept-of-operations-level portrait of the mission to predict priorities, constraints, and operational rhythms. The aim is not merely understanding but timing: choosing moments when authentication might be relaxed, monitoring is saturated, or rapid-response authority is invoked.

Resource Development: Building the Attack Toolkit

Resource Development (ST0002) describes how a threat actor establishes the assets and capabilities needed to support operations. Adversaries operating against space systems need more than software. They need antennas, compute infrastructure, timing sources, cryptographic material, and in some cases orbital assets of their own. This tactic makes that preparation visible.

Acquiring Physical and Digital Infrastructure

Acquire Infrastructure (RD-0001) covers the assembly of people, platforms, and plumbing that an adversary uses to observe, reach, or impersonate mission components. Infrastructure spans RF and optical ground assets including antennas, modems, timing sources, and front ends; compute and storage; network presence including leased autonomous system numbers and IP space; VPS fleets, CDN relays; and fabrication and test environments for hardware and software.

Ground Station Equipment (RD-0001.01) describes adversaries building their own RF ground stack rather than compromising existing stations. Typical building blocks include steerable mounts with auto-track, time and frequency standards, band-appropriate antennas and feeds, low-noise amplifiers and filters at the feed, low-loss intermediate frequency chains, transmit and receive switching, medium and high-power amplifiers with protection and telemetry, and weather protection. Software-defined radio hardware combined with commercial modems generates and captures mission waveforms and framing.

Commercial Ground Station Services (RD-0001.02) describes renting time on commercial ground networks or cloud-integrated ground-station-as-a-service platforms instead of building dishes. Access can be obtained legitimately through front companies with weak vetting or via compromised customer accounts, allowing schedule requests, RF front-end configuration, and data exfiltration through reputable providers. The appeal is speed, global reach, and plausible deniability.

Spacecraft (RD-0001.03) acknowledges that a well-resourced actor may field their own spacecraft or hosted payload to gain proximity, visibility, or RF leverage. Small satellites can be launched into nearby planes or phasing orbits to observe emissions, perform spectrum measurements, or test spoofing and denial techniques at short range. Proximity also enables on-orbit relay, crosslink probing, or attempts to exploit weak segmentation between payload and bus on rideshares.

Launch Facility (RD-0001.04) notes that in practice, adversaries are far more likely to purchase launch services via rideshare slots or hosted-payload opportunities than to control a launch facility directly. Shell entities might book benign-sounding rides, insert dual-use payloads, or seek special handling that relaxes integration controls.

Weaponizing Existing Systems

Compromise Infrastructure (RD-0002) targets existing infrastructure, mission-owned, third-party, or shared, to obtain ready-made reach with the benefit of plausible attribution. Mission-Operated Ground System (RD-0002.01) compromises the mission’s own ground system to gain preconfigured access to TT&C and automation. Third-Party Ground System (RD-0002.02) targets commercial ground stations and hosted modem providers as stepping-stones. Third-Party Spacecraft (RD-0002.03) uses a compromised neighbor spacecraft to gain proximity, sensing, and relay capabilities.

Obtain Cyber Capabilities (RD-0003) acquires ready-made tools, code, and knowledge. Exploit and Payload (RD-0003.01) obtains or adapts exploits and payloads for space, ground, and cloud components. Cryptographic Keys (RD-0003.02) seeks uplink authentication and MAC keys and counters, link encryption and session keys, loading and transfer keys for hardware security modules, pseudonoise and spreading codes, modem credentials, and station or crosslink keys.

Stage Capabilities (RD-0004) prepares the ground before execution. Identify and Select Delivery Mechanism (RD-0004.01) selects the pathway that best balances effect, risk, bandwidth, and attribution, considering modulation and coding, Doppler and polarization, anti-replay windows, pass geometry, rate and size limits, and expected operator workload. Upload Exploit and Payload (RD-0004.02) pre-positions specific packages and procedures where execution will be fastest.

Obtain Non-Cyber Capabilities (RD-0005) covers the acquisition of physical counterspace means. Launch Services (RD-0005.01) uses commercial launch to position inspection or relay assets. Non-Kinetic Physical ASAT (RD-0005.02) acquires directed energy systems including ground or space-based lasers and high-power microwave systems. Kinetic Physical ASAT (RD-0005.03) develops or accesses physical interceptors. Electronic ASAT (RD-0005.04) obtains portable or fixed jammers, high-gain antennas with agile waveforms, and specialized signal-processing toolchains for jamming and spoofing operations.

Initial Access: Breaching Space System Defenses

Initial Access (ST0003) describes the 13 techniques by which a threat actor gains a first foothold in a space system. The range is extraordinary: from contaminated software libraries injected during development, to a rogue antenna impersonating a legitimate ground station, to a co-orbiting spacecraft that physically grapples with a target. No other cybersecurity framework covers this breadth of entry paths because no other domain combines information technology, radio frequency engineering, orbital mechanics, and mechanical proximity operations in a single attack surface.

The Supply Chain as the Entry Point

Compromise Supply Chain (IA-0001) recognizes that a spacecraft may arrive on orbit already compromised. Software Dependencies and Development Tools (IA-0001.01) targets the libraries, compilers, build systems, and CI/CD pipelines that produce flight software. Software Supply Chain (IA-0001.02) targets the distribution and update mechanisms that carry software to the mission. Hardware Supply Chain (IA-0001.03) focuses on component fabrication, screening, and integration, covering everything from counterfeit electronic parts to malicious field-programmable gate array bitstreams inserted before delivery.

The SolarWinds incident of December 2020 demonstrated how a single tampered software build tool could silently compromise thousands of organizations. Space systems face a similar risk, compounded by the fact that once a compromised satellite is in orbit, patching the affected component may be impossible without a software update capability, and even that update capability may have been compromised.

Radio and Communications Entry

Compromise Software Defined Radio (IA-0002) acknowledges that software-defined radios, increasingly common on modern spacecraft for their flexibility, present an attack surface distinct from traditional hardware transceivers. Their programmability is also their vulnerability: if the configuration or software image of a software-defined radio can be altered, the radio becomes an adversary-controlled communications endpoint.

Secondary and Backup Communication Channel (IA-0004) targets the contingency receivers, backup antennas, or emergency communication paths that many spacecraft maintain for anomaly recovery. Ground Station (IA-0004.01) targets those used on the ground side, while Receiver (IA-0004.02) targets the spacecraft-side backup. These channels often have reduced authentication requirements compared to the primary path because they’re designed for emergency access when normal channels fail.

Crosslink via Compromised Neighbor (IA-0003) uses an already-compromised satellite in a constellation to reach other satellites over inter-satellite links. Because crosslinks are assumed to carry trusted traffic from trusted peers, they may not be subject to the same scrutiny as uplink traffic from ground stations. An attacker who controls one node in a constellation effectively has a persistent, authenticated inside position for reaching others.

Physical and Proximity Approaches

Rendezvous and Proximity Operations (IA-0005) covers three sub-techniques representing physically close access approaches. Compromise Emanations (IA-0005.01) uses an adversary spacecraft in close proximity to observe electromagnetic emissions that reveal internal bus activity, timing, and operational patterns. Docked Vehicle and On-orbit Servicing, Assembly, and Manufacturing (IA-0005.02) exploits the high-trust, high-bandwidth connections that form during docking or servicing operations. Proximity Grappling (IA-0005.03) represents the most physically aggressive form, where a spacecraft uses robotic arms or capture mechanisms to make contact with and potentially gain physical interface access to the target.

These techniques have moved from theoretical to demonstrated in recent years. China’s Shijian-21 satellite performed rendezvous and proximity operations with a defunct Chinese navigation satellite in 2022, demonstrating the orbital mechanics and sensor capabilities required. The line between legitimate on-orbit servicing and a precursor to malicious proximity operations is thin and getting thinner as commercial servicing vehicles become operational.

Hosted Payloads and Trusted Relationships

Compromise Hosted Payload (IA-0006) recognizes that hosted payloads, secondary instruments or transponders carried aboard another operator’s spacecraft, often represent poorly defended attack surfaces. They connect to the host bus through standard gateways while potentially being operated by a completely different organization with different security practices. The trust boundary between the host and the payload is a natural entry point for an actor who can compromise either side.

Compromise Ground System (IA-0007) targets the ground segment directly. Compromise On-Orbit Update (IA-0007.01) intercepts or replaces the software or parameter updates sent to the spacecraft during normal operations. Malicious Commanding via Valid Ground Station (IA-0007.02) uses a compromised ground system to issue unauthorized commands while appearing to the spacecraft to be a legitimate operator.

Rogue External Entity (IA-0008) covers three variants of impersonation. Rogue Ground Station (IA-0008.01) sets up a transmitter that impersonates a legitimate ground station, exploiting knowledge of frequencies, modulation, and authentication parameters gathered during reconnaissance. Rogue Spacecraft (IA-0008.02) uses a co-orbital asset to impersonate a trusted crosslink partner or service vehicle. ASAT and Counterspace Weapon (IA-0008.03) represents the use of a physical counterspace capability as the initial access mechanism.

Trusted Relationship (IA-0009) exploits the relationships that missions depend on for normal operations. Mission Collaborator (IA-0009.01) covers academic partners, international agencies, and other organizations with legitimate system access. Vendor (IA-0009.02) targets the hardware and software suppliers who maintain ongoing access for support and updates. User Segment (IA-0009.03) targets the end users or user terminals of the spacecraft’s services, whose connections to the space segment may provide a path inward.

Unauthorized Access During Safe-Mode (IA-0010) exploits the reduced security posture that many spacecraft adopt when entering autonomous recovery. Assembly, Test, and Launch Operation Compromise (IA-0012) targets the ground facilities and procedures used before launch, when the spacecraft is physically accessible and security controls may be less stringent. Auxiliary Device Compromise (IA-0011) targets secondary devices connected to the spacecraft. Compromise Host Spacecraft (IA-0013) involves using a hosted payload position as a springboard to compromise the spacecraft carrying it.

Execution: Running Malicious Operations Aboard a Spacecraft

Execution (ST0004) is the largest tactic in SPARTA with 18 techniques and 40 sub-techniques. It describes what a threat actor actually does once access has been achieved: the specific methods by which malicious code, commands, or effects are produced on or through the space system. The breadth of this tactic reflects the unusual nature of spacecraft as targets. Unlike enterprise computers where execution largely means running unauthorized code, spacecraft execution can involve corrupting sensor data, commanding propulsion burns, triggering single-event upsets with radiation, or physically destroying the vehicle with a kinetic weapon.

Replaying Captured Traffic

Replay (EX-0001) is the re-transmission of previously captured traffic over RF links, crosslinks, or internal buses to elicit the same processing and effects a second time. Command Packets (EX-0001.01) resends authentic-looking telecommands that were previously accepted by the spacecraft. Bus Traffic Replay (EX-0001.02) targets internal command and data handling by injecting or retransmitting messages on the spacecraft bus. Because many subsystems act on the latest message or on message rate rather than on uniqueness, a flood of historical but well-formed frames can consume bandwidth, starve critical publishers, or cause subsystems to perform the same action repeatedly.

Geofencing Malware

Position, Navigation, and Timing Geofencing (EX-0002) represents one of the most sophisticated techniques in the SPARTA matrix. Malware or implanted procedures execute only when the spacecraft’s state meets geometric and temporal criteria. Triggers can be defined in orbital elements, inertial or Earth-fixed coordinates, relative geometry, lighting conditions, or time references. The code monitors onboard navigation solutions, ephemerides, or propagated two-line element sets and arms itself when thresholds are met. A payload might be programmed to activate only when the spacecraft passes over a specific geographic region, only during a launch and early operations phase, or only within seconds of a scheduled downlink window. The geofencing dramatically reduces exposure and aids deniability because triggers are rare, aligned with mission cadence, and difficult to reproduce in a laboratory.

Subverting Authentication

Modify Authentication Process (EX-0003) alters how the spacecraft validates authority so future inputs are accepted on the adversary’s terms. Modifications can target code by patching flight binaries, hot-patching functions in memory, or hooking command handlers. They can target data by changing key identifiers, policy tables, or counter initialization. They can target control flow by short-circuiting message authentication code checks, widening anti-replay windows, or bypassing interlocks on specific opcodes. Subtle variants preserve outward behavior, producing normal-looking acknowledgments and counters, while internally accepting a broader set of origins, opcodes, or time tags.

Boot Memory and Firmware Attacks

Compromise Boot Memory (EX-0004) manipulates memory and configuration used in the earliest stages of boot so malicious code runs before normal protections and integrity checks take effect. Targets include boot ROM vectors, first and second-stage bootloaders, boot configuration words and strap pins, one-time-programmable fuses, non-volatile images in flash memory and electrically erasable programmable read-only memory (EEPROM), and scratch regions copied into RAM during cold start. Faults can be induced deliberately through timed power, clock, or electromagnetic glitches, or via crafted update and write sequences that leave a partially programmed but executable state. Because boot logic initializes buses, memory maps, and handler tables, even small changes at this stage cascade.

Exploit Hardware and Firmware Corruption (EX-0005) achieves execution or effect by corrupting behavior beneath the software stack in device firmware, programmable logic, or hardware. Design Flaws (EX-0005.01) exploits inherent properties or errata in the hardware or logic design, including undocumented behaviors, counter and timer rollovers and wraparound, interrupt storms and priority inversions, and memory management unit corner cases. Malicious Use of Hardware Commands (EX-0005.02) issues low-level device or maintenance commands that act directly on hardware, bypassing much of the high-level command mediation.

Bypassing Encryption

Disable and Bypass Encryption (EX-0006) alters how confidentiality or integrity is applied so traffic or data is processed in the clear or with weakened protection. Paths include toggling configuration flags that place links or storage into maintenance or test modes, forcing algorithm fallbacks or null ciphers, downgrading negotiated suites or keys, and selecting alternate routes that carry the same content without encryption. The end state is that command, telemetry, or data products traverse a path the spacecraft accepts while cryptographic protection is absent, weakened, or inconsistently applied.

Exploiting Radiation

Trigger Single Event Upset (EX-0007) induces or opportunistically exploits a single-event upset (SEU), a transient bit flip or latch disturbance in logic or memory. SEUs arise when charge is deposited at sensitive nodes by energetic particles or intense electromagnetic stimuli. An actor may time operations to coincide with natural radiation peaks such as passages through the South Atlantic Anomaly or use artificial means from close range. Outcomes include corrupted stacks or tables, altered branch conditions, flipped configuration bits in FPGAs or controllers, and transient faults that push autonomy and FDIR into recovery modes with broader command acceptance.

Precision Timing

Time Synchronized Execution (EX-0008) arranges malicious logic to run at precise times derived from onboard clocks or distributed time sources. Absolute Time Sequences (EX-0008.01) keys execution to a fixed wall-clock timestamp or epoch, independent of current vehicle state. Relative Time Sequences (EX-0008.02) keys execution to elapsed time since a reference event such as boot, reset, safing entry or exit, or receipt of a particular telemetry or command pattern. Relative sequences are resilient to clock discontinuities and mirror how many spacecraft schedule internal activities.

Code Flaws and Malicious Software

Exploit Code Flaws (EX-0009) abuses defects in software running on the vehicle. Flight Software (EX-0009.01) targets mission-specific parsing and autonomy in command and telemetry handlers, table loaders, file transfer services, mode management and safing logic, payload control applications, and gateway processes. Operating System (EX-0009.02) targets primitives that schedule work and mediate hardware, potentially yielding kernel-mode execution, arbitrary memory read and write, or control of scheduling and address spaces. Known Vulnerability in Commercial Off-the-Shelf and Free and Open-Source Software (EX-0009.03) maps components and versions to publicly or privately known defects, then crafts inputs to trigger them.

Malicious Code (EX-0010) introduces executable logic that runs on the vehicle through legitimate pathways: software and firmware updates, file transfer services, table loaders, maintenance consoles, or command sequences that write to executable regions. Ransomware (EX-0010.01) encrypts data or critical configuration so nominal operations can no longer proceed. Wiper Malware (EX-0010.02) deliberately destroys or irreversibly corrupts data and executable images to impair or end mission operations. Rootkit (EX-0010.03) hides the presence and activity of other malicious components by interposing on the mechanisms that report system state. Bootkit (EX-0010.04) positions itself in the pre-OS boot chain so malicious code executes before normal integrity checks, shaping what the system subsequently trusts.

Safe Mode as an Attack Window

Exploit Reduced Protections During Safe-Mode (EX-0011) times on-board actions to the period when the vehicle is in safe-mode and operating with altered guardrails. In many designs, safe-mode enables contingency command dictionaries, activates alternate receivers or antennas, reduces data rates, and prioritizes survival behaviors. Authentication checks, anti-replay windows, rate and size limits, and interlocks may differ from nominal; counters can be reset, time-tag screening relaxed, or maintenance procedures made available for recovery.

Modifying On-Board Values

Modify On-Board Values (EX-0012) stands out as the SPARTA technique with the most sub-techniques: 13. This technique alters live or persistent data that the spacecraft uses to make decisions and route work. Registers (EX-0012.01) targets the internal registers of the victim spacecraft to modify specific values while the flight software is functioning. Internal Routing Tables (EX-0012.02) rewrites the maps that tell software where to send and receive messages. Memory Write and Loads (EX-0012.03) uses legitimate direct-memory commands or load services to place chosen bytes at chosen addresses.

App and Subscriber Tables (EX-0012.04) modifies the mappings in publish and subscribe flight frameworks that define which components receive which messages. Scheduling Algorithm (EX-0012.05) edits real-time scheduling parameters and associated tables to skew execution order and timing. Science and Payload Data (EX-0012.06) alters the payload data and metadata in place to mislead users or degrade mission outputs.

Propulsion Subsystem (EX-0012.07) modifies the parameters and sensed values that govern burns, pressure management, and safing. Attitude Determination and Control Subsystem (EX-0012.08) edits the models and parameters that closed the loop between what the vehicle believes and how it responds, including star-tracker catalogs, sensor alignments, bias terms, gyro scale factors, drift rates, estimator covariances, and controller gains. Electrical Power Subsystem (EX-0012.09) alters parameters and sensed values that govern power generation, storage, and distribution. Command and Data Handling Subsystem (EX-0012.10) targets tables and runtime values that define how commands are parsed, queued, and dispatched.

Watchdog Timer (EX-0012.11) manipulates watchdog behavior by changing timeout durations, windowed watchdog bounds, reset actions, enable and mask bits, or the source that performs the petting operation. System Clock (EX-0012.12) skews time references by writing to clock registers, altering time distribution services, switching disciplining sources, or biasing oscillator parameters. Poison AI and ML Training Data (EX-0012.13) targets the training datasets used by onboard artificial intelligence and machine learning systems, inserting crafted examples or labels so the resulting model behaves incorrectly while appearing valid.

Flooding and Spoofing

Flooding (EX-0013) overwhelms a communication or processing path by injecting traffic at rates or patterns the system cannot comfortably absorb. Valid Commands (EX-0013.01) saturates paths with legitimate telecommands or bus messages so the spacecraft burns scarce resources honoring them. Erroneous Input (EX-0013.02) injects noise, malformed frames, or near-valid messages so receivers and parsers labor to acquire, decode, and reject a flood of invalid content.

Spoofing (EX-0014) forges inputs that subsystems treat as trustworthy truth. Time Spoof (EX-0014.01) forges or biases the time seen by onboard consumers. Bus Traffic Spoofing (EX-0014.02) forges messages on internal command and data paths. Sensor Data (EX-0014.03) presents fabricated or biased measurements that estimation and control treat as ground truth. Position, Navigation, and Timing Spoofing (EX-0014.04) transmits GNSS-like signals so the spacecraft’s navigation solution reflects attacker-chosen states. Ballistic Missile Spoof (EX-0014.05) deploys decoys or emitters designed to mimic ballistic-missile signatures so early-warning and missile-defense systems allocate interceptors and attention to false targets.

Side-Channel Attack (EX-0015) extracts secrets or steers execution by observing or perturbing physical byproducts of computation rather than intended interfaces. Passive channels include timing, power draw, electromagnetic emissions, acoustic and optical leakage, and thermal patterns correlated with operations such as key use, counter updates, or parser activity.

Electronic Warfare and Physical Destruction

Jamming (EX-0016) uses radio frequency signals to interfere with communications. Unlike physical attacks, jamming is completely reversible once the jammer is disengaged. Uplink Jamming (EX-0016.01) transmits toward the spacecraft’s uplink receive antenna at the operating frequency and sufficient power spectral density to drive the uplink signal below the demodulator’s threshold. Downlink Jamming (EX-0016.02) creates noise in the same frequency as the downlink signal from the satellite to block users on the ground. Position, Navigation, and Timing Jamming (EX-0016.03) raises the noise floor in GNSS bands so satellite navigation signals are not acquired or tracked.

Kinetic Physical Attack (EX-0017) inflicts damage by physically striking space assets. Direct Ascent ASAT (EX-0017.01) involves a medium- or long-range missile launching from Earth to damage or destroy a satellite in orbit. India’s March 27, 2019 Mission Shakti direct-ascent ASAT test demonstrated this capability at roughly 300 kilometers altitude, generating a debris field that the United States Space Force tracked for weeks. Co-Orbital ASAT (EX-0017.02) uses a spacecraft already in space to conduct a deliberate collision or near-field detonation.

Non-Kinetic Physical Attack (EX-0018) inflicts physical effects without mechanical contact. Electromagnetic Pulse (EX-0018.01) delivers a broadband, high-amplitude electromagnetic transient that couples into spacecraft electronics and harnesses, upsetting or damaging components over wide areas. High-Powered Laser (EX-0018.02) can permanently or temporarily damage critical satellite components. If directed toward a satellite’s optical center, the attack is known as blinding or dazzling; blinding causes permanent damage to optics while dazzling causes temporary loss. High-Powered Microwave (EX-0018.03) can disrupt or destroy a satellite’s electronics through front-door attacks that use the spacecraft’s own antennas as an entry path, or back-door attacks that attempt to enter through small seams or gaps around electrical connections and shielding.

Persistence: Maintaining a Long-Term Foothold

Persistence (ST0005) describes how a threat actor maintains their foothold and access to execute code on the spacecraft across reboots, mode changes, and recovery events. Five techniques address the different mechanisms by which an adversary can ensure their access and implanted capabilities survive.

Memory Compromise (PER-0001) recognizes that spacecraft may have mechanisms for automatically running programs on system reboot, entering or returning from safe mode, or during specific events. Threat actors target these specific memory locations to store malicious code or files, ensuring the attack remains on the system even after a reset. The technique exploits the spacecraft’s own recovery and initialization logic as a persistence mechanism.

Backdoor (PER-0002) covers both hardware and software backdoors. Hardware Backdoor (PER-0002.01) targets backdoors within the spacecraft hardware, which once deployed in orbit become increasingly difficult for ground controllers to mitigate. Software Backdoor (PER-0002.02) involves injecting code to create persistent access, either through modification of code throughout the software supply chain or through modification of the software-defined radio configuration where applicable. The insidious nature of backdoors, particularly hardware backdoors, is that they can be invisible to all software-based security checking, and they exploit the extreme difficulty of physically servicing a spacecraft in orbit.

Ground System Presence (PER-0003) moves the persistence footprint to the terrestrial side. Threat actors compromise target-owned ground systems that can be used for persistent access to the spacecraft. These ground systems have already been configured for communications to the spacecraft, meaning an attacker with persistent presence on the ground effectively has persistent access to the space segment as well. From this position, threat actors can stage, launch, and execute persistently without needing to maintain an implant on the spacecraft itself.

Replace Cryptographic Keys (PER-0004) represents one of the most disruptive persistence mechanisms available. If a threat actor can fully replace the cryptographic keys on the spacecraft, mission operators lose commanding access entirely. The threat actor then controls who can communicate with the spacecraft. Adversaries can exploit weaknesses in key management strategy, for example by exploiting over-the-air rekeying procedures to inject their own cryptographic keys. Once the encryption key is changed on the spacecraft, the spacecraft is rendered inoperable from the operator’s perspective.

Credentialed Persistence (PER-0005) uses legitimate credentials to maintain persistent access to a spacecraft or its supporting command and control systems. These credentials may include system service accounts, user accounts, maintenance access credentials, cryptographic keys, or other authentication mechanisms that enable continued entry without triggering access alarms. By operating with legitimate credentials, adversaries can sustain access over extended periods, evade detection, and facilitate follow-on tactics. Credentialed persistence is particularly effective in environments lacking strong credential lifecycle management, segmentation, or monitoring.

Defense Evasion: Staying Hidden Against Space System Operators

Defense Evasion (ST0006) is where the sophistication of space system attacks becomes most apparent. Twelve techniques and 17 sub-techniques describe how a threat actor avoids being detected, covering everything from disabling onboard fault monitoring to physically mimicking orbital debris. The space domain creates evasion opportunities that have no equivalent in enterprise cybersecurity.

Disabling Fault Detection

Disable Fault Management (DE-0001) suppresses or alters fault detection, isolation, and recovery (FDIR) so unauthorized actions proceed without triggering safing or alerts. Targets include watchdogs and heartbeat monitors, limit and sanity checks on sensor and command values, command interlocks and inhibit masks, voting and redundancy-management logic, and event and alert generation and routing. With FDIR dulled or offline, anomalous states resemble nominal behavior and automated mitigations do not engage, masking the attack from ground oversight.

Cutting Off Ground Visibility

Disrupt or Deceive Downlink (DE-0002) targets ground-side telemetry reception, processing, or display to disrupt the operator’s visibility into spacecraft health and activity. Inhibit Ground System Functionality (DE-0002.01) disables, corrupts, or falsifies data within the ground system itself to provide the appearance of nominal operation. Jam Link Signal (DE-0002.02) overwhelms or jams the downlink signal to prevent transmitted telemetry signals from reaching their destination. Inhibit Spacecraft Functionality (DE-0002.03) suppresses telemetry at the source by manipulating onboard generation or transmission.

Manipulating the Telemetry Record

On-Board Values Obfuscation (DE-0003) manipulates housekeeping and control values that operators and autonomy rely on to judge activity, health, and command hygiene. Twelve sub-techniques address specific elements of this concealment strategy.

Vehicle Command Counter (DE-0003.01) masks activity by zeroing, freezing, or selectively decrementing the command counter, or by steering actions through paths that do not increment it. Rejected Command Counter (DE-0003.02) hides probing and trial-and-error by suppressing increments, periodically clearing the value, or forging the downlinked field so rejection rates appear benign. Command Receiver On and Off Mode (DE-0003.03) creates deliberate quiet windows by toggling receiver enable states. Command Receivers Received Signal Strength (DE-0003.04) targets the automatic gain control parameters on onboard command receivers. Command Receiver Lock Modes (DE-0003.05) exploits the lock status indicators to create windows where the spacecraft is receptive to commands while downlinked status suggests otherwise.

Telemetry Downlink Modes (DE-0003.06) switches telemetry modes or edits associated parameters to thin, defer, or reroute observability. Cryptographic Modes (DE-0003.07) manipulates mode controls and selectors to desynchronize ground and space or to hide content. Received Commands (DE-0003.08) edits or prunes command histories and logs to remove evidence of unauthorized actions. System Clock for Evasion (DE-0003.09) biases the spacecraft’s authoritative time so telemetry, event logs, and command histories appear shifted or inconsistent. GPS Ephemeris (DE-0003.10) involves spoofing GPS signals to cause erroneous calculations of the satellite’s position while falsifying the telemetered data. Watchdog Timer for Evasion (DE-0003.11) shapes what evidence survives by extending or disabling timeouts or inducing frequent resets that wipe volatile traces. Poison AI and ML Training for Evasion (DE-0003.12) introduces crafted examples or labels into security monitoring models so the learned model treats attacker behaviors as normal.

Masquerading, Safe Mode, and Whitelisting

Masquerading (DE-0004) presents the adversary as an authorized origin so activity appears legitimate across RF, protocol, and organizational boundaries. Subvert Protections via Safe-Mode (DE-0005) exploits the spacecraft’s recovery posture to bypass controls that are stricter in nominal operations. Modify Whitelist (DE-0006) targets the software execution allowlists that prevent unauthorized programs from running.

Evasion via Rootkit (DE-0007) hides malicious activity by interposing on reporting paths after the system has booted, patching flight software APIs, kernel syscalls, message queues, and telemetry publishers. Evasion via Bootkit (DE-0008) positions itself in the boot chain, shaping what higher layers will later observe. Overflow Audit Log (DE-0010) hides activity by exhausting finite onboard logging and telemetry buffers so incriminating events are overwritten before they can be downlinked. Credentialed Evasion (DE-0011) leverages valid credentials to conduct unauthorized actions in a way that conceals presence and evades detection. Component Collusion (DE-0012) involves two or more compromised components operating in coordination where each performs only a limited, seemingly benign function when analyzed in isolation.

Physical Concealment in Orbit

Camouflage, Concealment, and Decoys (DE-0009) exploits the physical and operational environment to reduce detectability or mislead observers. This is where SPARTA departs most dramatically from enterprise cybersecurity frameworks, describing techniques with no equivalent outside the space domain.

Debris Field (DE-0009.01) hides an adversary spacecraft within or near clusters of small objects, matching apparent characteristics such as brightness, radar cross-section, tumbling, and intermittent emissions so the vehicle blends with background debris. Space Weather (DE-0009.02) aligns operations with heightened solar and geomagnetic activity so effects resemble natural disturbances; during storms, receivers struggle with scintillation, single-event upsets rise, and operators expect anomalies.

Trigger Premature Intercept (DE-0009.03) deploys decoys and deceptive signatures to provoke defenders into committing limited resources early, including inspection vehicles, interceptors, laser dwell time, or analyst attention. Targeted Deception of Onboard Space Situational Awareness and Space Domain Awareness Sensors (DE-0009.04) targets the spacecraft’s own proximity-awareness stack including cameras, star-tracker side products, lidar and radar, RF transponders, and the onboard fusion that estimates nearby objects. Corruption or Overload of Ground-Based Space Domain Awareness Systems (DE-0009.05) targets terrestrial space-domain awareness pipelines, sensor networks, tracking centers, catalogs, and their data flows to blind or confuse broad-area monitoring.

Lateral Movement: Spreading Through Space System Architecture

Lateral Movement (ST0007) describes how a threat actor moves through sub-systems and payloads of the spacecraft once an initial foothold has been established. Seven techniques address the distinct movement paths available in space system architectures. In enterprise IT, lateral movement typically means moving between networked computers. In space systems, it means moving between subsystems on a shared bus, hopping between satellites in a constellation over crosslinks, or exploiting the mechanical and digital interfaces created during docking operations.

Moving Across Payload and Bus Boundaries

Hosted Payload (LM-0001) pivots through the host-payload boundary to reach additional subsystems. Hosted payloads exchange power, time, housekeeping, and data with the bus through defined gateways, and often support file services, table loads, and command dictionaries distinct from the host’s. A foothold on the payload can be used to inject traffic through the gateway processor, request privileged services, or ride shared backplanes where payload traffic is bridged into command and data handling networks. In some designs, payload processes execute on host compute or expose maintenance modes that temporarily widen access.

Exploit Lack of Bus Segregation (LM-0002) recognizes that on flat architectures where remote terminals, subsystems, and payloads share a common bus with minimal partitioning, any node that can transmit may influence many others. An attacker leverages this by forging message identifiers or terminal addresses, replaying actuator and sensor frames, seizing or imitating bus-controller roles, or abusing gateway bridges that forward traffic between links. Because many consumers act on the latest valid-looking message, crafted traffic from one compromised device can reconfigure peers, toggle power domains, or write persistent parameters across the entire spacecraft.

Constellation-Level Movement

Constellation Hopping via Crosslink (LM-0003) uses a compromise on one spacecraft as a springboard to others in a satellite constellation. The attacker crafts crosslink traffic including routing updates, service advertisements, time and ephemeris distribution, or file and tasking messages that appears to originate from a trusted neighbor and targets gateway functions that bridge crosslink traffic into command and data paths. In mesh or hub-and-spoke constellations, a single foothold uses shared trust and protocol uniformity to reach additional satellites without contacting the ground segment.

Visiting Vehicle Interface (LM-0004) targets docking, berthing, or short-duration attach events that 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.

Virtualization and Launch Vehicle Movement

Virtualization Escape (LM-0005) pivots across partitions by abusing the mechanisms a separation kernel or hypervisor exposes for inter-partition communication and device sharing. Paths include message ports and queues, shared-memory windows, virtual network interface controllers and bridges, hypercalls, and common driver backends. A foothold in a less-trusted partition can be turned into access to a higher-privilege domain by crafting traffic that exploits parser flaws in port services.

Launch Vehicle Interface (LM-0006) uses the integration and ascent interfaces between payload and launch vehicle. Rideshare Payload (LM-0006.01) describes the particular vulnerability in shared launches where multiple independent payloads cohabit common infrastructure until separation. If isolation is incomplete through shared data buses, mispartitioned deployer controllers, or common logging and telemetry collectors, a compromise in one payload’s domain can be leveraged to observe or influence another’s traffic before release.

Credentialed Traversal (LM-0007) uses legitimate credentials and keys to cross boundaries that rely on trust rather than strict isolation. Using operator or service accounts, maintenance logins, station certificates, or spacecraft-recognized cryptographic material, the adversary invokes gateways that bridge domains. Because traversal occurs through approved interfaces, actions appear as routine operations while reaching progressively more privileged subsystems or neighboring spacecraft.

Exfiltration: Stealing Data from Orbit

Exfiltration (ST0008) describes the 10 techniques by which a threat actor removes data from a space system. The data at stake spans raw sensor and imagery products worth hundreds of millions of dollars in commercial value, intelligence products of strategic importance, cryptographic material, and operational data that reveals mission patterns. Unlike enterprise exfiltration where data leaves through network connections, space system exfiltration can occur over RF downlinks, through side-channel emissions, via proximity operations, or through compromised ground infrastructure.

Replay (EXF-0001) re-transmits captured data in a form that allows the adversary to receive it. Side-Channel Exfiltration (EXF-0002) exploits physical byproducts of computation to extract sensitive data. Power Analysis Attacks (EXF-0002.01) measure power consumption correlated with cryptographic operations to recover key material. Electromagnetic Leakage Attacks (EXF-0002.02) capture the electromagnetic emissions from processing operations. Traffic Analysis Attacks (EXF-0002.03) derive sensitive information from patterns in communication traffic rather than content. Timing Attacks (EXF-0002.04) exploit variations in execution time to infer secret values. Thermal Imaging Attacks (EXF-0002.05) use thermal signatures to derive operational information.

Signal Interception (EXF-0003) captures data as it traverses RF links. Uplink Exfiltration (EXF-0003.01) intercepts command traffic to learn operational procedures and cryptographic parameters. Downlink Exfiltration (EXF-0003.02) captures the payload data, telemetry, and operational outputs intended for authorized users.

Out-of-Band Communications Link (EXF-0004) establishes a covert channel distinct from the mission’s normal communications paths. Proximity Operations (EXF-0005) uses an adversary spacecraft in close range to receive emissions that would not reach ground stations. Modify Communications Configuration (EXF-0006) alters the spacecraft’s communications setup to redirect data to an adversary-controlled receiver. Software Defined Radio (EXF-0006.01) modifies the software-defined radio configuration to add or change downlink destinations. Transponder (EXF-0006.02) reconfigures the spacecraft’s transponder to pass data through additional paths.

Compromised Ground System (EXF-0007), Compromised Developer Site (EXF-0008), and Compromised Partner Site (EXF-0009) represent exfiltration paths through terrestrial infrastructure that already handles mission data. By compromising these systems, an adversary receives data without touching the spacecraft at all. Payload Communication Channel (EXF-0010) exploits the dedicated communications path used by the spacecraft’s primary payload to extract data outside of the monitored telemetry channels.

Impact: The End Goals of Space Cyberattacks

Impact (ST0009) describes what adversaries actually want to accomplish against space systems. Six techniques cover the full spectrum from subtle deception to outright destruction. Understanding these outcomes matters because impact shapes threat modeling: defenders need to understand not just how an attack might happen but what success looks like from an adversary’s perspective.

Deception or Misdirection (IMP-0001) involves measures designed to mislead an adversary by manipulation, distortion, or falsification of evidence or information. Threat actors may seek to deceive mission stakeholders or military decision makers for numerous reasons. Telemetry values could be modified, attacks could be designed to intentionally mimic another threat actor’s tactics to create false attribution, and allied ground infrastructure could be compromised and used as the source of communications to the spacecraft. The 2022 cyberattack against the Viasat KA-SAT network prior to Russia’s invasion of Ukraine demonstrated how space system compromise can directly support broader military deception operations.

Disruption (IMP-0002) describes measures designed to temporarily impair use or access to a system for a period of time. Threat actors may seek to disrupt communications from the victim spacecraft to ground controllers or other interested parties during critical times, causing data to be lost or critical actions not performed. Disruption differs from Denial in that it can also involve modifying data and messages as they are passed, rather than simply blocking them entirely.

Denial (IMP-0003) covers measures designed to temporarily eliminate the use, access, or operation of a system for a period of time, usually without physical damage. Denial is characterized by total elimination of access rather than temporary impairment, achieved by exhausting system resources, degrading subsystems, or blocking communications entirely. The distinction between Disruption and Denial is meaningful for defenders because the two require different countermeasures and detection approaches.

Degradation (IMP-0004) describes measures designed to permanently impair, either partially or totally, the use of a system. Threat actors target various subsystems or hosted payloads in such a way as to rapidly increase degradation, potentially shortening the lifespan of the spacecraft. Degradation is particularly insidious because it may initially appear as normal wear, and the accumulated damage may not become apparent until well into the mission lifecycle.

Destruction (IMP-0005) covers permanent elimination of a system potentially through physical damage. Threat actors may destroy data, commands, subsystems, or attempt to destroy the victim spacecraft itself. Destruction differs from Degradation in that individual parts are destroyed rather than put in a position where they would slowly degrade over time. Kinetic antisatellite weapons, high-powered laser blinding that permanently damages optical components, and wiper malware that destroys flight software images all fall under this outcome category.

Theft (IMP-0006) acknowledges that many spacecraft have a particular purpose associated with them and the data they gather is deemed mission critical. By stealing this data, the mission or purpose of the spacecraft could be lost entirely. Commercial Earth observation satellite imagery can have competitive and intelligence value that makes theft a strategic goal rather than a secondary outcome.

What the SPARTA Countermeasures Framework Provides

SPARTA doesn’t stop at cataloging threats. The countermeasures section of the framework maps defensive controls to each technique and sub-technique, giving security engineers actionable guidance. The countermeasures section cross-references multiple established standards frameworks, making it possible to trace a specific spacecraft attack technique to specific control requirements.

SPARTA Requirements maps each technique to specific security requirements that programs can adopt as baseline controls. The Space Segment Control Tailoring guidance helps engineers adjust control sets based on mission risk profile and the operational constraints of their specific spacecraft. NIST References maps SPARTA countermeasures to NIST SP 800-53 security controls, one of the most widely used control catalogs in US government programs. ISO IEC 27001 mappings provide alignment for programs operating under international information security management standards. The NASA Best Practice Guide mappings align with the NASA cybersecurity guidance applicable to civil space programs.

In March 2026, coinciding with the SPARTA v3.2 release, The Aerospace Corporation published a SPARTA Countermeasure Utilization and Prioritization presentation that introduced a structured prioritization methodology. The methodology evaluates each countermeasure based on three factors: efficacy, which is informed by the number and risk level of mitigated techniques; feasibility, including size weight and power constraints, architectural compatibility, and technology maturity; and cost, covering implementation and lifecycle burden. These factors support a tiered model that categorizes countermeasures into foundational Tier I protections, enhanced Tier II protections, and advanced Tier III protections, while distinguishing applicability between onboard spacecraft and ground or development environments.

The D3FEND integration within SPARTA adds a further defensive dimension. The MITRE D3FEND framework provides a knowledge graph of defensive cybersecurity techniques, and SPARTA’s D3FEND mappings link space-specific attack techniques to the countermeasure techniques in that broader catalog. SPARTA presents D3FEND tactics, techniques, and artifacts in three separate views, allowing defenders to approach defensive planning from multiple angles.

SPARTA Navigator and Supporting Tools

The SPARTA toolset extends the framework’s utility well beyond a static reference document. The SPARTA Navigator allows users to visualize attack coverage, map threat actor behaviors to the matrix, and identify where defensive gaps exist. Security engineers can load threat intelligence reports, map observed behaviors to SPARTA techniques, and immediately see which other techniques in the same attack chain merit attention.

The Countermeasure Mapper provides a way to identify which countermeasures address specific techniques or sets of techniques. An engineer who has identified a particular vulnerability can use the mapper to quickly identify the relevant defensive controls rather than manually searching through the full countermeasures catalog. The Control Mapper performs a similar function with respect to specific security control frameworks.

The Spacecraft Mapper tool connects SPARTA techniques to the Spacecraft Functional Decomposition framework, which provides a standardized way to describe spacecraft subsystem architecture. By linking attack techniques to specific functional elements of a spacecraft, the mapper helps engineers understand which architectural components are most exposed to which attack classes. This is particularly useful in threat modeling exercises where the goal is to understand how architecture choices affect the security posture of the system.

The JSON Creator allows users to build machine-readable representations of attack scenarios using SPARTA’s taxonomy. This supports automation and integration with other tools, including the Attack Flow capability developed separately, which provides a code-based and web-based tool for building and visualizing attack chains. Notional Risk Scores provide quantitative starting points for risk assessment, allowing programs to prioritize defensive investments based on the assessed severity and likelihood of different technique categories.

How Space Professionals Apply SPARTA

SPARTA is designed to support several distinct use cases in the space security community. The resources section documents three primary applications: space system developer, threat intelligence, and assessments and tabletops.

For space system developers, SPARTA provides a threat-informed basis for security requirements. Rather than deriving security requirements solely from general IT security standards that may not account for spacecraft-specific attack surfaces, engineers can use SPARTA to identify the specific techniques that apply to their mission and then trace those techniques to relevant controls. This produces requirements that are grounded in realistic threat scenarios rather than theoretical checklists. The March 2026 Countermeasure Prioritization framework further supports developers by providing a structured method for deciding which controls to implement first given limited budgets and engineering capacity.

For threat intelligence analysts, SPARTA provides a vocabulary for describing and communicating observations about space system threats. When analyzing an incident or a threat actor’s observed behavior, analysts can map behaviors to SPARTA technique identifiers, enabling precise communication with technical teams and government partners. The cross-references to MITRE ATT&CK further enable analysts who work across both enterprise and space domains to communicate effectively about actors who operate in both.

Assessors, penetration testers, and red teamers use SPARTA as a structured test methodology. The DEF CON 32 presentation from August 2024 demonstrated how a man-in-the-middle attack on ground infrastructure can realize many SPARTA techniques and sub-techniques simultaneously. The DEF CON 31 presentation from 2023 demonstrated best practices for extracting TTPs from reports and building various attack chains. The DEF CON 33 presentation from August 2025 went further, actively exploiting space systems using SPARTA techniques to generate realistic Indicators of Behavior (IoBs) that could inform intrusion detection system design.

Tabletop exercises are a particularly valuable application. Program managers and mission operations teams can walk through SPARTA attack chains to stress-test their incident response plans, identify communication gaps between engineering and security teams, and evaluate whether their monitoring and alerting capabilities would detect the specific behaviors cataloged in the framework. The combination of SPARTA’s structured taxonomy with the Navigator’s visualization capability makes attack chain construction and discussion straightforward even for teams without deep offensive security expertise.

Indicators of Behavior and the Detection Challenge

The Indicators of Behavior work linked from SPARTA’s related work section represents an important extension of the framework into the detection domain. Traditional cybersecurity detection relies heavily on indicators of compromise such as file hashes, IP addresses, and domain names. These indicators work reasonably well in enterprise environments but are less applicable to space systems, where many of the most dangerous techniques produce effects that are difficult to distinguish from normal operational anomalies.

An attacker who uses EX-0012.08 to modify attitude determination and control subsystem parameters doesn’t necessarily leave file hashes or network connections that an intrusion detection system can flag. The attack may manifest as increased gyro drift, unexpected mode transitions, or degraded pointing accuracy, all of which can also result from hardware aging or environmental factors. Distinguishing deliberate manipulation from natural degradation requires behavioral baselines, anomaly detection tuned to spacecraft operational profiles, and specific knowledge of what parameter changes look like when caused by attack rather than environment.

The 2025 DEF CON 33 research addressed this challenge directly by actually executing attacks against representative space system testbeds and recording what the resulting telemetry and log patterns looked like. This empirical approach produced IoBs derived from real attack scenarios rather than theoretical predictions. The resulting IoBs feed back into the SPARTA framework as a resource for building realistic, data-driven threat profiles for spacecraft intrusion detection.

SPARTA Versions and the March 2026 Release

SPARTA has evolved substantially since its initial release. The SPARTA Versions page tracks the history of updates, and the Updates page documents the specific changes in each release. Version 3.2, released on March 11, 2026, represents the most current state of the framework.

Earlier versions established the foundational tactic structure and populated techniques across the nine tactic categories. The October 2022 initial release coincided with a CyberSatGov presentation and introduced the framework to the broader space security community. Version 1.5 was documented in the October 2023 Value of Space Summit update, which covered the first year of SPARTA’s existence and introduced new features.

The AI and machine learning sub-techniques represent one of the more recent additions to the framework, reflecting the growing adoption of onboard AI in commercial and government space systems. Techniques EX-0012.13 (Poison AI and ML Training Data) and DE-0003.12 (Poison AI and ML Training for Evasion) acknowledge that as AI-driven autonomy, anomaly detection, and image processing move onto spacecraft platforms, the training data and model management pipelines become attack surfaces in their own right. The difficulty of auditing AI model behavior in operation makes these attacks particularly hard to detect.

The Component Collusion technique (DE-0012), added in a more recent version, addresses supply-chain attacks where multiple compromised software modules are designed to cooperate covertly. No single module appears malicious when analyzed in isolation; the attack only becomes visible when the modules are observed together, a challenge that strains traditional code review and static analysis approaches.

The credentialed techniques added across multiple tactics, including Credentialed Persistence (PER-0005), Credentialed Evasion (DE-0011), and Credentialed Traversal (LM-0007), reflect the growing recognition that spacecraft and ground systems face the same identity and access management vulnerabilities that have driven major enterprise breaches. The inclusion of these techniques in SPARTA pushes space system programs to apply the same rigor to credential management and access control that has become standard in enterprise security.

SPARTA’s Relationship to the Broader Space Security Architecture

SPARTA occupies a specific position in a larger ecosystem of space security resources. It deliberately focuses on unclassified, offense-informed knowledge that can be shared widely. This positions it as complementary to classified threat intelligence that mission planners and national security space programs receive through government channels; SPARTA doesn’t replace that intelligence but provides a common language for acting on it.

The Space ISAC has incorporated SPARTA as a common reference framework for its members, supporting information sharing across commercial, civil, and national security space operators. When a member experiences an anomaly that may indicate an attack, mapping the observed behavior to SPARTA techniques allows precise communication with other members and with government liaison partners who can cross-reference against classified reporting.

The framework’s relationship to MITRE ATT&CK is explicitly documented through informational references on each tactic page. Reconnaissance (ST0001) maps to ATT&CK’s TA0043, Resource Development maps to TA0042, Initial Access maps to TA0001, Execution maps to TA0002, Persistence maps to TA0003, Defense Evasion maps to TA0005, Lateral Movement maps to TA0008, Exfiltration maps to TA0010, and Impact maps to TA0040. These mappings enable threat intelligence reports that characterize adversary behavior in ATT&CK terms to be partially translated into SPARTA terms, though significant spacecraft-specific techniques have no ATT&CK equivalent.

The connection to the Space Segment Cybersecurity Profile (TOR-2023-02161 Rev A) provides a regulatory and acquisition pathway for SPARTA’s threat knowledge. Programs procuring spacecraft under government contracts that reference the profile find SPARTA embedded as a threat context reference, meaning the framework directly influences what security requirements are levied on contractors and how those requirements are tested.

The Convergence Problem in Space Security

Something in the SPARTA framework that doesn’t always receive enough emphasis is the degree to which it deliberately integrates what were historically treated as separate threat categories: cyber threats, electronic warfare, and kinetic counterspace. By placing jamming, high-powered laser attacks, and kinetic antisatellite weapons alongside software exploits and supply chain compromises within a single matrix, SPARTA forces programs to confront a challenge that siloed organizational structures often obscure.

A spacecraft defending against cyber threats alone remains vulnerable to an adversary who combines a software implant with selective jamming during a maintenance window. A program that monitors for RF interference but lacks software-defined radio security may be exposed to a technique that uses a compromised software-defined radio as an RF attack vector. The EX-0005.02 technique, Malicious Use of Hardware Commands, sits in the Execution tactic alongside software exploits because the practical effect, unauthorized state change on a spacecraft, is the same whether the mechanism is software or hardware. Treating them separately in organizational structure or defensive architecture creates gaps.

This convergence is not merely theoretical. The 2022 Viasat incident involved a cyber attack on ground infrastructure that disabled satellite modems across Europe, demonstrating that a cyber attack on the ground segment can produce effects on par with direct attacks on the space segment. Russian GPS jamming operations in Eastern Europe and the Middle East have been documented affecting both military and civilian navigation systems. China’s development of directed-energy weapons, rendezvous and proximity operations capabilities, and cyber units with demonstrated interest in space systems all appear within the threat context that SPARTA was designed to support.

The framework doesn’t resolve the organizational problem of integrating cyber, electronic warfare, and kinetic defense. That’s a program management and policy challenge, not a technical one. What SPARTA does is make the integrated threat visible in a single document that engineers, operators, policy makers, and security professionals can all reference without needing separate classified briefings for each domain.

Summary

SPARTA version 3.2, released by The Aerospace Corporation on March 11, 2026, provides the space security community with the most complete unclassified taxonomy of spacecraft attack behaviors currently available. Spanning nine tactics, more than 85 techniques, and hundreds of sub-techniques, it covers the full lifecycle of a space system attack from initial reconnaissance through impact, and it does so in a format deliberately borrowed from MITRE ATT&CK to enable communication and tool compatibility across the broader cybersecurity community.

The Reconnaissance tactic’s nine techniques and 27 sub-techniques establish how adversaries gather the engineering intelligence, operational intelligence, and cryptographic material needed to attack spacecraft effectively. Resource Development’s five techniques show how adversaries acquire or build the physical and digital infrastructure required for operations. Initial Access’s 13 techniques document the remarkably diverse pathways into space systems, from supply chain compromise before launch to proximity grappling in orbit. Execution’s 18 techniques and 40 sub-techniques, the richest tactic in the framework, catalog the specific mechanisms by which adversaries produce effects on and through spacecraft, spanning software exploits, hardware commands, spoofing, jamming, and physical destruction.

Persistence’s five techniques address how footholds survive reboots and recovery events. Defense Evasion’s 12 techniques and 17 sub-techniques describe sophisticated concealment methods that exploit the limited telemetry bandwidth and reduced monitoring characteristic of spacecraft operations. Lateral Movement’s seven techniques document how attacks spread through spacecraft architectures, constellations, and the interfaces created during docking and launch. Exfiltration’s 10 techniques address the multiple paths by which data can be stolen from space systems. Impact’s six techniques capture the full range of adversary end goals, from deception to destruction to theft.

The Countermeasure Prioritization methodology published alongside version 3.2 transforms SPARTA from a threat catalog into a design guide, giving programs a structured, risk-informed method for selecting and sequencing defensive investments. The Navigator, Countermeasure Mapper, and related tools make the framework computationally actionable rather than merely readable. The growing body of empirical research, including active attack demonstrations against representative testbeds published through DEF CON, grounds the framework in operational reality rather than theoretical possibility.

What may be the most important thing about SPARTA isn’t its content but its existence as a publicly available, continuously updated, community-supported resource. Before SPARTA, the space security community lacked a shared unclassified vocabulary for discussing how spacecraft could be attacked. Programs couldn’t easily compare notes. Engineers couldn’t efficiently communicate with security professionals. Operators couldn’t describe anomalies to each other in terms that mapped to known threat behaviors. SPARTA fills that gap, and the growing adoption across commercial operators, government programs, academic researchers, and security assessors suggests the gap was real and the fill is working.

Appendix: Top 10 Questions Answered in This Article

What is SPARTA and who created it?

SPARTA is the Space Attack Research and Tactic Analysis matrix, a publicly available framework created by The Aerospace Corporation to catalog the tactics, techniques, and sub-techniques adversaries use to attack spacecraft and space systems. Version 3.2 was released on March 11, 2026. The framework provides unclassified information to space professionals about how spacecraft may be compromised via both cyber and traditional counterspace means.

How many tactics, techniques, and sub-techniques does SPARTA contain in version 3.2?

SPARTA version 3.2 contains nine tactics: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Defense Evasion, Lateral Movement, Exfiltration, and Impact. The matrix includes more than 85 techniques across those nine tactics, with Execution being the most populated tactic at 18 techniques. Many techniques include sub-techniques, with Execution containing the most at 40 sub-techniques across its 18 techniques.

How does SPARTA relate to MITRE ATT&CK?

SPARTA was built using MITRE ATT&CK’s structure as a model, and each SPARTA tactic maps conceptually to an ATT&CK tactic through informational cross-references on each tactic page. For example, Reconnaissance maps to ATT&CK tactic TA0043 and Execution maps to TA0002. The relationship is deliberate: borrowing ATT&CK’s structure allows SPARTA to use existing tools, analyst skills, and communication norms from enterprise cybersecurity while addressing the unique attack surfaces of space systems.

What does the Execution tactic cover in SPARTA?

The Execution tactic (ST0004) covers the 18 techniques by which a threat actor executes malicious operations on a spacecraft, including replay attacks, PNT geofencing of malware, authentication modification, boot memory compromise, hardware and firmware exploitation, encryption bypass, single-event upset induction, time synchronized execution, code flaw exploitation, malicious code including ransomware and rootkits, exploitation of reduced protections during safe mode, modification of on-board values, flooding, spoofing of time and navigation and sensor data, side-channel attacks, jamming, and both kinetic and non-kinetic physical attacks.

What are the five Persistence techniques in SPARTA and why do they matter?

The five Persistence techniques are Memory Compromise (PER-0001), Backdoor (PER-0002), Ground System Presence (PER-0003), Replace Cryptographic Keys (PER-0004), and Credentialed Persistence (PER-0005). These techniques address how an adversary ensures their access and implanted capabilities survive reboots, mode changes, and recovery events. Replace Cryptographic Keys is particularly severe because successful execution can lock legitimate operators out of the spacecraft entirely while giving the adversary exclusive command access.

What is the Defense Evasion tactic’s Camouflage, Concealment, and Decoys technique?

Camouflage, Concealment, and Decoys (DE-0009) exploits the physical and operational environment to reduce detectability or mislead observers. Its five sub-techniques include hiding within a debris field, aligning operations with space weather events to blend with natural disturbances, triggering premature intercept of defensive resources using decoys, deceiving a target spacecraft’s onboard proximity sensors, and corrupting or overloading ground-based space domain awareness systems. These techniques have no equivalent in enterprise cybersecurity and reflect the unique physical environment of spacecraft operations.

How does SPARTA address supply chain security for space systems?

SPARTA addresses supply chain security across multiple tactics. During Reconnaissance, Gather Supply Chain Information (REC-0008) describes how adversaries map manufacturing, software, and business relationship chains to find chokepoints. During Initial Access, Compromise Supply Chain (IA-0001) covers software dependencies, software supply chain attacks, and hardware supply chain tampering. During Resource Development, attackers stage capabilities through compromised or controlled supply chain infrastructure. The framework recognizes that a spacecraft may arrive on orbit already compromised through a supply chain attack conducted before launch.

What physical attack techniques does SPARTA include?

SPARTA includes three categories of physical attack techniques. Kinetic Physical Attack (EX-0017) covers direct-ascent antisatellite missiles that launch from Earth to destroy a satellite, and co-orbital antisatellite vehicles that maneuver in space before striking. Non-Kinetic Physical Attack (EX-0018) covers electromagnetic pulse weapons, high-powered lasers that can dazzle or permanently blind optical sensors, and high-powered microwave weapons that can disrupt or destroy spacecraft electronics. These techniques make SPARTA unique among cybersecurity frameworks by explicitly incorporating weapon system threats alongside software exploits.

What tools does The Aerospace Corporation provide alongside SPARTA?

The Aerospace Corporation provides multiple tools through the SPARTA website. The Navigator allows visual exploration of the attack matrix and attack chain building. The Countermeasure Mapper identifies defensive controls relevant to specific techniques. The Control Mapper links countermeasures to standard security control frameworks. The Spacecraft Mapper connects attack techniques to spacecraft functional architecture. The JSON Creator produces machine-readable attack scenario descriptions. Notional Risk Scores provide quantitative starting points for threat assessment and prioritization.

How is SPARTA used in practical space security work?

Space system developers use SPARTA to derive threat-informed security requirements and validate architectural security decisions. Threat intelligence analysts use it as a vocabulary for describing observed adversary behaviors and communicating them precisely across organizational boundaries. Security assessors, penetration testers, and red teams use it as a structured methodology for conducting spacecraft security assessments. Operations teams use it in tabletop exercises to stress-test incident response plans. The Space ISAC incorporates SPARTA as a common reference for information sharing among commercial, civil, and national security space operators.