Space Security: An End-to-End Threat Model for Space Systems
The Central Question
Which trust decisions across the Earth-to-orbit path can be independently verified, and what risks remain outside that evidence?
What a trust layer can and cannot stop
Space security discussions often begin with the spacecraft: anti-satellite weapons, close approaches, and radio-frequency interference. Those threats are real, but a space system is larger than the satellite. It includes several parties across the ground and space segments. We must consider users and operators; identities and authorization services; mission-control software and cloud infrastructure; ground stations and communication relays; radio links; onboard computers and workloads; payloads and sensors; and the systems that consume the resulting data.
An attacker does not need physical access to orbit if they can compromise a component the system already trusts. The broader pattern is familiar from cyber-physical attacks on critical infrastructure: compromise the authority or control path, and software can produce operational or physical consequences. Space infrastructure is part of the same attack surface.
The 2022 Viasat KA-SAT incident affected ground-side operations and modems rather than physically attacking a satellite. Earlier incidents involving NOAA systems, Landsat-7, Terra AM-1, and a controlled exercise against ESA's OPS-SAT likewise show credible paths through ground infrastructure, command channels, or onboard software.
This article models those paths end to end. Its purpose is not to claim that one security layer can stop every attack. It is to show what is being protected, what evidence can be produced, which assumptions that evidence depends on, and where Space Fabric and Orbitport, our solution to Space Internet Trust Layer, can - and cannot - contribute.
A satellite is the orbital endpoint of a system that begins with identities, software, cloud services, and ground infrastructure.
1. How this threat model was built
To build this model, we searched publicly documented attacks, intrusions, interference campaigns, and controlled security exercises affecting space systems. The review focused on incidents from recent years and selected earlier cases that established recurring attack patterns. Sources included government advisories, operator disclosures, academic and industry research, and reputable reporting.
Public reporting is necessarily incomplete. It is biased toward incidents that were detected, investigated, and ultimately disclosed. We therefore use these cases to identify credible attack paths and recurring failure modes - not to estimate the relative frequency, likelihood, or cost of each threat. So overall, each scenario is classified by the attacker's primary operational target. Real incidents may cross several categories and should receive more than one threat ID when appropriate.
2. Scope and system boundary
This is an end-to-end system model rather than a spacecraft-only model. It covers the path from a customer or operator, through identity and mission-control systems, cloud and ground infrastructure, the RF link, onboard execution, and finally the downstream user of space-derived data.
Kinetic and RF threats are included because they affect the same overall system. They remain explicit boundaries of a software trust layer. The model's primary focus is the security of authority, execution, cryptographic identity, and data provenance across the Earth-to-orbit path.
We introduce a concept framework called Trust Layer. The trust layer is defined as the set of identities, cryptographic keys, authorization rules, measured software and hardware states, execution and location claims, and data-provenance mechanisms that determine what an end-to-end space system accepts as authentic, authorized, and attributable. In simpler terms, the trust layer is the part of the system that decides what to believe and what to obey.
Therefore, it is important to keep in mind the following:
- Attestation is not authorization.
- Attestation shows what software and environment are running; authorization determines which identities may perform which actions.
- Provenance is not physical truth.
- Provenance establishes origin and integrity; it does not prove that a sensor reading or observation accurately represents reality.
- A quorum is not automatically independent.
- Multiple endorsements improve assurance only when the endorsers do not share a common point of control or failure.
- Evidence matters only when policy acts on it.
- Attestation and provenance become security controls only when failed verification causes the system to reject, restrict, quarantine, or escalate the operation.
Protected assets and security properties
Adversary Model
The adversary may obtain network access, steal or misuse valid credentials, compromise an operator account, cloud service, gateway, ground station, or communication relay, alter software or configuration, execute code in a compromised environment, and inject, modify, or replay data. The model also considers correlated compromise when components that appear independent share software, administration, vendors, networks, or credentials.
Kinetic weapons, hostile co-orbital activity, and RF denial are included as system threats. The model does not assume that an attacker can break well-established cryptographic primitives or simultaneously compromise every genuinely independent root of trust; those are explicit architectural assumptions, not guarantees.
Core Assumptions
- Attestation evidence is fresh and checked against correct reference measurements.
- Attestation is connected to enforcement: failed verification changes what the system permits.
- Ground stations used for triangulation are genuinely independent across administration, software, networks, credentials, and failure modes.
- Secure elements and key-generation paths have sufficiently independent failure modes.
- Identity, authorization, revocation, software update, and compromise-recovery mechanisms exist around the evidence layer.
- Time, monotonic state, and freshness mechanisms are trustworthy enough to resist replay and rollback.
3. Threat Taxonomy by Primary Target
Public reporting often groups very different events together: a missile test, a jamming campaign, a stolen password, or a compromised workload. Sorting threats by what the attacker primarily targets creates a useful first layer for the model.
These are primary targets, not mutually exclusive incident types. One incident may span RF, ground, and onboard compromise, so scenario IDs may be combined.
4. The End-to-End System Angle
A space threat model must show the full chain of authority, execution, and data rather than treating the spacecraft as an isolated endpoint. The diagram below places Space Fabric and Orbitport inside that chain and keeps kinetic and RF boundaries visible.
Trust Decisions Along the Path
At each trust boundary, the architecture should answer three questions: What claim is being made? What evidence supports it? What happens when verification fails?
Enforcement Principle
Evidence is not the security outcome. The outcome is the policy decision made from that evidence: refuse the session, withhold a key, deny a workload, require another approver, or label data as untrusted.
5. Threat Scenarios and Solution overage
The matrix separates the contribution of Space Fabric from the contribution of Orbitport and makes residual risk explicit. “Direct” means the described product mechanism provides the primary security property. “Conditional” means it helps only under stated assumptions or when combined with external controls. “Out of scope” means no material protection is claimed. “Requires explicit design” identifies a security property that the current product description does not establish on its own.
6. Security Properties the Architecture can Provide
Space Fabric and Orbitport do not eliminate trust. They move selected trust decisions from organizational assurances to evidence that a verifier can evaluate and make the trust assumption explicit. Each mechanism addresses a different part of the end-to-end path and depends on explicit technical and operational assumptions.
Attested Earth-to-Orbit Gateway
Orbitport can operate as an attested gateway following external mission control, or it can be integrated with mission-control and cloud workloads that run inside a TEE. In the integrated deployment, the mission-control workload produces evidence about its software, configuration, and execution environment. Its protected workload identity and fresh attestation can be bound to the secure session with Orbitport, extending the verifiable terrestrial boundary upstream into mission-control logic. Where mission control is not deployed inside a TEE, that boundary begins at Orbitport.
Security claim. A client, Orbitport, or another verifier can obtain evidence about the measured mission-control workload and the Orbitport environment handling a request, and can connect the live session to that evidence.
Depends on. Fresh TEE and gateway attestation, correct reference values, trustworthy roots of measurement, protected workload identity, and a protocol that binds both endpoints and the live session to the evidence.
Does not guarantee. Attestation of one workload is not attestation of the whole cloud. It does not establish user authorization or command safety; cloud IAM, the control plane, orchestration, storage, networking, external services, approved vulnerable code, side channels, and service availability may remain outside the measured boundary.
Evidence of Orbital Execution
SEAP relies on endorsements from multiple ground stations to reduce reliance on a single station or location claim. The resulting evidence can support a verifier's conclusion that execution occurred in the expected orbital context.
Security claim. The system can provide evidence consistent with execution by the expected in-orbit platform, under stated quorum and independence assumptions.
Depends on. Genuinely independent stations, reliable time and freshness, quorum availability, and resistance to collusion or correlated compromise.
Does not guarantee. Universal location proof, correct execution semantics, or protection when enough endorsers share the same compromised dependency.
Post-Launch Key Generation
Space Fabric generates cryptographic secrets after launch rather than relying exclusively on keys provisioned before launch. Trust is distributed across two secure elements rather than concentrated in one hardware root.
Security claim. The architecture can reduce exposure to pre-launch key handling and to compromise of one hardware root.
Depends on. Sound entropy, correct initialization, trustworthy firmware, and sufficiently independent secure elements and provisioning paths.
Does not guarantee. Elimination of supply-chain risk, resistance to every common-mode failure, or recovery after both roots are compromised.
Source Authentication and Provenance
Space-derived data can be signed close to its source so downstream systems can verify origin and detect subsequent modification or substitution. Orbitport can extend that assurance across an attested transport path.
Security claim. A consumer can distinguish data carrying a valid source identity and integrity proof from an unauthenticated signal claiming to be the same thing.
Depends on. Protected signing keys, trustworthy provenance metadata, freshness and anti-replay state, and a verifier that checks the evidence.
Does not guarantee. That the sensor observation is physically correct or that an authorized signing workload is behaving honestly.
7. Hard Problems and Residual Risk
A useful threat model is defined as much by its remaining risks as by its controls. The following questions should stay explicit in the architecture and in future product claims.
Authorization After Credentials are Compromised
Attestation can show what code handles a command and, in an integrated deployment, which mission-control TEE issued it. It does not show whether the person or service requesting that command is authorized for the action or has benign intent. A cryptographically valid malicious command sent through correctly attested mission-control and Orbitport environments remains valid unless a separate command policy rejects it.
The end-to-end design therefore needs a clear authorization story: strong identity, least privilege, command scoping, multi-party approval for critical actions, revocation, and audit. The architecture should state whether Space Fabric enforces any of this onboard, exposes policy hooks for an external system, or treats authorization as a separate dependency.
Independence and Correlated Compromise
A quorum is only stronger than one station when its members are independent in ways that matter. Stations operated by different organizations may still share the same cloud provider, software image, credentials, time source, or administrative tooling. The same principle applies to two secure elements: the number of components is less important than whether their failure modes are genuinely different.
Evidence, Enforcement, and Failure Semantics
Every verification check needs a defined consequence. Does a failed attestation block the session? Does a stale location proof withhold a key? Does an unavailable quorum stop execution, trigger failover, or place the mission in a degraded mode? Without an enforcement response, evidence becomes telemetry rather than a security control.
Availability and Recovery
Attestation and provenance primarily address integrity and authenticity. They do not by themselves provide service availability or compromise recovery. The architecture should separately define redundancy, rate limits, resource isolation, anti-rollback controls, measurement and key revocation, secure update, failover, and recovery after a root of trust or operator account is compromised.
Authenticity Versus Correctness
A valid signature proves that data came from the holder of a key and has not been modified after signing. It does not prove that the sensor was calibrated, the software interpreted the observation correctly, or the authorized workload was honest. Provenance should therefore be presented as evidence of origin and integrity, not as proof of physical truth.
8. What This Model Shows
Space security is an end-to-end systems problem. A mission can be compromised without physical access to the spacecraft: an attacker may steal authority on the ground, alter the software handling a command, compromise a trusted relay, run an unexpected workload in orbit, or substitute data on its way to a customer. The relevant question is therefore not only whether the spacecraft is secure, but which trust decisions across the Earth-to-orbit path can be independently verified.
Space Fabric and Orbitport address a defined subset of this problem. They are designed to provide evidence about the software and execution environment handling a request, the orbital context in which code ran, how cryptographic keys were established, and where resulting data originated. When mission control runs inside a TEE and is integrated with Orbitport, that evidence chain can begin in the mission-control workload, continue through the terrestrial access path, and extend to Space Fabric and the onboard workload. These mechanisms do not stop physical destruction or RF denial. They also do not by themselves prove that an authorized user is benign, that measured software is correct, that the surrounding cloud is fully trustworthy, or that a signed observation is physically true.
The objective is not to claim complete protection. It is to replace selected implicit assumptions with testable evidence, identify the assumptions that remain, and define what the system does when those assumptions fail.
The attacks that are hardest to see often win by looking like normal, authorized traffic. A verifiable trust layer makes selected parts of that authority inspectable - without pretending that every threat is a trust-layer problem.
If you want to explore how this applies to your satellite or constellation, reach out at product@spacecomputer.io or contact us.
Visit our website for more.
Follow us on X and LinkedIn.
The full trust architecture is in our research paper, Space Fabric.
