Post-Quantum Migration Is a Key Management Problem
The post-quantum algorithms are ready for Q-Day, when a quantum computer becomes powerful enough to break standard public-key cryptography. NIST published its first three standards in August 2024 (ML-KEM for key encapsulation, ML-DSA and SLH-DSA for signatures) and selected HQC as a backup in March 2025. The next step is operational in nature: finding, replacing, rotating, and retiring every cryptographic key in your stack. This is referred to as post-quantum key management, and it's why a key management service (KMS) sits at the center of every credible quantum migration plan.
Key management fails long before the cryptography does
Modern encryption algorithms are almost never broken in practice. Breaches happen because a key was hardcoded in a repository, stored in plaintext on a server, shared with more services than anyone tracked, or never rotated after an employee left. Attackers steal keys because stealing keys is easier than breaking through the incredibly complex mathematics behind encryption.
A KMS addresses this directly by centralizing key generation, storage, access control, rotation, and audit. Keys live in one hardened place instead of scattered across configs and environment variables, ideally anchored in hardware such as a trusted execution environment (TEE), where even a compromised host can't access them. That protection layer is already critical today, against attackers who already exist.
Post-quantum cryptography defends against attacks that haven't happened yet
A sufficiently large quantum computer running Shor's algorithm will break RSA and elliptic curve cryptography (ECC), the public-key systems behind key exchange, digital signatures, and certificates that keep our day to day applications secure. Symmetric encryption such as AES survives the transition with larger key sizes, which narrows the problem usefully: the vulnerable layer is the one that protects and exchanges keys. Post-quantum migration is a migration of keys.
Nobody can name the year that quantum capability arrives, but the planning dates are converging. IBM's roadmap targets a fault-tolerant machine in 2029, NIST's draft transition guidance proposes deprecating RSA and elliptic curve algorithms after 2030 and disallowing them after 2035, and a June 2026 executive order made the migration mandatory for US federal systems. This is the distinction in the NIST guidance: deprecated means you can keep using an algorithm if you document and accept the risk, while disallowed removes that option entirely.
The effective deadline to upgrading your security for long-lived data is earlier than any of the dates shared above because of harvest now, decrypt later attacks: adversaries record encrypted traffic today and store it until quantum computers can break it. Data that must stay confidential into the 2030s is already exposed to that collection, and no future upgrade can take back the ciphertext that's already been collected.
PQC migration runs through the KMS
Three operational realities put the KMS at the center of the transition.
1. Inventory comes first.
You can't replace keys you can't find, and organizations without centralized key management genuinely don't know where all of their keys live. Cryptographic discovery is consistently the longest phase of a migration, and a KMS makes it as simple as a lookup.
2. Crypto-agility needs a control plane.
If every application implements its own cryptography, migration means changing thousands of codebases. If applications call a KMS for cryptographic operations instead, you swap algorithms once and everything downstream inherits the upgrade. The same property enables hybrid schemes, which run a classical and a post-quantum algorithm together so a flaw discovered in either one doesn't strip your protection. Hybrid deployment is how most real-world applications of transitions that are being used, because the new algorithms are limited to years of scrutiny rather than decades of proven capability.
3. Migration is lifecycle mechanics.
Migrating means generating new post-quantum keys, re-encrypting data protected under old ones, rotating on schedule, and eventually revoking classical keys, which are the operations a KMS automates. PQC also brings practical friction, including larger keys and signatures than their classical equivalents. A KMS absorbs that complexity centrally so end users of those applications don't experience the friction.
The KMS itself must become quantum-safe first
Most migration plans treat the KMS as the tool and forget it's also a target. A KMS protects keys in a hierarchy: data keys are wrapped by key-encryption keys, chained up to a root of trust. If any link in that chain relies on RSA or elliptic curves, the entire vault becomes a single point of quantum failure, because a wrapped key blob harvested today can be unwrapped by a future quantum computer, and every key inside it falls at once.
So the migration starts inside the KMS. Root keys, wrapping algorithms, and the attestation signatures that prove hardware is genuine all need post-quantum protection before the rest of the system's guarantees mean anything. PQC keeps the math secure, the KMS keeps the keys secure, and neither holds without the other.
In orbit, quantum readiness is a launch requirement
Cryptographers use Mosca's inequality to time the transition: if the years your data must stay confidential plus the years your migration takes exceed the years until a cryptographically relevant quantum computer exists, you've already run out of time. Every variable in that inequality gets worse in space.
A satellite launched today operates for the next 5-10 years, its data often carries confidentiality requirements that outlast the mission, and security hardware can't be added after launch (for obvious reasons). There's no retrofit path in orbit, so crypto-agility is a pre-launch integration decision: the spacecraft either flies with an adaptable security architecture, or flies without one for its entire operational lifetime.
We build our Key Management Service around this constraint. Keys are anchored in attested TEEs (e.g., Intel TDX) and are non-exportable by design, so they can be used but never extracted. In the future our trust ramp will extend our architecture from hardened infrastructure on Earth toward keys born in orbit inside a satellite-based TEE, where physical access is impossible by default. Post-quantum readiness is in development on our roadmap so the platform stays cryptographically agile across the full lifespan of the spacecraft it flies on. Quantum readiness is a compliance timeline for most organizations, and a launch requirement for orbital infrastructure. For why shared, interoperable spacecraft need this level of security, see our recent blog breaking down single-service siloes.
Frequently asked questions
Do I need a KMS to migrate to post-quantum cryptography?
Nothing stops you from migrating without one, but you'd be locating, replacing, and rotating keys across every application by hand, and incomplete inventory is where PQC migrations stall. A KMS turns the migration into a control-plane change instead of a thousand code changes.
When will quantum computers break current encryption?
Estimates vary. IBM's roadmap targets fault-tolerant quantum computing in 2029, and US federal guidance phases out quantum-vulnerable algorithms between 2030 and 2035. For data with long confidentiality requirements, the practical deadline is now, because harvest now, decrypt later collection is already underway.
What is harvest now, decrypt later?
An attack strategy where adversaries record encrypted data today and store it until quantum computers can decrypt it. It makes post-quantum migration urgent for any data that must stay confidential beyond the next several years, even though large-scale quantum computers don't exist yet.
Does post-quantum cryptography replace the need for a KMS?
No, because they solve different problems. PQC replaces vulnerable algorithms, while a KMS governs how keys are generated, stored, accessed, and rotated. Strong algorithms with sloppy key management fail against today's attackers, and strong key management with quantum-vulnerable algorithms fails against tomorrow's.
Our Key Management Service anchors keys in attested TEEs, non-exportable by design, with post-quantum readiness in development on our roadmap. Create an account at accounts.spacecomputer.io to get started.
SpaceComputer is building a satellite-native security architecture that combines verifiable execution, on-orbit key management, cryptographic proof of orbital deployment, and post-quantum readiness into a comprehensive security layer for the space internet and orbital compute. The full paper, "Space Fabric: A Satellite-Enhanced Trusted Execution Architecture" is available here.
Visit our website.
Follow us on LinkedIn and Twitter (X).
