Post-Quantum Cryptography

Store it now, decrypt it later

Security teams keep asking when a cryptographically relevant quantum computer arrives. The useful question is which ciphertext already has to stay secret until that day. Harvest-now, decrypt-later (store it now, decrypt it later) is a recording attack. An adversary copies traffic today, waits, and decrypts it after Shor's algorithm can recover the private key that established the session. They do not need to break the symmetric cipher. They need the key-establishment transcript.

What a future quantum computer actually breaks

RSA, finite-field Diffie-Hellman, and elliptic-curve Diffie-Hellman fall to Shor's algorithm once a large, fault-tolerant quantum computer exists. Those algorithms establish session keys and they sign certificates, code, and documents. AES-256 and SHA-256 sit in a different category. Grover's algorithm is a quadratic speedup against symmetric keys and hashes. A 256-bit AES key still has a 128-bit quantum work factor, which is why NIST and the cloud KMS guides keep AES-256 for data at rest. AWS KMS documents that data encrypted under KMS keys uses AES-256-GCM, and calls that symmetric construction quantum-resistant. The exposure is the path that delivered the key.

Confidentiality fails backwards in time. A TLS session recorded in 2026 can be opened later if its handshake used classical key establishment and the plaintext still matters. Authentication of that same finished session does not fail backwards. A forged signature has to be accepted when a verifier checks it. That is why hybrid key establishment comes before a wholesale replacement of signature algorithms.

Traffic and archives already in scope

Treat any of the following as exposed if the confidentiality lifetime crosses your quantum planning horizon and the key was established with RSA or elliptic-curve public-key cryptography:

• TLS across a network you do not control: public APIs, SaaS callbacks, mobile clients, and partner interconnects.
• Cloud control-plane calls that return secrets. GenerateDataKey and Secrets Manager return plaintext over TLS. A recorded handshake plus the response is the secret.
• VPN and private-circuit handshakes that still use classical Diffie-Hellman, wherever the path can be recorded.
• Long-retention backups, medical records, financial history, and intellectual property whose wrapping key was transported with classical public-key encryption. Re-encrypting the bulk object under a fresh AES-256 key does nothing if the old wrap was recorded.

Data whose AES-256 key was born inside an HSM and never crossed a classical public-key exchange is a smaller problem. Most cloud applications are not in that shape. The data key leaves KMS over TLS, or the archive was wrapped with RSA-OAEP years ago.

NIST primitives, and why hybrids come first

On 13 August 2024 NIST approved the first three post-quantum standards. FIPS 203 is ML-KEM (from CRYSTALS-Kyber), a key-encapsulation mechanism with parameter sets ML-KEM-512, ML-KEM-768, and ML-KEM-1024. FIPS 204 is ML-DSA (from CRYSTALS-Dilithium), with ML-DSA-44, ML-DSA-65, and ML-DSA-87. FIPS 205 is SLH-DSA (from SPHINCS+), a stateless hash-based signature. SLH-DSA signatures are large. Cloud KMS documents an SLH-DSA-SHA2-128s signature of 7856 bytes. Use it where you want the security assumption to rest on the hash function, typically a long-lived root, and keep ML-DSA for high-volume signing.

RFC 10024 defines three TLS 1.3 hybrid groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. Each group runs a classical ECDH exchange and an ML-KEM encapsulation, then combines the secrets. The session holds if either algorithm holds. That property matters while ML-KEM is younger than X25519 and P-256. Hybrid groups are TLS 1.3 only. A policy that still accepts TLS 1.2 has to keep a classical group, or TLS 1.2 clients cannot connect. Azure Front Door states that constraint directly. AWS Application Load Balancer PQ policies are built the same way: they offer the hybrid groups and they keep TLS 1.3 and TLS 1.2 suites.

AWS publishes the same priority order on its post-quantum cryptography page. Inventory first. Then ML-KEM on public endpoints and on customer TLS terminators, which is the harvest-now control. Then ML-DSA for roots of trust and code signing, because those signatures must still verify years from now. Session authentication moves last. A future quantum computer cannot impersonate a handshake that already finished.

Two signature cases move earlier than leaf WebPKI certificates. Code-signing and document-signing keys protect artifacts that verifiers will check after a cryptographically relevant quantum computer exists. Build those trust anchors in parallel. AWS Private CA and Windows Server AD CS both require a new CA hierarchy for ML-DSA. An existing RSA or ECDSA CA does not change algorithm in place. AD CS ML-DSA is a Windows Server capability, documented for Windows Server 2025 with a specific servicing update. It is the PKI you might run on an Azure VM. It is not an Azure Key Vault key type.

A migration sequence that matches the threat

1. Inventory the key-establishment paths, not just the certificates. List TLS terminators, VPN and interconnect gateways, KMS keys, private CAs, database TLS settings, and every data class whose confidentiality lifetime crosses the planning horizon. Record where a data key or a secret crosses TLS.
2. Make the algorithm configuration. A TLS security policy, an ssl_groups parameter, or a KMS key spec can change without a rewrite. A curve hard-coded in an SDK cannot. Keep the inventory queryable so a provider default change shows up as a diff.
3. Turn on hybrid TLS where the client population can negotiate it. Start at the edge: CloudFront already enables hybrid key establishment for viewer connections, Azure Front Door's default key-exchange policy includes hybrid groups, and Google Cloud load balancers expose X25519MLKEM768 on the SSL policy. Then update the HTTP stacks that call cloud APIs, because KMS, S3, IAM, ACM, Secrets Manager, and *.googleapis.com can only protect a caller that offers the hybrid group. Then enable database PQ-TLS on engines that document it, and measure before you remove classical groups.
4. Measure the negotiation. CloudFront's CloudFront-Viewer-TLS-Details header reports the key exchange. Application Load Balancer connection logs include the key exchange. Aurora MySQL exposes Aurora_ssl_named_group. A policy that offers a hybrid group still completes classically when the client does not advertise one.
5. Plan KMS and PKI on two tracks. Use ML-KEM when a new shared secret will protect long-lived data. AWS KMS holds ML-KEM-512, ML-KEM-768, and ML-KEM-1024. Cloud KMS holds ML-KEM-768, ML-KEM-1024, and the X-Wing hybrid, and it decapsulates only: encapsulation runs with the public key outside the service. Use ML-DSA for new code-signing keys and private roots. AWS KMS and Private CA document ML-DSA-44, ML-DSA-65, and ML-DSA-87. Cloud KMS adds SLH-DSA-SHA2-128s. Azure Key Vault's stable key-type article still lists EC, RSA, and preview 256-bit AES. An ML-DSA signing preview exists on the 2026-05-01-preview data-plane API and in the .NET SDK's MLDsaSignOptions path. Keep that in a lab until the stable article lists the key type.
6. Re-wrap keys that traveled under classical public-key encryption. Leave bulk AES-256 objects in place when the key itself was never exposed. Rotate the wraps, the exported data keys, and the TLS policies that carried them.

The cards below are limited to behavior described in the linked provider documents. Where a document describes a product's cryptography and does not mention a post-quantum control, the card says so. That gap is a finding from the document, and it will change when the document changes.