Why Put a Key Management Service on a Satellite?

Every three months, a small group of people meets in a secure room in Culpeper, Virginia, or El Segundo, California to use the root key behind DNS security. The hardware holding that key stays sealed in a tamper-evident bag, inside a safe, inside a metal cage, and it can't be activated until three of seven independent community representatives present their smartcards while cameras stream the ceremony online.

The ceremony exists because protecting a high-value key has always come down to controlling who can physically reach it. A satellite takes that logic to its limit by putting the hardware hundreds of kilometers overhead, which is why we're taking SpaceComputer's Key Management Service (KMS) into orbit, with two missions already announced for 2027.

A Satellite Key Management Service Keeps Key Authority Out of Physical Reach

A satellite key management service generates, stores, and uses cryptographic keys on hardware in orbit, where nobody can physically reach them after launch. Applications request a signature and receive the result while the key stays on the satellite, and the strongest designs pair the orbital system with a KMS on Earth so that sensitive operations need approval from both.

Our KMS is in public beta on Earth today, and it's experimental and not yet production-ready. Our first mission is planned for early 2027 and will run key generation and signing on the satellite's secure hardware.

Every Security Guarantee Ends at a Key, and Most Keys Live in Buildings

HTTPS connections, software updates, and remote attestation all depend on a private signing key staying private, so attackers who can't hack the math try to hack the key directly instead. A hardware security module (HSM) keeps keys inside tamper-resistant hardware, and a KMS adds access policy, rotation, and audit logging on top.

Those controls work well, and on Earth they still sit in a building that someone with enough motivation can still gain access to. Physical access is the hardest of those risks to remove. One of the best examples of this is when researchers built a memory bus interposer for under $1,000 and used it to attack Intel and AMD trusted execution environments (TEEs), the isolated processor regions designed to protect code from the machine around them.

The other second exposure that needs to be obfuscated comes before deployment, because most TEE platforms root their attestation in secrets provisioned during manufacturing, which leaves customers trusting that a vendor generated each key correctly and didn’t retain a copy.

Key Management Is One of the Few Workloads That Make Sense in Orbit Today

Most computation will stay cheaper on Earth for the near to medium term, so the useful question is which parts of the stack gain enough from physical separation to justify a launch. Key management is a strong candidate because it's authority-dense: it needs modest compute and little bandwidth, and it controls the signatures and decryptions that authorize far more valuable systems.

The protocol we use to bind a satellite to its keys transfers about 1.9 kB per ground station exchange, a footprint small enough to put on-orbit key management within reach of current small satellite platforms well before large orbital data centers arrive.

A Satellite Changes When Keys Are Created and Who Can Reach Them

On-orbit key generation removes the manufacturing window. In our design, signing keys are created inside secure hardware on first boot after launch and marked non-exportable, so only public information, such as serial numbers and configuration hashes, is registered on the ground. An identical device left on Earth would generate different keys and fail verification, which is what lets the satellite act as an orbital root of trust.

Physical inaccessibility replaces the locked room. Once deployed, the hardware is out of reach for any adversary short of a nation-state with anti-satellite capabilities, and an unexpected approach would show up in orbital tracking and telemetry.

An orbital system also gives key authority physical and possibly jurisdictional separation from any single data center or cloud provider. At the end of a mission in low Earth orbit, a satellite gets automatic security from burning up in atmospheric reentry, which destroys the hardware that held its keys along with the spacecraft.

Orbit Adds the Most Security When Earth and Space Both Have to Approve

A KMS on a satellite changes where a key sits, and a single system still holds the authority to use it. Satellites also carry their own supply chain, communication, update, and hardware risks, so satellite cybersecurity still depends on secure boot and remote attestation to make the orbital system verifiable.

Separation of authority begins when independent systems on Earth and in orbit must jointly authorize a sensitive operation through threshold signatures, multisignature schemes, or co-signing. A compromised data center can't complete a signature alone under that model, and neither can a compromised satellite.

Joint approval suits the keys where a wrong signature does the most damage, such as root keys and high-value approvals, while everyday keys can stay in a simpler single-system setup.

We Built Our KMS on Earth to Take It Into Orbit

We started with key management because it's where a small system holds the most authority, and we started on Earth so developers could test it now. Our KMS is designed for space and validated on Earth, which means real users exercise the API, the key policies, and the failure modes before those interfaces move onto constrained satellite hardware.

The question we ask operators is where in their workflow they have to trust a provider with no way to verify what happened. For teams weighing sovereign or distributed infrastructure, the answer often comes down to who can exercise a signing key and whether a single provider holds too much of that authority.

