AWS KMS Just Shipped ML-KEM. Post-Quantum Crypto Stopped Being a Side Project

On October 26, AWS added ML-KEM to its Key Management Service. If you build with cryptography, that date matters more than most of the quantum headlines this year. Not because a quantum computer is about to break RSA tomorrow. Because the boring, production part of the stack just went post-quantum, and boring is exactly how a migration actually happens.

I noticed the announcement for a personal reason: ML-KEM-768 is the same algorithm I use for key exchange in my own encrypted messenger. For the past year, using it has felt like working slightly ahead of the curve. Now the curve has caught up, and it is sitting inside the key vault of the biggest cloud provider on the planet.

What actually shipped

AWS KMS now lets you create keys for ML-KEM, the key encapsulation mechanism NIST standardized as FIPS 203 in 2024. All three parameter sets are supported: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. Two new API calls do the work. Encapsulate takes a public key and produces a random 32-byte shared secret plus a ciphertext. Decapsulate takes that ciphertext and the private key and recovers the same secret. The private key itself never leaves the hardware security module. AWS says those HSMs are validated to FIPS 140-3 Level 3.

That last detail is the whole point. A KEM is only as good as the place its private key lives. Anyone can run ML-KEM from a library on a laptop. KMS puts the private key in a validated module, wraps it in access policy, audit logging, and key rotation, and hands your application a shared secret without ever showing it the long-term key. That is the difference between a demo and infrastructure.

A few facts worth keeping straight. The feature is available in every region where KMS runs except Bahrain, the United Arab Emirates, and China. AWS has not announced a separate ML-KEM price, and the announcement gave no customer adoption numbers or performance figures. The same week, Amazon Aurora PostgreSQL added post-quantum TLS key exchange on versions 18 and higher. And this is not AWS's first post-quantum move: in April 2025 it added a hybrid post-quantum method to protect connections to KMS itself, and KMS already supports ML-DSA, the FIPS 204 signature scheme, for signing.

Why a KMS launch matters more than another library release

Most of the post-quantum conversation is about algorithms. Libraries are the easy part. The hard part is where keys live, who can touch them, and what happens when one needs to be replaced.

Think about what a key exchange actually protects. The threat that drives this whole migration has a plain name: harvest now, decrypt later. An adversary records your encrypted traffic today and opens it years from now, once a capable quantum computer exists. That only works against the key exchange. If the shared secret was agreed with RSA or elliptic-curve Diffie-Hellman, a future machine can recover it from a recording made today. If it was agreed with ML-KEM, the recording stays locked.

That is why putting ML-KEM in KMS is a bigger deal than putting it in one more open source library. KMS is where companies already keep the keys that protect their databases, their backups, their customer data. When the key store itself can speak ML-KEM, a team can start protecting data that will still be sensitive in ten years without rebuilding their key management from scratch. The migration stops being a research project and becomes a configuration choice.

NIST's final transition report, published October 27, one day after the AWS announcement, sets the clock: quantum-vulnerable public-key cryptography is deprecated after 2030 and disallowed under NIST standards after 2035. That sounds far away. It is not, if your data has a long shelf life. Medical records, legal archives, government files, and yes, chat histories, are exactly the kind of data that is still valuable in a decade. The question is not whether quantum computers arrive on schedule. It is whether you want your ten-year-old ciphertexts to be readable when they do.

What I learned using ML-KEM-768 in my own messenger

I built my messenger around a hybrid design: ML-KEM-768 for key encapsulation plus ECDH on P-256, with ML-DSA-65 identity signatures on top. My project is small, experimental, and not independently audited, and I say that plainly because it matters. But building with the algorithm taught me things no announcement will tell you.

First, the sizes are real. An ML-KEM-768 public key is 1,184 bytes. The ciphertext is 1,088 bytes. Compare that with a 32-byte X25519 public key and you understand immediately why protocols need redesign, not just a swap. Every message that carries a key bundle gets heavier. On a phone, on a slow connection, that weight shows up.

Second, the hard part was never the math. Libraries handle the math. The hard part was everything around it: where the private key is stored, how a contact verifies a changed key, what happens to old messages when a key rotates. I ended up building safety numbers, the same idea Signal uses, so two people can compare a fingerprint of each other's identity keys and know nobody swapped them in the middle. Key management is the product. The algorithm is one component inside it.

Third, hybrid is the sane default right now. Running ML-KEM alongside a classical algorithm means you are protected if either one holds up. Pure post-quantum sounds cleaner, but classical algorithms have decades of cryptanalysis behind them and ML-KEM has two years as a standard. Until the new standard earns that kind of track record, belt and suspenders is the honest choice. AWS seems to agree: its earlier KMS move was hybrid, and its documentation treats hybrid as the migration path.

What this launch does not do

A KMS feature does not make your application post-quantum. It gives you a place to keep a post-quantum key and an API to use it. You still have to decide which data needs protection, which sessions use the new keys, and how your protocol handles the bigger key material. If your application encrypts with a key it derived through RSA key transport somewhere else, a shiny ML-KEM key in KMS changes nothing for that data.

It also does not solve the identity problem. ML-KEM establishes a shared secret. It does not prove who is on the other end. That is what signatures are for, and it is why ML-DSA support in KMS matters as much as ML-KEM. A key exchange without authentication is an invitation to a person-in-the-middle. Any real deployment needs both, and needs to think about how keys are verified when they change, not just when they are created.

And the usual caveats apply. No pricing was announced, so budget planning still needs a conversation with AWS. Three regions are excluded at launch. And no vendor announcement tells you how many customers have actually migrated, so treat any claim about industry momentum as marketing until you see real deployments.

If you are starting a migration, start here

I am not going to pretend there is a checklist that fits every system. But the order that makes sense to me, from building my own small version of this problem, looks like this.

Start with an inventory. List every place your system uses public-key cryptography: TLS, key exchange, signatures, encrypted backups, signed updates. Most teams are surprised by how many places there are. You cannot migrate what you have not found.

Protect the long-lived data first. Session keys expire. Backups, archives, and stored messages do not. A KMS ML-KEM key is most useful exactly where the data will outlive the migration.

Go hybrid, and test with real traffic. ML-KEM key material is bigger than what your protocol was designed for. Size limits in databases, message queues, and URL fields are where migrations quietly break. Find those limits in testing, not in production.

Finally, plan for key changes. The day a key needs to rotate or a contact's key changes is the day your verification story gets tested. Build the human side of that early: a fingerprint users can compare, a warning when something changes, a clear path to re-verify. I learned that one the slow way, by getting it wrong first.

The takeaway

A year ago, using ML-KEM meant pulling a library into your own project and explaining to people why you were doing something unusual. This week, the same algorithm is a key type you can pick from a dropdown in the console of the largest cloud provider. That is what a real transition looks like. Not a breakthrough, not a deadline, just the standard plumbing getting a new option, one service at a time.

The quantum computer is still not here. The migration is. And it is arriving the way infrastructure always arrives: quietly, in a changelog, on a Tuesday.

Sources: AWS Weekly Roundup, November 2, 2026; AWS What's New, KMS ML-KEM support, October 26, 2026; NIST IR 8547, "Transition to Post-Quantum Cryptography Standards," final version, October 27, 2026; TechInformed, "AWS KMS adds quantum-resistant key exchange," October 30, 2026.