An uncrewed spacecraft is only as trustworthy as the radio link that commands it. There is no pilot to take manual control and no operator on board to notice something is wrong. Telecommand goes up, telemetry comes down, and the vehicle does what the uplink tells it to do. That link is the single most valuable thing to protect on the entire mission, and it is precisely the thing a large quantum computer is built to undermine.

The threat is neither hypothetical nor distant. Signals intelligence organisations already record encrypted traffic they cannot yet read. Spacecraft launched now will still be flying when a cryptographically relevant quantum computer is a realistic prospect. For most missions the cryptography chosen at design freeze is the cryptography that flies for the life of the vehicle. Getting it wrong is not a patch away from being fixed.

This note walks through what actually breaks, what the standards bodies now require, and why space is the hardest place in which to make the switch.

What a space link actually carries

A spacecraft link is usually split into three flows. Telecommand is the uplink that controls the vehicle. Telemetry is the downlink that reports its state. Payload data is the downlink that carries what the spacecraft was launched to collect. The command uplink is the crown jewel. An adversary who can forge or replay a valid command can manoeuvre, safe, or brick the vehicle. Confidentiality matters, but for telecommand, authentication and integrity matter more.

Most space links today are governed by the Consultative Committee for Space Data Systems. Its Space Data Link Security protocol, SDLS, provides authentication, integrity and optional confidentiality at the data-link layer. SDLS is deliberately conservative. It relies exclusively on symmetric cryptography with keys pre-shared between the ground segment and the flight segment, and its extended procedures add security association and key management on top.

That symmetric-only design has a useful property. Because it does not depend on RSA or elliptic-curve key exchange in flight, the confidentiality of an SDLS link is not directly broken by a quantum computer. The weakness sits elsewhere. Pre-shared symmetric keys are hard to distribute, hard to rotate, and hard to recover after a compromise, especially across large constellations and multiple ground stations. The asymmetric cryptography that a quantum computer does break tends to live in the surrounding infrastructure: the ground-segment public-key infrastructure, the key-establishment handshakes, and the code and firmware signing that authorises what runs on board.

Why the quantum threat lands hardest in orbit

Three properties combine to make uncrewed spacecraft an unusually exposed target.

Harvest now, decrypt later. A passive adversary records ciphertext today and stores it. When a capable quantum computer arrives, the stored traffic is decrypted retroactively. Any secret with a shelf life longer than the arrival date of that machine is already at risk. Mission plans, sensor tasking and key material all qualify.

Lifetime. A satellite designed today can carry a service life of ten to fifteen years or more. A vehicle launched at the end of this decade may still be operating in the 2040s. It has to stay secure across that whole window, not just at launch.

No recall. A terrestrial system can, in principle, be patched. A spacecraft cannot be brought back to have its cryptographic core replaced. Whatever ships is what defends the vehicle for its entire life, unless the design anticipated change from the outset.

What a quantum computer actually breaks

It is worth being precise here, because "quantum breaks encryption" is too blunt to design against.

Public-key cryptography is the casualty. Shor's algorithm, run on a sufficiently large fault-tolerant quantum computer, solves integer factorisation and the discrete logarithm problem in polynomial time. That breaks RSA, Diffie-Hellman, and elliptic-curve schemes including ECDH and ECDSA. These are the algorithms that establish session keys and authenticate parties across almost every ground segment and PKI in service today.

Symmetric cryptography is weakened, not broken. Grover's algorithm gives a quadratic speedup on brute-force search, which roughly halves the effective strength of a symmetric key. AES-128 drops to around 64 bits of quantum security, which is uncomfortable. AES-256 drops to around 128 bits, which remains sound. The practical response is to use 256-bit symmetric keys and long hash outputs, not to abandon symmetric cryptography.

So the migration is targeted. The job is to replace quantum-vulnerable key establishment and signatures, harden symmetric key sizes, and keep the symmetric core in place.

The toolkit

The post-quantum standards

In August 2024 NIST published the first three post-quantum standards.

FIPS 203 specifies ML-KEM, a key-encapsulation mechanism derived from CRYSTALS-Kyber. It replaces RSA and elliptic-curve key exchange. Its security rests on the Module Learning With Errors problem, for which no efficient quantum algorithm is known.

FIPS 204 specifies ML-DSA, a lattice-based signature scheme derived from CRYSTALS-Dilithium and built on the same family of hardness assumptions.

FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme. It is slower and its signatures are large, but its security rests only on the properties of hash functions, which makes it the conservative choice for signatures that must remain valid for decades.

The cost of the switch is size. Post-quantum keys and signatures are substantially larger than the classical values they replace. On a link that is already bandwidth-constrained, that size is not an accounting detail. It is a system-design constraint.

