Right now, someone could be copying your encrypted traffic off the wire and storing it. They can't read it. The TLS session protecting your database credentials, your API secrets, and your customer data in transit is safe against every computer that exists today.
They don't need to read it today. They need to read it in 2032, when a large enough quantum computer runs Shor's algorithm and unwinds the elliptic-curve math that TLS uses to agree on a session key. The ciphertext they harvested this morning gets decrypted the moment that hardware arrives.
This is the "harvest now, decrypt later" threat, and it's a today problem for any data that stays sensitive for years. AWS has been rolling out the fix across its services, and the interesting part is how quiet it's been. If you connect to AWS Secrets Manager with a current client, your handshake is already post-quantum. Most people never noticed the switch.
Here's what changed, why it matters, and a demo you can run in ten seconds to see it on your own connections.
Why "Later" Is Closer Than the Headlines Suggest
The usual objection: no quantum computer today can crack a P-256 handshake. True. Current machines have a few hundred noisy qubits. Breaking modern key agreement needs millions of stable ones, which is years away, maybe more than a decade.
The timeline that matters isn't when the quantum computer shows up. It's the sum of three numbers:
- How long your data must stay confidential (X years)
- How long your migration to quantum-safe crypto takes (Y years)
- How long until a cryptographically relevant quantum computer exists (Z years)
This is Mosca's inequality. If X + Y > Z, you're already late. A database credential might rotate in 90 days, so its X is tiny. But regulatory records, health data, and long-lived encryption keys can carry a confidentiality requirement measured in decades. For that data, an adversary who records the handshake today wins later, no matter how far off "later" turns out to be.
The weak point is the key agreement, not the bulk encryption. AES-256 holds up fine against quantum attacks. Grover's algorithm only halves its effective strength, and 128 bits of post-quantum security is still unbreakable. The problem is the asymmetric step at the start of every connection, where client and server use elliptic-curve Diffie-Hellman to agree on the symmetric key. Shor's algorithm eats ECDH for breakfast. Recover the key agreement, recover the session key, decrypt everything that flowed over it.
So the fix targets exactly that step.
What AWS Deployed: ML-KEM in a Hybrid Handshake
The new algorithm is ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism, standardized by NIST as FIPS 203 in 2024. Its security rests on lattice problems that no known quantum algorithm solves efficiently. If you followed this earlier, you knew it as CRYSTALS-Kyber. Kyber was the pre-standard draft. ML-KEM is the finished version, and AWS is removing Kyber support from its endpoints in 2026 in favor of it.
The design choice worth understanding is the word "hybrid." AWS didn't rip out elliptic curve and drop in ML-KEM alone. The handshake negotiates both at once: X25519 for the classical part and ML-KEM-768 for the post-quantum part, combined into a single group labeled X25519MLKEM768. Both key exchanges run, and their shared secrets get mixed together to derive the session key.
Why keep the old one? Because ML-KEM is new. Lattice cryptography has held up under scrutiny, but "held up so far" isn't the decades of battle-testing that X25519 has behind it. If someone breaks ML-KEM tomorrow, the hybrid handshake is still as strong as classical X25519, which is what you run today anyway. If a quantum computer arrives, the ML-KEM half holds. You have to break both halves to lose. It's a hedge, and it's the right one.
This runs on AWS's open-source crypto stack: AWS-LC for the primitives and s2n-tls for the TLS implementation. AWS-LC was the first open-source cryptographic module to get ML-KEM into a FIPS 140-3 validation, which matters if your compliance requirements only accept validated modules.
Support landed first, back in April 2025, on the three services carrying the most confidentiality-critical traffic: KMS, ACM, and Secrets Manager. Since then it has spread. Run the demo below and you'll find it negotiated on S3, DynamoDB, and EC2 endpoints too. AWS committed to deploying ML-KEM to every service with an HTTPS endpoint, and by mid-2026 that rollout is well underway.
The Part Everyone Gets Wrong: This Is Shared Responsibility
Here's the trap. AWS turning on ML-KEM at the endpoint does nothing for you by itself. The server only speaks post-quantum if the client offers it first. Your SDK, your TLS library, your client, that's the side that has to propose X25519MLKEM768 in the ClientHello. If your client offers only classical curves, the handshake stays classical and your traffic is still harvestable, no matter how ready the server is.
So the migration is your client fleet, not the AWS side. The good news is that for the flagship path, AWS already made the default decision for you. As of April 2026, these Secrets Manager clients enable hybrid post-quantum TLS out of the box:
- The Workload Credentials Provider (formerly the Secrets Manager Agent) v2.0.0 and later
- The Secrets Manager Lambda extension v19 and later
- The Secrets Manager CSI Driver v2.0.0 and later
On those versions you're done. No code change, no flag. Upgrade the client and the handshake goes post-quantum.
For direct SDK usage, support exists in the AWS SDKs for Rust, Go, Node.js, Kotlin, Python, and Java v2, each with its own minimum version. Some enable it automatically, some need a flag. Java v2 is the explicit case. You need the AWS Common Runtime HTTP client, version 2.30.22 or later, and you turn it on:
// Maven: software.amazon.awssdk:aws-crt-client:2.30.22 (or later)
SdkAsyncHttpClient crtClient = AwsCrtAsyncHttpClient.builder()
.postQuantumTlsEnabled(true)
.build();
KmsAsyncClient kms = KmsAsyncClient.builder()
.httpClient(crtClient)
.build();
// This call now negotiates X25519MLKEM768
kms.listKeys().get();
The Rust SDK uses rustls. Add the crate and turn on the prefer-post-quantum feature flag, and the client offers ML-KEM automatically. Across every language the rule is the same: the endpoint is ready, but the algorithm only gets used if your client asks for it. Auditing client and SDK versions is the actual work.
The Demo: See It on Your Own Connections
You don't need an AWS account to watch a post-quantum handshake happen. You need OpenSSL 3.5 or later, which added X25519MLKEM768 as a default group. Check your version first:
$ openssl version
OpenSSL 3.5.7 9 Jun 2026
Now force the handshake to use only the hybrid group and look at what gets negotiated:
$ echo | openssl s_client -connect secretsmanager.us-east-1.amazonaws.com:443 \
-groups X25519MLKEM768 2>/dev/null | grep "Negotiated TLS1.3 group"
Negotiated TLS1.3 group: X25519MLKEM768
That's it. The server accepted the post-quantum group and the handshake completed. I ran the same check across a handful of endpoints and every one came back post-quantum:
kms.us-east-1.amazonaws.com Negotiated TLS1.3 group: X25519MLKEM768
acm.us-east-1.amazonaws.com Negotiated TLS1.3 group: X25519MLKEM768
secretsmanager.us-east-1.amazonaws.com Negotiated TLS1.3 group: X25519MLKEM768
dynamodb.us-east-1.amazonaws.com Negotiated TLS1.3 group: X25519MLKEM768
s3.amazonaws.com Negotiated TLS1.3 group: X25519MLKEM768
ec2.us-east-1.amazonaws.com Negotiated TLS1.3 group: X25519MLKEM768
Here's a small script to check your own list. Point it at any endpoint your workloads talk to:
#!/usr/bin/env bash
# pq-check.sh: verify an endpoint negotiates post-quantum TLS
# requires OpenSSL 3.5+
endpoints=(
kms.us-east-1.amazonaws.com
secretsmanager.us-east-1.amazonaws.com
s3.amazonaws.com
)
for ep in "${endpoints[@]}"; do
group=$(echo | openssl s_client -connect "$ep:443" \
-groups X25519MLKEM768 2>/dev/null \
| sed -n 's/^Negotiated TLS1.3 group: //p')
if [ "$group" = "X25519MLKEM768" ]; then
printf '%-45s PQ-TLS ✓ (%s)\n' "$ep" "$group"
else
printf '%-45s classical or handshake failed\n' "$ep"
fi
done
One caveat this demo hides: OpenSSL is not the client running in production. It proves the endpoint supports post-quantum. It says nothing about whether your application's SDK actually offered it. For that, you verify real traffic.
Every API call to KMS, ACM, and Secrets Manager logs a tlsDetails block in CloudTrail, and inside it is a keyExchange field. When the connection used post-quantum TLS, it reads X25519MLKEM768. Pull a recent event and check:
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventSource,AttributeValue=secretsmanager.amazonaws.com \
--max-results 1 \
--query 'Events[0].CloudTrailEvent' --output text \
| python3 -c 'import json,sys; e=json.load(sys.stdin); print(e.get("tlsDetails"))'
If that field comes back X25519MLKEM768, your real client negotiated post-quantum. If it shows X25519 or a P-curve while OpenSSL said the endpoint supports it, something between your app and AWS downgraded the connection. That's the signal to go looking, and it usually points at one thing.
The Silent Failure Mode: Middleboxes
The most common reason a post-quantum handshake quietly falls back to classical is a middlebox. Some deep-packet-inspection firewalls, load balancers, and proxies choke on the larger ClientHello or on TLS extensions they don't recognize. They either drop the connection or strip it down to something they understand.
The hybrid handshake is bigger for a reason. Moving from ECDH-only to ECDH plus ML-KEM adds roughly 1,600 bytes to the handshake and 80 to 150 microseconds of extra compute for the ML-KEM operations. That's a one-time cost at connection setup. But 1,600 extra bytes is enough to trip a poorly written middlebox that assumed handshakes fit in one packet.
This is why the CloudTrail check matters more than the OpenSSL check. Your endpoint can be ready, your SDK can be current, and a firewall in the middle can still be handing you classical crypto without a single error in your logs. Better to catch that in a query today than in an audit three years from now.
"But What About Performance?"
The reflexive worry with any crypto change is latency. Post-quantum key exchanges are bigger, and bigger sounds slower.
Here are AWS's published numbers, measured against KMS GenerateDataKey from an EC2 client in the same Region:
- With TLS connection reuse (the SDK default): throughput went from 216.1 to 216.0 transactions per second. A 0.05 percent difference. Noise.
- Without connection reuse (a fresh handshake for every request, which you should never do): throughput dropped from 108.7 to 106.2 TPS, about 2.3 percent, and that's the pathological worst case.
If you reuse connections, and every well-configured SDK does by default, enabling post-quantum TLS is effectively free. The larger handshake is a startup cost paid once per connection, then amortized across every request on it. The "it'll slow us down" objection doesn't survive contact with the measurements.
What to Actually Do This Week
You don't need a quantum computer to act, and you don't need a six-month project either.
-
Run
pq-check.shagainst the endpoints your workloads hit. Ten minutes tells you which servers are ready. Most AWS endpoints already are. - Upgrade the easy wins. Workload Credentials Provider (formerly Secrets Manager Agent), Lambda extension, or CSI Driver on their current major versions turn on post-quantum TLS with zero code change.
-
Enable the flag where it's opt-in, like
postQuantumTlsEnabled(true)on the Java CRT client orprefer-post-quantumin Rust. -
Verify real traffic with CloudTrail. Check
tlsDetails.keyExchangereadsX25519MLKEM768. If it doesn't while the endpoint supports it, hunt the middlebox. - Prioritize by data lifetime. Traffic carrying data that must stay secret for years is where harvest-now-decrypt-later actually bites. Migrate that first.
The quantum computer that breaks P-256 isn't here. The adversary recording your handshakes so they can decrypt them when it arrives might already be. The defense costs you a client upgrade and, in the best case, nothing else. A real threat, a cheap fix, and a vendor that already did the hard part. The only way to lose is to leave it off.
*Sources: *
AWS Security Blog, "ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager" (April 2025);
AWS Security Blog, "Protecting your secrets from tomorrow's quantum risks" (April 2026);
NIST FIPS 203. OpenSSL handshake output and endpoint results were captured live with OpenSSL 3.5.7.
Benchmark figures are AWS-published measurements for KMS GenerateDataKey and vary with instance type, workload, and network path.

Top comments (0)