On our first mission, signing keys will be generated and used on the satellite's secure hardware. Under the Space Fabric design, those keys are created after launch inside secure elements from two vendors, NXP and Tropic Square, and both chips must co-sign attestation evidence so that no single supplier anchors the result.

The first flight will also run the Satellite Execution Assurance Protocol (SEAP), in which independent ground stations endorse the satellite's identity key, binding it to that spacecraft so a replica on the ground can't pass verification as long as enough stations stay honest.

Five Applications for Key Management in Orbit

These applications share one trait: an operator has to trust a signature or decryption produced by a system they can't inspect.

Satellite Software Updates Need Approval the Ground Can't Grant Alone

Once a satellite launches, software updates are the only maintenance it will ever get, so an operator needs confidence in who authorized each one. A payload can accept only signed update bundles, and joint approval from Earth and orbit would keep a compromised ground system from pushing an update on its own. Measured boot then lets a customer check which software version is running.

AI Agents Can Sign Transactions Without Holding the Signing Key

An AI agent with a wallet only needs a revocable token while the wallet key stays in the KMS: the agent builds the payment and asks the KMS to sign it, and an attacker who compromises the agent has no key to copy. Per-key policies can cap spending or restrict destinations, and an orbital co-signature could sit behind the largest approvals, keeping that authority outside the environment where the agent runs. A KMS limits what a compromised agent can take, and teams still need separate defenses against prompt injection. As agents are given more tools and can take more actions, a KMS will only continue to grow in importance.

Earth Observation Images Can Carry a Fingerprint From Capture

A customer asking whether a vessel was at a location yesterday may receive an image that passed through several providers, and an encrypted link stops protecting that image once the transfer ends. A key on the payload can sign a cryptographic fingerprint of the image at capture, and remote attestation can record the software that handled it, so a third party can check both after the file has been copied or sold on. That evidence shows specific bytes were recorded at a defined point on the payload, while sensor calibration and the meaning of the scene remain separate questions. We're developing this capture flow for an upcoming mission.

Multi-Tenant Payloads Need Keys the Host Operator Can't Read

Sharing a satellite between customers depends on each tenant's keys staying out of reach of the operator and every other tenant. Secure hardware integrated before launch would give each tenant that separation on infrastructure designed for shared spacecraft, and multi-tenancy is a capability we're working toward demonstrating on upcoming missions.

Orbital Data Centers Need a Way to Prove What Ran

As orbital data centers and on-orbit processing grow, tenants will want to verify what executed, where it executed, and who authorized it. An orbital KMS can hold workload identity keys and sign results before they leave the spacecraft, giving customers evidence that travels with the output.

High-Frequency Signing Should Stay Close to the Workload

With how orbit infrastructure operates in present day, it is not a strong fit for signing every API call. A low Earth orbit satellite might reach a given ground station for about 10 minutes of every 90-minute orbit, and a geostationary satellite stays in view from nearly 36,000 kilometers away, so availability and latency both have limits.

The practical split keeps operational keys on Earth near the applications using them and reserves orbit for root keys and approvals that justify the extra step. Our API and policy model are built to stay consistent across both, so extending a key's authority into orbit won't require rewriting the application.

Frequently Asked Questions

Is SpaceComputer's KMS running in space today? Our KMS runs on Earth in public beta. Our first mission, planned for early 2027, will run key generation and signing on the satellite's secure hardware.

What is on-orbit key generation? On-orbit key generation creates a private key on a satellite after launch, so the key is never present on the ground. A verifier then only needs public device information registered before launch to check where the key came from.

Is a satellite more secure than a hardware security module? They address different risks. An HSM offers tamper protection in a facility someone controls, while a satellite removes physical access after launch and adds its own radio, software, and supply chain risks, so a satellite adds the most when it works alongside keys on Earth.

Why not use a second cloud region instead of a satellite? A second region improves availability, and either region can still act alone unless policy or cryptography requires both to agree. An orbital domain adds physical separation to that joint approval.

What happens to keys when a satellite is retired? A satellite in low Earth orbit gets automatic security from burning up in atmospheric reentry, which destroys the hardware holding its keys.

You can test our Key Management Service on Earth today. Create an account to start with 500 free credits during the beta, and talk to our team if you're planning a mission or evaluating key management in orbit.

Follow along on X and LinkedIn as we get closer to launch.

SpaceComputer is building sovereign compute and secure communications infrastructure for the Space Internet.

Space is evolving from isolated missions into shared infrastructure. We're bringing technologies established in terrestrial computing, confidential execution, hardware-rooted security, cryptographic attestation, and key management, into space. Our goal is to make orbital compute and communications accessible as secure, interoperable services, without requiring every customer to build and operate their own satellite infrastructure.

Visit our website for more information.