5 Steps to Plan a Post-Quantum Cryptography Migration
Post-quantum cryptography migration breaks down into three moves an engineering team can start this quarter: inventory where RSA and ECDSA protect long-lived data, move TLS connections to managed key services over hybrid key exchange, and adopt quantum-safe signing where your provider already offers it. NIST finalized its first three post-quantum standards on August 13, 2024, so the algorithms are implementable specifications with production support at AWS and Google — not draft proposals. This guide covers the threat model, what each standard does, provider capabilities, and a five-step plan you can execute without a research budget.
Why the Threat Starts Now
The migration driver is a recording attack, not a working quantum computer. An adversary can capture encrypted traffic and stored ciphertext today, hold it cheaply for years, and decrypt it once large-scale quantum hardware matures. AWS documents this scenario in its KMS guidance and names it harvest now, decrypt later. Any secret whose confidentiality must survive another decade — signed release artifacts, customer records, key material, or training datasets like those discussed in securing AI models and data in managed ML platforms — already sits inside that exposure window.
Not everything is at risk, and that shapes where you spend effort. The vulnerable primitives are public-key exchange and digital signatures; AWS states that data encrypted under KMS keys uses symmetric AES-GCM cryptography it already considers quantum resistant. Migration is therefore about replacing key agreement and signatures, not re-encrypting every database. It is also not a substitute for classical defenses: credential theft paths such as SSRF against instance metadata remain live, and controls like IMDSv2 enforcement still do daily work.
What NIST Finalized
The finalized set covers both jobs cryptography does: protecting data in transit and authenticating identity. NIST renamed the winning algorithms for their standardized versions; in this set, CRYSTALS-Kyber was renamed ML-KEM and designated the primary standard for general encryption, with NIST highlighting its comparatively small keys and fast operation. Project head Dustin Moody’s published guidance is blunt: administrators should start integrating the standards immediately because full integration will take time.
| Standard | Algorithm | Role |
|---|---|---|
| FIPS 203 | ML-KEM (from CRYSTALS-Kyber) | Key encapsulation for general encryption |
| FIPS 204 | ML-DSA (from CRYSTALS-Dilithium) | Primary digital signature standard |
| FIPS 205 | SLH-DSA (from SPHINCS+) | Backup signatures on different math |
Hybrid TLS in Practice
Hybrid mode is the deployment pattern that makes early migration safe. Instead of trusting a new algorithm alone, the client and server run a classical exchange and a post-quantum exchange together, so the connection keeps today’s security if either math problem later breaks. In AWS, AWS KMS supports a hybrid post-quantum key exchange option for TLS that combines Elliptic Curve Diffie-Hellman with ML-KEM, available in every Region where KMS runs, on all endpoints including its FIPS-validated ones.
Verification is built in, which matters for audits. After enabling a hybrid-capable SDK client, inspect the call’s CloudTrail entry: the keyExchange field shows a hybrid algorithm such as X25519MLKEM768 when the handshake used ML-KEM. Two operational cautions come straight from the AWS documentation: hybrid handshakes make some TLS messages larger, and intermediate proxies or firewalls with deep packet inspection may block the new key exchange groups, so test from each network location before rollout.
Provider Support Today
Both major providers have moved past slideware. Google operates under a published roadmap to migrate Google Cloud to post-quantum cryptography by 2029, and its Cloud KMS already offers quantum-safe digital signatures and key encapsulation mechanisms, with quantum-safe key exchange available for its load balancers. AWS ships the KMS hybrid TLS option across its SDKs and runs the server side on s2n-tls, its open-source TLS implementation. The practical comparison for buyers:
- NIST: finalized, implementable standards plus backup algorithms still in evaluation.
- AWS: hybrid post-quantum TLS to KMS, ACM and Secrets Manager endpoints, with CloudTrail verification.
- Google Cloud: quantum-safe KEMs and signatures in Cloud KMS, load-balancer key exchange, and a 2029 internal deadline.
Five-Step Migration Plan
- Build a cryptographic inventory. List every place RSA, ECDSA or Diffie-Hellman appears: certificates, mTLS meshes, KMS key policies, code-signing pipelines, VPN concentrators. Tag each entry with the confidentiality lifetime of the data it protects; anything that must stay secret for another decade is your first wave.
- Prioritize harvest-now exposure. Rank by what an attacker can record today, not by what is most used. External TLS endpoints, inter-service links over shared networks and replicated storage top the list.
- Enable hybrid TLS where it exists. Switch SDK clients calling KMS to a hybrid post-quantum-capable HTTP client, then confirm each integration through the CloudTrail keyExchange field before declaring it migrated.
- Adopt quantum-safe signing for artifacts. Use Cloud KMS quantum-safe signatures, or dual-sign with ML-DSA alongside your current scheme, so verification works in both worlds during the transition.
- Engineer cryptographic agility. Centralize algorithm choice in shared libraries and configuration instead of scattering it across services, so the next swap — including backup standards still in NIST evaluation — is a config change, not a rewrite. Track provider roadmaps quarterly; Google’s 2029 target is a useful external clock for your own.