Post-Quantum Cryptography and the Satellite Problem

Here's an uncomfortable piece of arithmetic:

• A satellite launched today will operate for five to fifteen years.
• Credible estimates for "Q-Day", the arrival of a quantum computer big enough to break current public-key cryptography, cluster between 2029 and 2035.

See the problem here? Those two timelines overlap, and unlike your web server, a satellite can't be re-keyed with a maintenance window and an apology email. The cryptographic decisions baked in at design time govern the entire mission.

In fact, this is such a big problem, Google has already pulled its internal post-quantum deadline forward to 2029. The deadline is quite real, and orbital hardware happens to be the hardware least equipped to miss it.

The 60-second version of the problem

Today's public-key cryptography (RSA, elliptic curves, Diffie-Hellman) rests on math problems classical computers can't solve in any useful timeframe: factoring big integers, and computing discrete logarithms. Breaking a 2048-bit RSA key classically takes longer than the universe has been around!

However, non-classically, things take a big turn. Shor's algorithm, published back in 1994, solves exactly those problems exponentially faster on a quantum computer. The catch has always been building a quantum computer large and stable enough to run it. Once one exists, everything downstream of RSA and ECC becomes forgeable or readable: TLS handshakes, code signing, on-chain transactions, etc.

Post-quantum cryptography (PQC) is the fix, and it's less exotic than it sounds: new algorithms built on math problems (mostly lattices and hash functions) that neither classical nor quantum computers can crack efficiently. There's no specific hardware required to implement it, although not all chips are ready to accelerate these operations to the same speeds as classical cryptography. PQC runs on the same servers, phones, and satellite computers as today's cryptography, and NIST has even standardized the replacements:

So the migration story is not "wait for the standards". That ship has sailed a few years ago. The story is deployment, and deployment is where satellites get interesting.

Threat one: harvest now, decrypt later

Most of us fall in the "we're safe until Q-Day" trap. Unfortunately, it's not that easy, because encrypted data can be recorded. Let us fuel those nightmares a little bit:

An adversary who captures your encrypted traffic today can simply store it and decrypt it the day quantum hardware catches up. This is called harvest now, decrypt later, and the more you think of it, the longer you'll stay awake at night. When you visit a website and you establish an SSL handshake with it, that handshake may not be quantum safe. Someone capturing that handshake can and will decrypt it in a few years.

For satellite links this is somehow even worse: downlinks are radio broadcasts over huge footprints. Anyone with a dish and patience can record them. The satellite communication page explains why interception has always been assumed in link design.

So for PQC, the question we want to ask isn't "when does quantum arrive?" but "will this data still matter when it does?". If it's telemetry with a shelf life of minutes, nobody cares. But earth-observation imagery, key material, anything sovereign or medical or proprietary with a ten-year confidentiality requirement... it's already exposed, today, if it crosses a link protected only by classical key exchange. That's what makes ML-KEM the urgent half of the migration. Confidentiality is the guarantee you can lose retroactively.

Threat two: forged history

The subtler casualty is attestation. Remote attestation, the mechanism SpaceTEE and Space Fabric build on, is a chain of signatures rooting in keys fused into silicon. When quantum computers can break the elliptic-curve keys at those roots, an attacker can do worse than impersonate hardware going forward: they can fabricate plausible-looking evidence about the past. Any historical attestation, audit log, or command-provenance record verified only by a quantum-broken key stops being evidence.

For confidentiality you can at least triage by data lifetime. But for integrity of records, the deadline is harder: the fix requires new roots of trust, and the industry's current confidential-compute platforms all root trust in ECC keys provisioned at fabrication. Replacing those is a hardware cycle, which takes a decade or so (one exception: hash-based constructions. Signatures like SLH-DSA and hash-based proof systems lean only on hash functions, which quantum computers merely dent rather than break. A proof generated in 2026 stays verifiable in 2040 regardless of how Q-Day shakes out.)

Now add the orbital constraint from the top of the page: you cannot swap silicon at 500 km. A satellite that launches with a quantum-vulnerable, non-upgradable root of trust has a cryptographic expiration date, and it was set on launch day.

Crypto-agility, or "don't marry an algorithm"

The design lesson generalizes past satellites. Since standards will keep evolving (FN-DSA is still in draft, parameters get revised, implementations get broken, etc), the systems that survive the transition are the ones where swapping an algorithm is a configuration change, not a hardware revision or a code rewrite. That property has a name, crypto-agility. It's pretty cheap at design time but brutally expensive to retrofit.

The most common and practical pattern during the transition is hybrid deployment: run a classical algorithm and a post-quantum one together (ex. X25519 and ML-KEM for key exchange, or ECDSA and ML-DSA for signatures), so security holds as long as either layer does. You pay a cost, since PQC keys and signatures are larger, and that stings precisely where satellites hurt most: on constrained radio links. But you're never worse off than the stronger of the two schemes.

If you operate anything with a long deployment life, satellite or otherwise, three questions are worth asking your vendors now:

1. Are the algorithms NIST PQC standards, or something bespoke?
2. Can the system swap algorithms without hardware changes?
3. What's the actual migration timeline if Q-Day lands in 2029 rather than 2035?

How SpaceComputer handles it

Space Fabric was designed after this problem was visible, which bought it the luxury of being algorithm-agnostic from the start. The attestation, endorsement, and verification layers treat the signature scheme as pluggable rather than welded in.

The concrete plan is the hybrid pattern above, applied to orbit. Hardware-bound elliptic-curve keys in the secure elements keep doing what they're uniquely good at, which is binding identity to one specific physical chip, while quantum-resistant signatures (ML-DSA) are layered on top in software, with the satellite's TPM as an independent root of trust for post-quantum provisioning. Current secure elements don't natively speak PQC yet (almost none do), so this hybrid path is how you get quantum resistance without waiting a hardware generation. The measured overhead is tolerable even on space links: attestation exchanges grow from about 1.9 kB to about 8 kB under the hybrid ECC + FALCON configuration.

The honest status: this is a migration in progress, not a solved checkbox. Which is exactly the posture the timeline math demands from anyone launching hardware this decade.

Further reading

• What Is Post-Quantum Cryptography? -- the fundamentals, algorithm families, and a five-step readiness checklist
• The Post-Quantum Cryptographic Expiration Date on Every Satellite You're Launching -- the satellite-specific argument in full
• Space Fabric -- where the hybrid PQC roadmap lands in the hardware
• NIST Post-Quantum Cryptography project -- the standards themselves