AWS KMS Post-Quantum Cryptography: ML-KEM Hybrid TLS and ML-DSA Signatures in Production

NIST published FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA) in August 2024. As of July 2026, AWS documents ML-KEM hybrid TLS for KMS, ACM, and Secrets Manager API connections and ML-DSA key specs in KMS for quantum-resistant signatures — the right response to harvest now, decrypt later on long-lived data.

First-party benchmark (AWS-published order of magnitude): hybrid ML-KEM handshakes add roughly ~1.6 KB (ML-KEM-768 class) and on the order of tens to ~150 µs of crypto CPU vs classical — often ~2% TPS impact when every request forces a new handshake; amortized near zero with connection reuse. Re-benchmark your path.

Reproduce this: PQC migration checklist

Counter-case: ACM public certificates remain classical until PQ issuance is broadly supported — do not assume browser-facing PQ certs today.

Need a PQC inventory → hybrid rollout? Compliance services · Contact

Why post-quantum, why now

The threat is not “quantum computers exist today.” The threat is harvest now, decrypt later (HNDL). A sophisticated adversary — nation-state, organised crime, well-resourced industrial competitor — copies your encrypted traffic today and stores it. Five to fifteen years from now, when a Cryptographically Relevant Quantum Computer (CRQC) capable of running Shor’s algorithm at RSA-2048 scale exists, they decrypt the stored traffic.

Industry estimates from NIST, NSA, the UK NCSC, and the Quantum Resilience Federation put the CRQC arrival window between 2030 and 2040 — uncertain, but tight enough that data with multi-decade sensitivity (intellectual property, regulated health records, financial records, intelligence, infrastructure designs, legal archives) is at risk if encrypted today only with classical algorithms.

The regulatory response is moving:

• NIST: FIPS 203/204/205 published August 2024. NIST recommends transition for critical workloads by 2030 and full deprecation of RSA-2048 / ECDSA-P256 by 2035.
• NSA Commercial National Security Algorithm Suite (CNSA 2.0) mandates ML-KEM and ML-DSA for National Security Systems by 2030-2033 depending on use case.
• CNIL, BSI, ANSSI in the EU have published PQC migration guidance with similar 2030+ horizons.
• PCI DSS and similar standards have not yet specified PQC requirements but have flagged it as an emerging concern.

For most organisations the migration window is now-to-2030 — start with hybrid TLS for transport, add ML-DSA for long-lived signatures, and inventory ciphertexts with multi-year sensitivity for re-encryption.

What AWS supports today

As of July 2026 (verify current Region/SDK matrix):

The TLS support is consistent across the AWS SDK ecosystem — the SDK negotiates ML-KEM hybrid where both client and server support it, falling back to classical ECDHE if not. ACM-issued certificates remain classical (RSA-2048 or ECDSA-P256) — the PQC certificate issuance pathway depends on browser ecosystem support which is not yet GA.

How hybrid TLS works

The IETF hybrid construction (draft-ietf-tls-hybrid-design) wraps two key-exchange operations into a single TLS handshake. The shared secret is derived from both:

session_key = HKDF(classical_secret || pq_secret, ...)

If the classical algorithm (ECDHE-P256, ECDHE-X25519) is broken — for example, by a future quantum computer running Shor’s algorithm — the post-quantum component (ML-KEM-768 or ML-KEM-1024) still protects the session.

If the post-quantum algorithm is broken — for example, by an undiscovered classical attack on the Module-LWE lattice problem — the well-studied classical component still protects the session.

This is why “hybrid” is the migration step rather than “pure PQ.” Hybrid hedges against catastrophic discoveries on either side until ML-KEM has another 5-10 years of public scrutiny.

Enabling ML-KEM hybrid TLS in your applications

For AWS SDK v3 (Node.js, Python boto3, Java v2, Go v2), the SDK uses the s2n-tls library which negotiates ML-KEM hybrid by default when the AWS service endpoint supports it. To explicitly require ML-KEM, set the security policy:

Python (boto3):

import boto3
from botocore.config import Config

config = Config(
    tls_context={'security_policy': 'PQ-TLSv1-2-2023-12'}
)
kms = boto3.client('kms', config=config)

Node.js (AWS SDK v3):

import { KMSClient } from '@aws-sdk/client-kms';
import { NodeHttpHandler } from '@smithy/node-http-handler';
import https from 'https';

const kms = new KMSClient({
  requestHandler: new NodeHttpHandler({
    httpsAgent: new https.Agent({
      secureOptions: 'PQ-TLSv1-2-2023-12',
    }),
  }),
});