An ML-DSA-65 signature is roughly fifty times the size of an ECDSA P-256 signature. An ML-KEM-768 public key is around eighteen times an X25519 key. On a fat terrestrial pipe this is absorbed without comment. On a spacecraft link measured in kilobits per second, every extra kilobyte in a handshake is airtime, energy and exposure.

Why space is different

Bandwidth. Command links are narrow. Many deep-space and small-satellite links run at data rates where a multi-kilobyte handshake is a meaningful fraction of a pass. Larger keys and signatures consume airtime the mission needs for its actual work, and they cost transmit energy the power budget may not have.

Latency. A key-establishment handshake is a conversation, and every round trip costs propagation delay. In low Earth orbit that is tolerable. To the Moon it is seconds. To Mars it runs from minutes to more than twenty minutes one way. Any scheme that needs several interactive round trips to agree a key is punished heavily by distance. Protocols that minimise or eliminate the in-flight handshake win.

Compute and power. Flight processors are radiation-hardened and years, sometimes decades, behind commercial parts. Lattice cryptography is not free. Its polynomial arithmetic and sampling load a constrained processor, and every cycle is power. The algorithms have to be implemented to fit the hardware that is actually flying, not the hardware on an engineer's desk.

Radiation. Single-event upsets can flip bits in memory and registers. Cryptographic state, counters and keys have to survive that environment without failing open or losing synchronisation, which constrains how key schedules and anti-replay mechanisms can be designed.

Re-keying. On the ground, rotating a key is routine. On a spacecraft it is a scheduled operation across a contested, delayed, narrow link, and it has to be robust to interruption. SDLS being symmetric and pre-shared keeps confidentiality quantum-safe, but it also makes key distribution and post-compromise recovery the operational bottleneck.

Design patterns that survive contact

The research and standards communities have converged on a set of approaches that fit these constraints.

Hybrid key establishment. During the transition, combine a classical algorithm with a post-quantum KEM so the session holds if either component does. This hedges against both a quantum break and an undiscovered flaw in a young lattice scheme, and it is the mainstream migration pattern across both NCSC and NSA guidance.

Keep the symmetric core, fix the key management. SDLS already protects the link with symmetric cryptography. The productive move is not to replace that core but to give it a quantum-safe way to establish and update the keys it depends on. Recent work does exactly this: a KEM-based key-update mechanism for SDLS, built on a post-quantum variant of the Noise framework, that adds post-compromise security while leaving the SDLS data path untouched and starting from shared keys.

Minimise in-flight asymmetric operations. Because handshakes are expensive over delayed links, pre-provision key material before launch where possible, and prefer schemes that ratchet forward from established state rather than renegotiating from scratch. The asymmetric heavy lifting can often sit in the ground segment and at provisioning time.

Design for agility. The single most important property is the ability to change algorithms without changing the vehicle. Cryptographic agility, negotiable algorithm identifiers and modular key management let a mission adopt a new primitive when it is standardised, or retire one when a weakness appears, rather than being frozen to the choice made at design freeze. For hardware that cannot be recalled, agility is the whole game.

The migration is already scheduled

This is not a suggestion with an open end date. It has milestones.

The United States has been most explicit. The NSA's Commercial National Security Algorithm Suite 2.0 mandates ML-KEM-1024 for key establishment and ML-DSA-87 for signatures on national security systems. Its timeline is staggered by category, running from immediate adoption for new systems, through a preference deadline in 2025 and exclusive-use deadlines from 2030, to a full transition of national security systems by 2035. Software and firmware signing, the root of trust, carries the earliest pressure because it is the hardest thing to change after deployment.

NIST reinforced the endpoint. Its transition guidance deprecates RSA, ECDSA, ECDH and DSA for new use from 2030 and disallows them after 2035.

The United Kingdom is aligned. NCSC guidance supports ML-KEM-768 or higher as a baseline and sets a phased path: define the migration and complete discovery by 2028, migrate the highest-priority systems by 2031, and complete migration by 2035.

Set those dates against how spacecraft are built. Design, qualification and integration take years. Service life runs a decade or more beyond that. A vehicle entering design now is being specified for an operating life that runs well past every one of these deadlines. For space programmes, 2035 is not a distant horizon. It sits inside the current design window.

Build it in before launch

The uncomfortable summary is simple. The threat does not wait for the quantum computer to exist, because the harvesting is happening now. The standards exist. The mandates have dates. And the one system that cannot be patched after the fact is the one flying overhead.

For uncrewed spacecraft, the command link is not a feature of the mission. It is the mission. Protecting it against a quantum-capable adversary is not a late-stage security review. It is an architecture decision that has to be made before the vehicle is built, with enough agility left in the design to change the answer when the answer needs to change.