Who Signs the Proof? Attestation and Verifiability in Sovereign Space Technology
A government can own a satellite's payload and control its tasking, yet still rely on a chipmaker's attestation service to confirm that the satellite is running the code it was given. That's how remote attestation typically works, with a protected environment in the device proving itself to a service run by its manufacturer.
That dependency matters more as sovereignty in space shifts from ownership toward control. ABI Research describes the sovereignty buyers want today as operational and legal control rather than domestically built infrastructure, and sees incumbent operators building a middle tier that's more sovereign than leasing shared capacity but less sovereign than owning a dedicated satellite. That middle tier, along with every hosted payload and shared spacecraft arrangement, only works if trust can be proven to a party who will never touch the hardware.
We build infrastructure for exactly that position: Space Fabric and our security services are designed to ride on spacecraft that many parties share, where every operator and end user has verifiable evidence of their usage of hardware they can't inspect. Two properties carry that evidence: attestation and verifiability, and they're often misconstrued or lumped in together.
Attestation is what a system claims about itself. Verifiability determines whether anyone can check that claim without taking the issuer's word for it. And when it comes to sovereign space technology, we need both working in tandem to provide services all operators and end users can inherently trust.
Attestation is how a system produces evidence about itself
The IETF's Remote ATtestation procedureS (RATS) architecture gives the cleanest vocabulary for this. An attester produces evidence about its own state so that a relying party can decide whether to trust it, and a verifier sits between them, appraising that evidence against policy and reference values before the relying party acts on the result.
The evidence starts at a root of trust, a hardware component that measures the firmware and software running above it and signs those measurements with a key it protects. In our stack, attestation shows up in two places: our Key Management Service beta runs key operations inside an Intel TDX confidential virtual machine (CVM) on Earth, which produces signed evidence of the environment the keys are used in, and in orbit, Space Fabric generates attestation evidence from secure elements on the satellite itself.
The limit we design around is where that signature traces back to, since most terrestrial TEEs root their attestation in a single manufacturer's attestation service and sit in data centers where physical access eventually breaks every guarantee. When we first wrote about satellite-based TEEs in 2025, we named remote attestation as the open limitation of the model, because a sealed satellite is only useful to a third party if they can confirm what's running inside it. Attestation gives us the evidence, but on its own it still asks the relying party to trust whoever issued the keys.
Verifiability is how anyone else checks that evidence independently
An attestation report settles nothing until someone appraises it, which is why you see projects like Project Veraison treating verification as the central function of any attestation flow. Verifiability is the property that makes that appraisal open: the evidence, the reference values it's checked against and the verification software are all available to a party other than the issuer, so an operator can confirm a claim with tools they choose rather than a service the vendor runs.
We build verifiability into three layers of our stack, starting with hardware: Space Fabric uses Tropic Square's TROPIC01, a secure element whose architecture is open source and publicly auditable, so the root of trust itself can be inspected. The second layer is verification software, where the Space Fabric paper verifies attestation end to end using Veraison, an open source verifier adopted by the Confidential Computing Consortium and built on the IETF RATS terminology. The third layer is access, since our definition of open source includes open cryptographic verification of satellite workloads for the end user who queries them.
Without that openness, a satellite can produce correct attestation evidence and still leave its operator depending on one company's servers to interpret it, which is a weak position for any secure satellite system described as sovereign.
Attestation and verifiability answer different questions
Attestation answers what a system is claiming about itself, and verifiability answers who can confirm that claim and whether they need anyone's permission to do it.
The distinction matters most at the failure points: when attestation fails, the evidence is wrong, and when verifiability fails, the evidence may be correct but nobody outside the vendor can prove it.
Attestation and verifiability work as one trust chain
In Space Fabric, attestation and verifiability are designed as one chain, where each link removes a dependency the previous link couldn't remove on its own.
The chain starts with evidence: every attestation the system produces must be co-signed by two secure elements from independent vendors, Tropic Square's TROPIC01 and the NXP SE050, so no single chip, supplier or trust anchor can vouch for the satellite alone. Those signing keys are generated on orbit after launch, which means no critical key has ever existed on Earth where it could be copied or provisioned by a third party.
The second link adds location through our Satellite Execution Assurance Protocol. This protocol uses a distributed network of ground stations to confirm which satellite processed the data and verify that the correct code ran in a secure environment.
Each link in the chain is either open to inspection or split across independent parties, so the operator at the end never has to trust a single vendor, chip or ground station.
We combine attestation and verifiability on Earth today and in orbit next
On Earth, our Key Management Service (KMS) public beta runs key operations inside an Intel TDX confidential virtual machine, with keys held in an OpenBao Transit engine that never exports them. Key operations run inside attested TEEs, so you can verify the environment instead of trusting us. The beta is experimental and runs entirely on Earth, and the attestation-aware client flow that lets callers check that evidence directly is part of the near-term architecture laid out in From KMS to SpaceKMS.
In orbit, Space Fabric makes the satellite itself the orbital root of trust, where physical inaccessibility after launch becomes a tamper barrier that no terrestrial deployment can match. Because the secure elements are part of the payload hardware, Space Fabric is integrated before launch, which makes it a design decision for the next generation of spacecraft rather than something added to satellites already in orbit.
The path between the two runs from attested TEEs on Earth, through threshold cryptography that splits authority across independent trust domains, to SpaceKMS, where keys are born in orbit. Each step moves more of the trust chain outside the control of any single party, our own infrastructure included.
Verifiable trust makes sovereign space technology accessible
An operator who can verify the trust chain themselves keeps control of the trust question on hardware they don't own, and the dual-vendor anchor keeps any one chipmaker out of the critical path. That fits the definition of sovereignty buyers are using now, where operational and legal control counts for more than owning every layer of the system.
Accessibility is the other half of the case, because ABI expects defense-grade requirements to favor larger operators that can absorb the capital and R&D costs, squeezing smaller operators out. When sovereign-grade assurance requires a dedicated satellite, every ministry and operator that needs it launches its own, which is how the single-service siloes that waste capacity in orbit form in the first place. Verifiable trust on shared infrastructure lets a smaller operator or a newer space nation run a sovereign workload on a spacecraft it shares with others and still prove that workload's integrity independently.
Location ties the two together, since certifying which satellite a workload ran on gives an operator evidence that maps to tasking authority and jurisdiction, which attestation of the software stack alone can't provide.
Your Next Read:
Who signs the proof decides who holds control of a space system, and our answer is two independent secure elements in orbit signing it, with anyone running an open verifier able to check it.
The Space Fabric paper covers the full protocol and its security analysis, and our end-to-end threat model maps the attacks this trust chain is built to resist.
Developers can create an account to test the KMS public beta and see attested key operations on Earth before they move to orbit.
SpaceComputer is the open, credibly neutral infrastructure layer that connects the space economy, providing the hardware and software standard for verifiable compute and cybersecurity across operators, jurisdictions, and satellites, with high security guarantees and verifiability.
Visit our website for more information.
Don't forget to follow us on X (Twitter) and LinkedIn.
