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

The first NIST post-quantum cryptography standards landed in August 2024 as FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). Through 2025 and into April 2026, AWS rolled out post-quantum support across AWS KMS, AWS Certificate Manager (ACM), and AWS Secrets Manager — first for transport (ML-KEM hybrid TLS) and then for signatures (ML-DSA in KMS). The migration window is now open for organisations that need to defend against “harvest now, decrypt later” attacks on long-lived data.

This guide is for security architects, platform engineers, and CISOs evaluating whether to enable post-quantum cryptography (PQC) on their AWS workloads now or later. It covers the threat model, the algorithms AWS supports, performance characteristics, configuration across SDKs and services, the migration pattern for existing key material, and the regulatory context that makes PQC a 2026 boardroom topic.

Need help mapping a PQC migration on AWS? FactualMinds runs cryptographic-modernization engagements alongside ISO 27001 and FIPS 140-3 readiness — start with an inventory of long-sensitivity data and finish with a deployed hybrid stack. See our compliance services or talk to our team.

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 April 2026:

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.

Where to go next

• Read the NIST PQC Migration Roadmap (NIST IR 8547).
• Browse the AWS KMS Post-Quantum announcements for the latest service support matrix.
• Build the inventory step using AWS Config rules + a custom Lambda that tags resources with their crypto algorithm and key spec.
• Browse the AWS Security & Compliance hub and the Data Security subtopic for related guides on KMS, S3 hardening, and Secrets Manager.

Post-quantum migration is unlike most security migrations — there is no “off” date, no breach to respond to, no auditor demanding it before the deadline. Most teams will discover the work is straightforward once the inventory is in place. Start the inventory now; let the migration follow on the natural certificate-and-key rotation cadence.