ML-KEM on AWS: Post-Quantum Cryptography Has Left the Lab and Entered Production SDKs
In April 2026, AWS turned on ML-KEM hybrid post-quantum TLS by default across KMS, Secrets Manager, ACM, Payment Cryptography, and S3. Here is what changes at the byte level, how to validate negotiation in CloudTrail, and why legacy DPI appliances can silently break it.
Post-quantum cryptography is one of those topics that triggers two predictable reactions from security practitioners. One part of the team fully understands why it matters and wants to know how to migrate. Another part thinks it is a bit overblown, a bit of a hype cycle, and wonders why worry about something that depends on a functional quantum computer that does not yet exist. Both reactions are legitimate, and I have been on both sides at different points in my career.
What has changed in the last two years is that the conversation is no longer theoretical. In April 2026, AWS enabled ML-KEM (the algorithm standardized by NIST for quantum-resistant key exchange) automatically in Secrets Manager Agent 2.0.0+, Lambda Extension v19+, and CSI Driver 2.0.0+. That follows the earlier enablement in KMS, ACM, Payment Cryptography, and S3. And CRYSTALS-Kyber, the predecessor of ML-KEM that AWS had been supporting, will be removed from all endpoints within this year.
If you run applications that depend on these services, you are likely already negotiating hybrid post-quantum TLS without realizing it. This article walks through what that means, what can break, and why AWS is making this transition now, even with the so-called quantum apocalypse supposedly distant.
TL;DR for the impatient builderML-KEM-768 is now active by default on KMS, ACM, Secrets Manager, Payment Cryptography, and S3 public endpoints. SDKs negotiate hybrid ECDH + ML-KEM automatically (or with a single flag, depending on language). The handshake costs around 1,600 extra bytes and 80 to 150 microseconds. With TLS reuse, throughput loss is 0.05%. Watch out for legacy DPI appliances that drop oversized handshakes.
The harvest now, decrypt later rationale
The strongest argument for migrating to PQC today is not that quantum computers will break cryptography tomorrow. That horizon, as far as researchers can estimate, is at least a decade out, probably more. The real argument is what the literature calls harvest now, decrypt later, and it works like this.
Sophisticated attackers (particularly state actors) are recording encrypted traffic flowing over public networks today. They cannot decrypt it now, but they store it. In ten, fifteen, twenty years, when a cryptographically relevant quantum computer exists, they return to the archived data and break what was previously impenetrable.
This affects any data whose value persists over time: medical records, long-lived financial information, government intelligence, trade secrets, research IP. If your application exchanges that kind of data over TLS today, and if that traffic passes through any point where it can be recorded, then you have a risk window that closes only when you migrate to PQC, and not before.
That is the reason AWS, the NSA, NIST, the Canadian government (which requires federal agency migration plans by April 2026, coincidentally), the Australian ASD, and other regulatory bodies are pressing for adoption now. It is not about breaking cryptography in 2026. It is about not leaving data born in 2026 readable in 2040.
ML-KEM in practical terms
ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) is the algorithm NIST selected in August 2024 as the standard for quantum-resistant key exchange. It is based on lattice problems, a class of mathematical problems that, as far as we know, remain hard even with access to a functional quantum computer.
ML-KEM is the standardized evolution of what was previously called CRYSTALS-Kyber, which was the project name. AWS uses specifically ML-KEM-768, which indicates the targeted security level. Here is the equivalence table for reference:
Variant | Classical-equivalent strength | Use case |
|---|---|---|
ML-KEM-512 | ~AES-128 | Constrained / IoT workloads |
ML-KEM-768 | ~AES-192 | Default for AWS public endpoints |
ML-KEM-1024 | ~AES-256 | Highest assurance / long-lived data |
Here is the important detail: AWS did not replace the key exchange algorithm. It built a hybrid key agreement, meaning the TLS handshake uses classical ECDH (typically X25519) combined with ML-KEM. The final shared secret is derived from both exchanges, with SHA-256 applied on top.
Why hybrid mattersIf ML-KEM is broken one day (unlikely but possible), you still have ECDH protection. If ECDH is broken by a quantum computer (the expected path), you still have ML-KEM protection. It is defense in depth applied to cryptography.
Step-by-step handshake mechanics
For those who enjoy the technical detail, the handshake flow is approximately as follows. The client sends a
ClientHello offering both classical elliptic curves and ML-KEM as key exchange algorithms. The server selects the hybrid key agreement if compatible, and responds. Both ends perform the traditional ECDH exchange and, in parallel, execute the ML-KEM encapsulation (where the client sends a lattice public key and the server returns a ciphertext that the client decapsulates). The two shared secrets are combined via a KDF, and the TLS session is established with hybrid protection.From the perspective of a developer using the SDK, none of this is visible. You call
secretsmanager.get_secret_value() as usual. The difference lies at the byte level: the handshake now transfers approximately 1,600 additional bytes, and setup time grows by 80 to 150 microseconds on modern CPU.These numbers sounded alarming on first read, but context dilutes them. AWS measured the production impact:
- With TLS connection reuse active (the default in modern SDKs): throughput loss is 0.05%.
- Without reuse, where each request opens a new connection: it rises to about 2.3%.
For the overwhelming majority of workloads, this is invisible. For workloads with high connection-establishment frequency (webhooks that open new TLS per event, for example), it is worth measuring beforehand.
Enabling ML-KEM in your SDK
Activation depends on the language. Here is the practical matrix you need at hand:
Java v2 (AWS SDK 2.35.11+)
Requires the AWS Common Runtime HTTP client and an explicit flag:
Java
SdkAsyncHttpClient httpClient = AwsCrtAsyncHttpClient.builder().postQuantumTlsEnabled(true).build();KmsAsyncClient kms = KmsAsyncClient.builder().httpClient(httpClient).build();
Rust
Enable the feature flag in
Cargo.toml :toml
[dependencies]aws-config = { version = "1.5", features = ["prefer-post-quantum"] }aws-sdk-kms = "1.50"
Python (boto3)
No SDK flag is required, but you need OpenSSL 3.5+ linked. Validate first:
Bash
python -c "import ssl; print(ssl.OPENSSL_VERSION)"# Expected: OpenSSL 3.5.x or later
Heads-up for conservative distrosAmazon Linux 2 and older Ubuntu/Debian ship with OpenSSL 1.1 or 3.0. You either need a base image upgrade, a custom build, or to switch to a runtime image that ships OpenSSL 3.5+ (Amazon Linux 2023 with recent patches, Ubuntu 24.04+, or a slim Python 3.13 image).
Secrets Manager Agent, Lambda Extension, CSI Driver
ML-KEM is enabled by default, no flag required, on Secrets Manager Agent 2.0+, Lambda Extension v19+, and CSI Driver 2.0+. If you use these components in Kubernetes to inject secrets into pods, your connections are already running PQC and you likely have not noticed.
Validating that PQC is actually negotiated
Do not assume the upgrade landed silently. CloudTrail already surfaces the negotiated key exchange algorithm. For KMS and Payment Cryptography events, look inside
tlsDetails.keyExchange :JSON
{"eventSource": "kms.amazonaws.com","eventName": "Decrypt","tlsDetails": {"tlsVersion": "TLSv1.3","cipherSuite": "TLS_AES_256_GCM_SHA384","keyExchange": "X25519MLKEM768","clientProvidedHostHeader": "kms.us-east-1.amazonaws.com"}}
If you see
X25519MLKEM768 (or a vendor-prefixed equivalent like X25519Kyber768Draft00 on legacy clients), the handshake is hybrid post-quantum. If you see plain X25519 or ECDHE , the SDK or runtime is too old or the path is blocked.The corporate DPI gotcha
Here is a point that does not show up in most official documentation, but is real and has already caused headaches in enterprise environments. Some corporate firewalls and proxies with Deep Packet Inspection (DPI) were programmed assuming maximum TLS handshake sizes. When the ML-KEM handshake starts transferring those extra 1,600 bytes, some of these devices (especially legacy, regex-based inspection systems) drop the connection, considering the handshake malformed or potentially malicious.
If you operate in an environment with a network perimeter that includes DPI (common in financial services, public sector, some regulated industries), test beforehand. A quick triage path:
Bash
# 1. Test handshake against KMS endpoint with PQC enabledopenssl s_client -connect kms.us-east-1.amazonaws.com:443 \-groups X25519MLKEM768:X25519 -tls1_3 < /dev/null# 2. If it fails, retry classical-only to isolateopenssl s_client -connect kms.us-east-1.amazonaws.com:443 \-groups X25519 -tls1_3 < /dev/null# 3. Capture in Wireshark and look for early CLOSE on ClientHello
Operational lesson learnedIf TLS fails to handshake but works without PQC, it is almost certain DPI is blocking it. The resolution involves talking to the network team and updating rules, sometimes firmware. It is not difficult, but it takes time and coordination you do not want to discover on a Friday night during deployment.
Triaging migration urgency by workload
Not every workload needs to migrate with the same urgency. A simple triage based on data sensitivity and longevity is worthwhile:
Priority | Workload profile | Action |
|---|---|---|
High | Multi-decade persistent data: medical records, genomic data, financial PII, government secrets, research IP, long-lived signing keys | Migrate now |
Medium | Intermediate-value data: short-lived credentials, operational data that ages out, configurations | Migrate at next SDK upgrade |
Low | Internal workloads on paths where capture is implausible: intra-VPC, within trust perimeters | Eventually migrate, no urgency |
N/A | Dev, test, playground environments without sensitive data | Skip |
Implementation sequencing
If I were building a plan today, I would start with applications that most heavily call Secrets Manager and KMS in production, especially those handling production database credentials, signing keys, and access tokens.
My playbook by phase:
- Phase 1 (week 1 to 2): update SDK, validate
keyExchangein CloudTrail, run load test pre/post.
- Phase 2 (week 3 to 4): CI/CD pipelines that retrieve secrets at deploy time.
- Phase 3 (week 5+): application workloads that make recurring calls to Secrets Manager at runtime.
For each group, I would keep a two-to-four-week migration SLA. Conservative, but it leaves room to roll back if any intermediate component (a proxy, a sidecar, a custom HTTP client) does not like it.
Remaining gaps and ongoing concerns
My concern with this transition is not ML-KEM itself. The algorithm has been thoroughly analyzed, was standardized through a public NIST process, and is implemented in auditable open-source libraries (AWS-LC, s2n-tls). My concern is with what has not been migrated yet.
ML-KEM solves key exchange. Post-quantum digital signature is a separate story, being addressed in parallel with ML-DSA (also NIST-standardized). But signatures on certificate chains, on signed-code manifests, on IoT firmware signatures, on container manifests, all of that still uses ECDSA or RSA. AWS has already started working on X.509 certificates with ML-DSA (IETF draft), but it is not yet widely in production.
Be honest about partial progressUntil ML-DSA is in production for certificate chains, you have quantum-resistant key exchange running over an authentication layer that is not. That is partial progress, and we need to be clear about it. Updating the SDK is step one of many, not the finish line.
I am also concerned that many teams will update the SDK and think "done, we are migrated." We are not. If you have services that do not use the AWS SDK (direct
curl calls, integrations with custom proxies, mobile apps, embedded devices, third-party libraries that bypass the SDK), those paths need to be verified individually. Full migration is an inventory project, not a library update.Closing thoughts
Post-quantum cryptography has left the drawing board. In 2026, it is in production endpoints, in widely adopted SDKs, in formal documentation, in regulatory roadmaps. Those who have not started looking yet are still within the window, but the window is shrinking. And those who work with long-lived data should treat this topic as a priority for this semester, not 2030.
I am personally glad to see AWS leading this front. Publishing AWS-LC as a FIPS-validated library with ML-KEM support, and s2n-tls as an open-source TLS implementation supporting hybrid key agreement, is real contribution to the state of the art. It is the kind of move the applied security community needs, and it deserves recognition.
Now it is up to each of us to do our part: inventory, plan, test, migrate. Without drama, but without procrastinating.
References
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article