For years, space cybersecurity suffered from a language problem. Network defenders had MITRE ATT&CK, a shared map of how attackers actually behave. The space community had nothing equivalent, so spacecraft threats got described in scattered, often classified terms that were hard to share and harder to act on.
SPARTA has gone a long way toward closing that gap.
What SPARTA is
SPARTA stands for Space Attack Research and Tactic Analysis. The Aerospace Corporation built it to give space professionals an unclassified, common vocabulary for how space systems get attacked. If you know ATT&CK, the shape is familiar: a matrix of tactics across the top, with specific techniques and sub-techniques listed underneath each one.
The tactics describe the attacker's goals in order, from first contact to final effect: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Defense Evasion, Lateral Movement, Exfiltration, and Impact. Under each, SPARTA catalogs the concrete techniques an adversary can use against a spacecraft and the systems that operate it. It also cross-references countermeasures, mapped to standards like NIST and ISO, so the matrix is not just a threat list. It is a defensive planning tool.
You can browse the full SPARTA matrix on The Aerospace Corporation's site: tactics across the top, techniques beneath each.
The value is not any single entry. It is that the whole community can now point at the same square and agree on what they are talking about. That shared map is what makes a real attack path easy to follow.
Walking an attack path: from the ground station to the satellite
The instinct is to picture an attack on a satellite as something dramatic in orbit. In practice, the reachable way in is almost always on the ground. SPARTA lets us trace that route step by step.
It starts with Reconnaissance. The attacker studies the operator: who runs the mission, what ground stations they use, which vendors and people are involved. Most of this is public.
Next comes Initial Access to the ground segment. The mission operations network is, underneath the space mission, an enterprise network. It has internet-facing services, operators who log in, and software that needs patching. A phished credential or an exposed service is enough to get a foothold, no orbital wizardry required.
From there the attacker moves through Execution and Persistence, running commands on an operator workstation and making sure they keep their access. Defense Evasion keeps that activity quiet, blending in with normal operator behavior so the team sees nothing unusual.
Then the important step: Lateral Movement from the ordinary IT side of the ground network into the mission systems, the ones that build and send commands to the spacecraft. This is the seam most programs miss, because the people who defend the enterprise network and the people who run the spacecraft are usually different teams.
The common assumption is that a separate network for satellite control closes this seam. It helps, but separation on a diagram is rarely separation in practice, because something almost always has to cross the boundary to get work done. A few of the bridges we see regularly:
- The dual-use workstation. An operator or engineer needs both email and the mission network, so their machine sits on the IT side and VPNs into the trusted control network. Compromise that one endpoint and the VPN carries the attacker straight across the gap, using a connection the firewall is built to allow.
- The vendor jump box. Spacecraft and ground software come with vendors, and vendors need remote access for support, usually through a trusted jump host into the control network. If the vendor is compromised upstream, the attacker inherits that trusted path. The control network sees a known partner logging in, not an intruder.
- The shared account or shared media. One set of admin credentials reused across both networks, or a laptop and a USB drive that touch each side in turn, quietly stitch the two environments back together.
In every case the separation held on paper. The attacker just used the thing that was allowed to cross it.
Now the attacker is holding the keys. They do not need to defeat the satellite's defenses from the outside. They send valid commands through the legitimate uplink, the same path the real operators use. That is where the Impact lands: denying service, degrading a sensor, repointing an antenna, or worse. The damage happens in orbit, but every step that led there happened on the ground.
Read that path back and the lesson is clear. The satellite was never the soft spot. The command path to it was.
When the ground station is in the cloud
That attack path assumed a ground station you own and run. Increasingly, you do not. A growing share of operators rent the ground segment instead of building it, paying for satellite contacts the way they pay for compute. Ground Station as a Service turns a field of antennas into an API call.
The market has a few serious players. AWS Ground Station is the surviving hyperscaler offering: you reserve a contact, the antenna talks to your spacecraft, and the data lands in your own cloud account within seconds, with access governed by AWS identity controls and traffic encrypted through managed keys. Alongside it sit the dedicated networks. KSAT runs the largest commercial ground network, with its KSATlite service built for high-volume small-satellite operators. ATLAS Space Operations leans software-first, automating contacts through its Freedom platform. Viasat Real-Time Earth brings a global downlink network and deep government and defense roots.
The convenience is real, and so is the shift in attack surface. SPARTA still maps the attack, because the tactics do not change. The terrain does. Initial Access and Lateral Movement no longer mean walking into a building. They mean a stolen API key, an over-permissioned identity role, a misconfigured network endpoint, or a weak link in the provider relationship. The model is shared responsibility: the provider secures the antenna and the physical infrastructure, while you still own identity, encryption keys, your mission configuration, and the pipeline that carries commands and data into your cloud. A misconfigured role is the new unlocked door.
None of this makes the ground segment less important. It makes a shared map of the attack more valuable, not less, because now the terrain spans your networks, your provider's, and the seams between them.
How we teach SPARTA in CFS
A framework like SPARTA tells you what to look for, but recognizing those techniques in a live system is a skill you have to practice. Knowing that Lateral Movement exists is different from spotting it, stopping it, and tracing where it leads, from the enterprise network all the way to the satellite.
That is why SPARTA runs through our Cybersecurity Fundamentals for Space course, an ANAB-accredited certificate program. Students do not just read the matrix. They apply it through hands-on labs and practical exercises, mapping real techniques to real systems. The course culminates in a capstone on our IRON GALAXY Space Cyber Range, where you take control of your own space enterprise and fight through realistic cyber attacks, the exact ground-to-satellite path described above, played out against a live mission operations environment.
Interested in learning how to apply SPARTA, defend your space platforms, and build real resilience into your operations? That is what Cybersecurity Fundamentals for Space is built to deliver.
References
- Brandon Bailey, "Building Space Attack Chains using SPARTA," DEF CON 31 Aerospace Village (2023): watch on YouTube.
- Randi Tinney, "From Theory to Reality: Demonstrating the Simplicity of SPARTA Techniques," DEF CON 32 Aerospace Village (2024): watch on YouTube.
- Brandon Bailey, "Hacking Space to Defend It: Generating IoBs with SPARTA," DEF CON 33 Aerospace Village (2025): watch on YouTube.
- SPARTA resources and publications and the SPARTA overview, The Aerospace Corporation.