The standards are finalized. The clock is running. Here's what you actually need to do — before "harvest now, decrypt later" makes your data retroactively insecure.

Your data is probably already harvested. The question isn't whether you'll be attacked — it's whether the attacker will be able to read it when quantum compute arrives.

This sounds alarmist. It isn't. It's the logical consequence of how nation-state adversaries operate in 2026, and it has a name: harvest now, decrypt later (HNDL). The attack works like this: intercept and archive encrypted traffic today — TLS handshakes, API calls to secrets management services, key exchange protocols — and store it. When a Cryptographically Relevant Quantum Computer (CRQC) becomes practical, decrypt everything retroactively. The interception happens years before the decryption capability exists. The attack is already underway.

Most developers hear "quantum computers" and think: that's decades away, not my problem today. That reasoning is wrong for one specific reason: the data you're protecting today may need to remain confidential well into the 2030s. If you're generating RSA-2048 certificates with 10-year validity in 2026, those certificates will be in use when the first CRQCs appear. If your application stores long-lived API credentials, health records, financial instruments, or private keys encrypted with classical public-key algorithms, those assets are already exposed to HNDL attacks.

The good news: NIST finalised the post-quantum cryptography (PQC) standards in August 2024. AWS has been implementing them aggressively. The tools to protect your systems exist right now. The migration window between "standards exist" and "quantum threat is real" is exactly the window you should be migrating in — at your own pace, not in crisis mode after the fact.

This post is written specifically for developers building on AWS. Not for CISOs writing strategy documents. Not for cryptographers studying lattice math. For the engineer who owns SDK configuration, TLS policies, code signing pipelines, and certificate management. Most of the PQC migration surface area lands directly on your desk, and most guidance written so far skips past you entirely.

The migration timeline you need to know

Before anything else, orient yourself on the actual dates:

None
PQC Timeline

The 2026 date is the one most relevant to developers building on AWS today. It's already here.

What NIST finalised — in plain English

You don't need to understand lattice mathematics to migrate your systems. You need to understand what each standard replaces and when to use it.

ML-KEM (FIPS 203 — replaces ECDH)

ML-KEM is a key-encapsulation mechanism — the algorithm that establishes a shared secret during a TLS handshake or key exchange protocol. This is what protects data in transit: your API calls, your HTTPS connections, your SDK calls to AWS KMS. Classical key exchange (ECDH) is vulnerable to Shor's algorithm on a quantum computer. ML-KEM is not — it's based on the hardness of module lattice problems, which quantum computers cannot efficiently solve with known methods.

ML-KEM comes in three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. These represent increasing security levels at the cost of larger key sizes. ML-KEM-768 is the most widely deployed and is what AWS uses in its hybrid TLS implementations. Use ML-KEM for: TLS connections, VPNs, any protocol that uses key agreement.

ML-DSA (FIPS 204 — replaces RSA/ECDSA for most signatures)

ML-DSA is a digital signature algorithm — the algorithm that proves authenticity and integrity. This is what protects code signing, certificate chains, JWT verification, and mTLS. Classical signature schemes (RSA, ECDSA) are also broken by Shor's algorithm. ML-DSA is not.

Three parameter sets: ML-DSA-44, ML-DSA-65, ML-DSA-87. ML-DSA is fast, efficient, and suitable for general-purpose use. Signature sizes range from approximately 2.4KB (ML-DSA-44) to 4.6KB (ML-DSA-87). Use ML-DSA for: code signing, certificate generation, JWT signing where token lifetime matters, mTLS certificate hierarchies.

SLH-DSA (FIPS 205 — the conservative long-term choice)

