Space Fabric: What you need to know
We are building the standard hardware and software architecture for computing and the space internet in orbit.
Every secure computing chip protecting financial transactions, cloud workloads, and government data today has the same vulnerability: it can be physically accessed on Earth. Given enough time and physical access, an attacker can break into it. Two attacks demonstrated in 2025 and 2026 (TEE.fail and WireTap) defeated state-of-the-art memory encryption by physically intruding on the memory bus. These are inherent limitations of any hardware that an adversary can reach.
As compute moves to space, there is a need for standardizable, secure hardware and software architectures built for the complexities of space while exploiting unique features space provides.
Enter Space Fabric: our satellite-native security architecture at the core of SpaceComputer. It provides a verifiable trust layer for secure computation in orbit, adaptable across key management, confidential workloads, encrypted communications, and sovereign data processing.
This is the first architecture to combine Trusted Execution Environment (TEE) based remote attestation with a satellite-binding protocol and fully on-orbit security key generation.
Space Fabric Use Cases
Space Fabric creates a secure standard for space internet applications across the space stack, from Earth to orbit. By building a standard that is both adaptable to third-party systems and secure by design, we are creating a scalable hardware and software layer for anyone building in orbit. Some of the deeper and technical use cases outlined in the paper include:
Cybersecurity and orbital key management
On-orbit key genesis and non-exportable storage provide a hardware guarantee no terrestrial Hardware Security Module (HSM) can match. When the satellite de-orbits, the keys are destroyed during atmospheric reentry.
Confidential computing in orbit for sensitive workloads
Space Fabric enables secure computing where multiple customers can deploy proprietary workloads on a shared satellite, where each runs their code in an isolated TEE that neither the operator or any other customers can observe.
Secure satellite communications
For high-security operations in orbit, satellite operators require encrypted communication between satellites and satellite-to-ground infrastructure. Authenticated TEEs can distribute security keys as long as a ground-based verifier can confirm they are secure, supporting encrypted mesh networking across constellations.
Sovereign data processing
Sensitive Earth-observation or intelligence data can be processed onboard inside an authenticated enclave (TEE). Only verified analyzed outputs are downlinked. Raw data never reaches Earth, improving security, and cutting uplink/downlink costs for large amounts of data.
Orbital data center security
Orbital infrastructure operators that offer verifiable confidential computing to their customers need to be able to prove their security for customers and collaborators. Space Fabric is able to prove what code is running, where it is running, and that the hardware has not been tampered with.
Sensitive data model deployment
As orbital compute scales, proprietary AI models will be deployed onto orbital infrastructure where the model itself is the sensitive asset. Space Fabric's verifiable TEE ensures the model runs in an isolated environment where neither the satellite operator nor any other party can access, copy, or inspect the model weights or architecture.
Shared space infrastructure
When a single satellite has multiple organizations sharing orbital compute, communications, or sensor infrastructure, maintaining security and isolation between tenants is required. Space Fabric provides the trust layer that makes multi-tenant orbital infrastructure viable by giving each party independent, cryptographic proof that their workload is secure, isolated, and untampered with.
What Space Fabric Does Differently
Think about the relationship of trust in most tech infrastructure: when you deploy a sensitive workload on a cloud server, you agree to some terms and conditions or sign a contract where you trust that the hardware is genuine, and that the vendor’s properly handled their encryption keys, and that nobody has tampered with the machine. You cannot verify any of that independently.
Space Fabric addresses the two most fundamental of those risks:
1. It secures the root of trust by generating all cryptographic keys in orbit after launch,
2. It mitigates physical tampering by placing the hardware beyond human reach.
Below are five properties that separate Space Fabric from existing trusted computing systems:
1. Keys that are born in space and never existed on Earth.
Every major TEE platform (Intel SGX, AMD SEV, ARM CCA, OpenTitan) has cryptographic keys created during manufacturing. You must trust the vendor erased their copy, but have no way to verify this. Space Fabric generates all signing keys on the satellite after launch, inside two physically separate secure elements (SEs). Key slots are verified to be empty before launch. The trust assumption shifts from having to trust the vendor erased your secret to trusting the vendor correctly implements their published key-generation policy, which is independently auditable.
2. Two independent secure elements that must both agree.
Space Fabric splits its hardware trust anchor across two secure elements (hardware chips): the NXP SE050 (closed-source, Common Criteria EAL 6+ certified) and the Tropic Square TROPIC01 (fully open-source with published RTL and firmware, auditable to the gate level). Both must co-sign every attestation proof, so compromising one vendor's hardware is not enough. And the operator runs their own Veraison verification instance.
3. Proof of Execution Triangulation.
Existing TEE attestation proves what code is running. Space Fabric adds a second dimension of where, through Proof of Execution Triangulation (Proof of ET). Think of it as GPS verification. As the satellite orbits, independent ground stations around the world each verify they are communicating with the actual satellite, then sign off on its identity. Once enough ground stations have ‘triangulated its location’ and endorsed the satellite (enough to account for any that might be compromised), the satellite holds a Certificate of Authorization: mathematical proof that the computation is happening in orbit. The formal protocol behind this is the Satellite Execution Assurance Protocol (SEAP), detailed in the next section.
4. Physical inaccessibility as a security primitive.
A satellite at 500+ km altitude (and orbiting Earth at 27,000 km/h) requires nation-state anti-satellite capabilities to physically access. This is a categorically different threat model from even the most secure terrestrial data center, where the phrase ‘if someone can reach it, someone can breach it’ will always be possible.
5. Atmospheric re-entry as end-of-life security.
When a terrestrial server is decommissioned, the hardware can be recovered and forensically analyzed to extract residual key material. When a LEO satellite re-enters the atmosphere at end of life, every key, every secure element, and every piece of hardware onboard is physically and irreversibly destroyed. There are no decommissioned drives to recover, no residual secrets to extract, and no possibility of forensic analysis. No terrestrial system can offer that guarantee.
Space Fabric vs. Terrestrial TEE Platforms
How Space Fabric Works
Space Fabric operates through five phases. At the simplest level:
- Secure boot establishes the initial link and software on the satellite is authentic.
- On-orbit secret key genesis.
- SEAP and Proof of ET proves the TEE is physically in space.
- And dual secure element co-signing proves that no single vendor can be the weak link.
- Each layer closes a gap that terrestrial TEEs leave open.
For More Technical Detail:
The platform is built on ARM TrustZone, which splits a single physical CPU into two hardware-isolated partitions: a Secure World (the TEE) and a Normal World (untrusted).
The SEAP server runs inside the Secure World as a Trusted Application (TA). The Normal World has a relay application that blindly forwards messages between the external communication link and the Secure World. It can see the traffic, but it cannot tamper with what the TEE produces. The SEAP client runs on Earth, at the ground stations.
Secure boot establishes the initial link in the trust chain by ensuring the satellite only runs trusted software. At startup, the Boot Read-Only Memory (Boot ROM) authenticates the Trusted Operating System against a permanent hardware verification key. If the software version is incorrect, the system halts. Because this verification key is a public key, it can only validate signatures, preventing adversaries from using it to sign fraudulent software.
On-orbit key genesis provides the cryptographic foundation. On first boot after launch, the two onboard secure elements (SE), dedicated tamper-resistant chips whose sole purpose is to generate, store, and protect cryptographic keys, each create their own key pairs internally.
Each secure element produces an identity key pair (used to prove which satellite is signing) and an attestation key pair (used to prove the TEE is genuine and running the correct software). All four private keys are flagged as non-exportable. They cannot be read out by anyone or anything.
The pre-launch trust anchor consists entirely of public artifacts: serial numbers, device certificates, chip identifiers, and configuration hashes. No secrets are generated.
SEAP binds everything together through a three-message challenge-response exchange between each ground station and the satellite's TEE.
Each exchange takes 210 to 620 milliseconds. Certificate issuance requires 6 to 11 hours (roughly 4 to 7 orbital passes) as the satellite collects endorsements from geographically distributed ground stations. After that, every subsequent workload attestation needs only a fresh dual-signed token at 100 to 200 milliseconds.
Bandwidth overhead is approximately 1.9 kB per exchange, comparable to a small email. Under a post-quantum migration (hybrid ECC + Falcon), this grows to roughly 8 kB, well within LEO link capacity. SEAP is a one-time setup cost.
Space Fabric's Known Limitations
The Space Fabric paper includes formal limitation bounds on what the protocol provably cannot guarantee.
SEAP Certificate of Authorization runs once during setup
The protocol issues a Certificate of Authorization at launch that subsequent attestations reference. The lifecycle of re-attestation, including scenarios where satellite software is updated or a ground station committee member is compromised after certificate issuance is still an active research area.
Compute capacity is constrained compared to MW scale space computing developments
The first upcoming Space Fabric deployment(s) will run on an ARM Cortex-A7 (USB Armory Mk II). Early use cases are workloads where latency overhead is acceptable and the physical inaccessibility premium is highest: key management services, secure edge computing, sovereign data processing. As orbital compute hardware for both SpaceComputer and other orbital compute organizations mature for different organizations with different capacities (Watt and MW), Space Fabric's architecture is designed to scale with it.
Pre-launch supply chain window requires operational controls
Space Fabric's security guarantees begin after launch. The hardware integration period before launch, when physical access is possible, demands its own set of protections. The paper addresses this through pre-registered device identifiers and verified-empty key slots, but the gap between "the protocol is secure post-launch" and "the hardware is secure during integration" is an operational requirement we take seriously.
Post-quantum readiness
The current secure elements do not natively support post-quantum cryptography. We have a hybrid migration path: hardware-bound ECC for platform binding combined with software-based post-quantum signatures for quantum resistance. This allows Space Fabric to maintain its hardware trust anchors while adding protection against future quantum threats, a priority for any deployment with a 5 to 10 year operational horizon.
Where Space Fabric Fits in the Security Stack
Space Fabric is designed to serve as the trust layer for any organization running sensitive workloads in orbit or relying on orbital infrastructure from the ground. It integrates into existing security architectures the same way a hardware security module or cloud TEE service would, with one addition: the attestation proof includes cryptographic evidence that the computation is running on a specific satellite, physically inaccessible to any adversary.
For in-space companies operating satellites, constellations, or orbital data centers, Space Fabric provides the verifiable execution layer that their customers require before trusting orbital infrastructure with sensitive workloads. For Earth-based enterprises, Space Fabric connects through SpaceComputer's ground-facing services, allowing organizations to access orbital security guarantees through APIs and key management interfaces without needing to operate space infrastructure themselves.
Within SpaceComputer's own product suite, Space Fabric is the foundational layer on which other security services and solutions are built:
- Cosmic True Random Number Generator (cTRNG), which generates true random numbers from cosmic entropy onboard the satellite, operates within the secure elements that Space Fabric manages.
- Key Management Services (KMS), which provide orbital key generation, storage, and signing where keys are physically unreachable, run inside the attested TEE environment that Space Fabric certifies.
- Randomness Beacon, a publicly verifiable source of tamper-proof randomness generated in orbit, derives its security guarantees from Space Fabric's orbital inaccessibility and two independent secure hardware co-signing.
- OrbitPort, our secure communications gateway between ground systems and orbital infrastructure, depends on Space Fabric's attestation to prove that data is being handled by verified software on verified hardware in a verified location.
- SEAP (Satellite Execution Assurance Protocol): the protocol behind the architecture that binds workload to a specific satellite through a ground station endorsement, and is the core mechanism through which Space Fabric certifies orbital deployment.
- Proof of Execution Triangulation (Proof of ET): the verifiable proof that a computation is running on a specific satellite in orbit and not on a ground-based replica, is the attestation output that SEAP produces and that all Space Fabric services carry.
Space Fabric is the answer to a single question: why should anyone trust that these services are actually running in space and have not been compromised?
What Comes Next for Space Fabric
Space Fabric is our foundation. The combination of on-orbit key genesis, Proof of Execution Triangulation, and two independent secure hardware co-signing does not exist anywhere else. Each piece alone closes a real gap. Together, they establish a category of satellite security that is physically impossible to replicate on the ground.
What comes next is putting this hardware in orbit.
The full paper, "Space Fabric: A Satellite-Enhanced Trusted Execution Architecture," is available at arxiv.org/pdf/2603.23745.
Discover our next read:
Daniel Bar
Follow us on X (Twitter) and LinkedIn.
Visit the SpaceComputer Website.
Start developing with space infrastructure today! Head to our docs.