For non-AWS clients (your application connecting to AWS endpoints), use s2n-tls or a TLS library that supports the IETF hybrid construct (OpenSSL 3.5+, BoringSSL with the appropriate flags, Go’s crypto/tls in Go 1.24+). Browser support for ML-KEM hybrid TLS shipped in Chrome 124, Firefox 132, and Safari 17.7 — most modern browsers negotiate it automatically against PQ-enabled servers.

ML-DSA signing in KMS

ML-DSA in KMS is exposed through the standard KMS Sign / Verify API. Create a key with the post-quantum signing key spec:

aws kms create-key \
    --key-spec ML_DSA_65 \
    --key-usage SIGN_VERIFY \
    --description "Code signing - PQ"

Then sign as you would with RSA or ECDSA:

aws kms sign \
    --key-id alias/code-signing-pq \
    --message fileb://artifact.tar.gz \
    --message-type DIGEST \
    --signing-algorithm ML_DSA_65

The signature is larger than ECDSA — 3.3 KB for ML-DSA-65 vs 64 bytes for ECDSA-P256 — which matters for storage-constrained workflows (TPM-bound signing, embedded device firmware) but is negligible for code signing, document signing, container image signing (cosign supports ML-DSA in 2.5+), and supply-chain attestations.

Performance benchmarks

In synthetic benchmarks against AWS KMS endpoints in us-east-1 from an EC2 c7i.2xlarge in the same region:

The handshake overhead is the only meaningful difference. For a service that opens one connection per process and runs for hours, the cost amortizes to zero. For a high-frequency short-lived-connection workload (DNS-over-TLS, IoT telemetry on cellular, real-time control), benchmark before enabling.

Migration playbook for existing deployments

1. Inventory. List every KMS key (CMK and AWS-managed), every ACM certificate, every IAM signing certificate, every customer-managed long-lived key in Secrets Manager. Tag with data_sensitivity_horizon (immediate / 1-5y / 5-15y / 15y+).
2. New defaults. Default new long-lived workloads (>5y horizon) to ML-KEM hybrid TLS in transport and ML-DSA signing for signed artefacts.
3. Re-encrypt long-lived ciphertexts. Use KMS aliases to swap underlying key material — applications keep using alias/data-vault, KMS rotates the underlying material from classical to PQ-protected. For server-side encryption at rest (S3-SSE-KMS, EBS, RDS), the data is re-encrypted on next write under the new key version; for ciphertexts at rest that no longer get rewritten, run a one-time re-encryption job using kms:ReEncrypt.
4. Plan ACM certificate renewals. ACM-issued public certificates remain classical until PQ issuance is GA. For private CAs (AWS Private CA), check the post-quantum roadmap; for now, plan the certificate inventory to be reissuable with minimal downtime when PQ public certificates ship.
5. Update code-signing. Container signing (cosign), Lambda signing (AWS Signer), and supply-chain attestations (in-toto, SLSA) — migrate to ML-DSA on next CI/CD update. Most major signing tools added ML-DSA support in 2025.
6. Document. Add a post-quantum readiness statement to your security architecture document. Auditors will start asking about it under ISO 27001:2022 / NIST CSF 2.0 cryptographic-asset-management controls within the next 12-24 months.

Common pitfalls

1. Treating hybrid TLS as the same as pure-PQ. Hybrid is the safe migration step. Pure ML-KEM TLS will become available, but hybrid is what AWS supports today and what NIST recommends until 2030+.
2. Forgetting browser support. A server that requires ML-KEM hybrid will fail handshakes from older browsers. Configure the TLS security policy to support the hybrid construct alongside classical fallback for public-facing endpoints.
3. Ignoring signed-artefact lifetime. A code-signing certificate issued today will validate signatures created today for the certificate’s full lifetime — usually 1-3 years. If the underlying signature is RSA-2048 and a CRQC arrives in 2032, signatures created in 2026 are at risk. Move code-signing to ML-DSA on the next certificate cycle.
4. Overestimating the latency penalty. Most teams find the handshake overhead invisible. Run benchmarks before assuming impact.
5. Skipping the inventory. The migration is cheap when you know what you have. The inventory is the expensive step — start it now even if you defer the actual algorithm change.

What to Do This Week

1. Inventory CMKs/certs; tag sensitivity horizon (>5y → hybrid TLS / ML-DSA candidates).
2. Enable ML-KEM hybrid on SDK clients talking to KMS/Secrets Manager in a non-prod account; measure handshake TPS.
3. Complete the PQC checklist.

What This Post Doesn’t Cover

Browser PQ certificate issuance timelines, Transfer Family SSH PQ policies in depth, and pure-PQ (non-hybrid) TLS defaults.

Where to go next

• NIST PQC · AWS KMS security blog category
• Security & Compliance hub · Data Security

Start the inventory now; migrate on natural key/cert rotation cadence.