SLH-DSA is also a digital signature algorithm, but based purely on hash functions rather than lattices. Its security rests on the most mathematically conservative assumptions available — essentially, if SHA-256 isn't broken, SLH-DSA isn't broken. The trade-off: significantly larger signatures (~8–50KB versus ML-DSA's ~2.4–4.6KB) and slower performance.

Use SLH-DSA specifically for data that must remain verifiably authentic for decades: government archives, legal documents, critical infrastructure firmware. For most application developers, ML-DSA is the right choice. Don't default to SLH-DSA unless the long-term signature overhead is justified.

What you do NOT need to change

This is important enough to state clearly: symmetric encryption (AES-256) and hash functions (SHA-256, SHA-3, HMAC) are already quantum-resistant. Grover's algorithm provides a modest quadratic speedup against symmetric ciphers, but AES-256 with its 256-bit key space remains secure against quantum attack. Your data at rest encrypted with AES-256 does not need to change. Your HMAC-based API authentication does not need to change. The rule of thumb: anything involving public-key cryptography (RSA, ECDH, ECDSA) needs migration. Anything using symmetric keys (AES, HMAC, SHA) does not.

Why you don't flip a switch: the hybrid approach

You cannot instantly replace ECDH with ML-KEM across your entire stack. Your clients, your servers, and your third-party integrations need to negotiate the same algorithm. If you force ML-KEM on your server before your clients support it, handshakes fail.

The solution is hybrid key exchange: run both the classical algorithm and the post-quantum algorithm in parallel during the same handshake, then combine both outputs cryptographically to derive the session key. The session is then protected by both. If ML-KEM is somehow broken in the future, you haven't lost classical ECDH security. If ECDH is broken by quantum, you're protected by ML-KEM. You lose nothing and gain protection.

The industry-standard hybrid for TLS is X25519MLKEM768: ECDH with the X25519 curve combined with ML-KEM-768. This is the combination AWS uses in s2n-tls, its open-source TLS implementation. Cloudflare uses it. Chrome shipped support for it. It's the de facto standard for production hybrid TLS today.

The performance cost of the hybrid is real but small: approximately 1,600 additional bytes in the TLS handshake, and 80–150 microseconds of additional compute time for ML-KEM operations. For most production workloads, this is below noise. For extremely high-throughput systems (hundreds of thousands of TLS handshakes per second), benchmark before rolling out — but this is rarely a blocking concern.

Crypto-agility is the architectural principle to apply here: design systems so cryptographic algorithms can be swapped without rewriting application logic. Hardcoded algorithm names in your TLS configuration or your certificate generation code create migration debt every time NIST updates a standard. Parameterise the algorithm choice.

AWS's PQC migration — what's live and what you need to do

AWS has been the most aggressive major cloud provider in deploying PQC support. Here's the current state of each relevant service, and what action lands on your side of the shared responsibility model.

AWS KMS, ACM, and Secrets Manager

ML-KEM hybrid PQ-TLS is live on all non-FIPS endpoints in all AWS regions. These three services were chosen first because they are the most security-critical AWS services — they handle the keys and secrets that protect everything else.

Critical date: CRYSTALS-Kyber, the predecessor to ML-KEM, is being removed from all AWS endpoints in 2026. If your SDK clients are negotiating Kyber today and you don't upgrade, they will silently fall back to classical ECDH when Kyber is removed. No error. No warning. No protection. You will not know unless you are monitoring which cipher suite is being negotiated.

Developer action:

  • AWS SDK for Java v2: upgrade to the latest generally available release. ML-KEM is negotiated automatically — no code changes required. Customers still using older SDK versions with Kyber support must upgrade before 2026.
  • AWS SDK for Rust: add the rustls crate to your dependencies and enable the prefer-post-quantum feature flag.
  • AWS SDK for Python (boto3): the AWS CRT-based HTTP client (awscrt) underpins boto3's HTTP layer and is the likely path for ML-KEM support, but AWS's ML-KEM announcement specifically called out Java v2 and Rust. Before relying on this for a production migration, verify ML-KEM negotiation against the current boto3 and awscrt changelogs, or test explicitly with cipher suite logging enabled.
  • All other SDKs: check the AWS SDK release notes for your language. Look specifically for ML-KEM or prefer-post-quantum mentions.

Amazon S3

Since November 2025, all regional S3, S3 Tables, and S3 Express One Zone endpoints support ML-KEM post-quantum TLS key exchange. Combined with S3's default AES-256 server-side encryption, this now provides quantum-resistant protection for data both in transit and at rest.

Developer action: Ensure your S3 client SDK version supports ML-KEM negotiation. If you're using a recent version of any AWS SDK, this should be automatic — but verify by checking which cipher suite is being negotiated in your monitoring.

AWS Private CA and KMS (ML-DSA)

AWS has added ML-DSA key support to KMS and ML-DSA certificate support to AWS Private CA. You can now create quantum-resistant PKI hierarchies for code signing, device authentication, mTLS, and IAM Roles Anywhere.

Developer action: This is not yet a hard deadline, but consider it for new PKI hierarchies you're creating in 2026 and beyond. If you manage certificates with long lifetimes (3–5+ years), the next rotation cycle is a natural migration point. Don't wait until your current classical certificates expire in 2029 and then try to migrate under time pressure.

If you're using AWS Private CA for mTLS or code signing today, evaluate whether your current certificate validity windows align with the 2030–2035 deprecation timeline. A certificate issued with a 5-year validity in 2027 will still be in use when NIST's deprecation begins.

Customer-managed load balancers (ALB / NLB)

This is the most commonly missed item. AWS has published updated TLS negotiation policies that include ML-KEM support for Application Load Balancers and Network Load Balancers. But applying these policies is on the customer's side of the shared responsibility model — AWS does not automatically update your load balancer's TLS configuration.

Developer action: Update your ALB/NLB TLS policy to a version that includes ML-KEM cipher suites. This is an infrastructure change (a few lines of CloudFormation or Terraform, or a console change) — not an application code change. You can also use IAM resource control policies to enforce PQ-enabled TLS policies on future resource creation.

Services not yet covered

AWS has committed to rolling out ML-KEM support to all HTTPS endpoints "over the coming years." As of March 2026, this rollout is ongoing. Do not assume that a service not explicitly mentioned here has PQ-TLS enabled. Check the AWS Post-Quantum Cryptography page for the current list of supported services, and monitor new announcements.

Auditing your own codebase

The AWS-managed services are only half the picture. Your application code, your TLS configuration, and your dependencies are the other half. Here is a concrete process for assessing your own exposure.

Step 1: Identify where you use public-key cryptography

Search your codebase for:

  • TLS connection setup — both outbound (SDK calls, HTTP clients, database connections) and inbound (your servers, your load balancers)
  • JWT signing algorithms — RS256, ES256, PS256 are public-key-based and vulnerable; HS256 (HMAC-based) is symmetric and safe
  • Certificate generation or validation — anything using openssl, cryptography (Python), java.security, crypto (Node.js), or similar
  • Code signing — any pipeline step that signs artifacts or verifies signatures
  • SSH key types — RSA, ECDSA, and Ed25519 keys are all quantum-vulnerable. Ed25519 uses elliptic curve discrete logarithm on Curve25519, which Shor's algorithm breaks for the same reason it breaks ECDSA. Ed25519 is preferred over RSA for classical security reasons (smaller keys, faster operations), but it is not quantum-resistant and belongs on the same migration list. Post-quantum SSH key types are being standardised by NIST and IETF but no finalised standard exists yet — monitor IETF's PQUIP working group for updates.
  • Explicit use of RSA or ECDSA keys in application code

Step 2: Check your TLS configuration

What cipher suites are your servers advertising? What are your clients accepting? Several tools help:

# Check what cipher suites your server offers and which is negotiated
openssl s_client -connect your-api.example.com:443 -tls1_3

# More detailed TLS analysis
testssl.sh --cipher-per-proto your-api.example.com

# Check if ML-KEM is being negotiated (look for "TLS_AES_256_GCM_SHA384 + X25519MLKEM768")

In AWS Security Hub, TLS findings surface misconfigurations across your load balancers and managed services. This is worth running if you haven't recently.

Step 3: Audit key and certificate lifetimes

Long-lived data is the highest risk. Specifically:

  • RSA or ECDSA certificates with validity periods extending past 2028
  • API keys or service account credentials that are rarely rotated
  • Encrypted backups or archives with indefinite retention
  • Any private key material that has existed since before 2022 (potential HNDL window already open)

The prioritisation rule: data that needs to remain confidential past 2030 needs post-quantum protection now. Data that is ephemeral (session tokens, short-lived Lambda invocation credentials, request-scoped HMAC signatures) is low urgency.

Step 4: Map your third-party dependencies

Which cryptographic libraries underpin your application?

  • OpenSSL 3.x: ML-KEM support is available in the oqsprovider extension
  • BoringSSL (used by Go's crypto/tls, Chrome, etc.): ML-KEM support shipping
  • AWS-LC: AWS's open-source FIPS 140–3-validated library — the first to include ML-KEM in a FIPS validation; a strong migration target if you control your crypto library
  • Java's JSSE: ML-KEM support via the BouncyCastle provider
  • Node.js crypto: depends on the linked OpenSSL version — check your Node.js build

Critically: also map your outbound connections to third-party services. You control your AWS SDK configuration, but you don't control whether your payment processor, identity provider, or external data feed supports hybrid PQ-TLS. Outbound connections to non-AWS services need separate migration timelines and conversations with those vendors.

Production gotchas

Silent fallback is not safety. The most dangerous aspect of the AWS CRYSTALS-Kyber deprecation in 2026 is that old SDK clients don't throw an error — they silently fall back to classical ECDH. You will continue to see successful API calls. The difference is invisible without cipher suite monitoring. Before the deprecation, check that your monitoring captures which key agreement algorithm is being negotiated on your high-sensitivity API paths.

Don't touch symmetric encryption. It's already safe. If someone suggests migrating your AES-256 data encryption to a post-quantum symmetric algorithm, that's unnecessary and introduces migration risk with no security benefit. Focus entirely on public-key operations.

ML-DSA certificate adoption is slower than ML-KEM. Cloudflare predicted in 2024 that the first post-quantum X.509 certificates would become available in 2026, but not enabled by default in WebPKI. PKI chain propagation takes time — root store inclusion, certificate transparency log acceptance, and client trust decisions all have multi-year latency. If your architecture requires mutual quantum-resistant authentication via mTLS, this is a multi-year project, not a configuration flag.

SLH-DSA signature sizes matter at scale. ML-DSA produces signatures between ~2.4KB and ~4.6KB depending on the parameter set. SLH-DSA produces signatures between ~8KB and ~50KB. If you're signing API responses, JWT tokens, or any high-frequency payload, that size difference has real bandwidth and latency implications. Use ML-DSA for general purpose. Reserve SLH-DSA for archival and long-term integrity use cases.

Your third-party services may not support hybrid PQ-TLS yet. You cannot force X25519MLKEM768 on an outbound connection to a server that only offers classical cipher suites. The hybrid will negotiate down to classical. Map your outbound dependencies separately from your inbound configuration — they have different migration paths and timelines you don't control.

Your migration priority order

Here's what to do and when, ordered by urgency.

Do now (2026):

  • Update all AWS SDK versions to their latest releases. ML-KEM negotiation for KMS, ACM, Secrets Manager, and S3 happens automatically in current SDK versions.
  • Update your ALB/NLB TLS negotiation policies to versions that include ML-KEM cipher suites. This is infrastructure configuration, not application code.
  • Add cipher suite negotiation to your observability. Log or monitor which key agreement algorithm is being used on high-sensitivity paths. The Kyber fallback is silent — observability is your only protection.

Do this year:

  • Run the codebase audit described above. Identify every location where you use RSA, ECDH, or ECDSA.
  • Inventory all certificates and key material by expiry date. Flag anything expiring after 2028 for migration at next rotation.
  • Brief your team. Most developers have not heard of ML-KEM. They will make different decisions about JWT algorithm selection, certificate validity periods, and TLS configuration if they understand the stakes.

Plan for 2027–2028:

  • Migrate code signing pipelines to ML-DSA. This is the highest-risk public-key use case for most development teams — the signatures on your software artifacts will be verifiable for years.
  • Evaluate post-quantum PKI hierarchies via AWS Private CA for any mTLS or device authentication architecture you're building new.
  • Begin conversations with third-party vendors whose APIs you depend on. Ask when they plan to support hybrid PQ-TLS. Build their timelines into your migration plan.

Complete before 2030:

  • Full TLS migration to hybrid ML-KEM on all customer-managed endpoints.
  • Retirement of long-lived RSA and ECDSA keys.
  • NIST begins deprecating 112-bit classical algorithms in this window. Any remaining classical public-key operations should be on an explicit retirement timeline.

What this is actually about

Cryptography migration is unglamorous work. It happens in configuration files and library versions and certificate rotation schedules, not in product features or user-visible improvements. It's the kind of work that's easy to defer precisely because the cost of deferring is invisible until it isn't.

But "harvest now, decrypt later" changes the calculus in an important way. With most security work, you can respond after an incident. With HNDL, the incident already happened — you just don't know the outcome yet. The data was recorded. The keys were archived. The window to protect against the decryption is now, while you still have time to rotate, migrate, and replace before a CRQC makes the question moot.

NIST has done its part. The standards are final, tested, and ready. AWS has done its part — PQ-TLS is live on the most critical services, and the roadmap to all HTTPS endpoints is underway. The migration that's left is on your side of the shared responsibility model.

The tools exist. The timeline is clear. The work is specific and tractable. The question is whether you do it now, at your own pace, or later, when someone else's timeline forces your hand.

References: