AWS KMS adds ML-KEM key encapsulation, putting post-quantum crypto into production

What AWS shipped

On October 26, AWS added ML-KEM to its Key Management Service, according to a post on dev.to. ML-KEM is the key encapsulation mechanism that NIST standardized as FIPS 203 in 2024, and 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 returns a random 32-byte shared secret along with a ciphertext; Decapsulate takes that ciphertext plus the private key and recovers the same secret. The private key itself never leaves the hardware security module, and AWS says those HSMs are validated to FIPS 140-3 Level 3.

The feature is available in every region where KMS runs except Bahrain, the United Arab Emirates and China, the post reports. AWS has not announced separate ML-KEM pricing, and the announcement included no adoption or performance figures.

This is not AWS's first post-quantum step. The same week, Amazon Aurora PostgreSQL added post-quantum TLS key exchange on versions 18 and higher. In April 2025 AWS added a hybrid post-quantum option for connections to KMS itself, and KMS already supports ML-DSA, the FIPS 204 signature scheme, for signing.

Why the key store matters more than another library

Running ML-KEM from a library on a laptop is easy; the hard part is where keys live, who can touch them and what happens when one must be replaced. KMS puts the private key in a validated module and wraps it in access policy, audit logging and rotation, handing the application a shared secret without ever exposing the long-term key.

The threat driving the migration is "harvest now, decrypt later": an adversary records encrypted traffic today and decrypts it once a capable quantum computer exists. That attack only works against the key exchange. If the shared secret was agreed with RSA or elliptic-curve Diffie-Hellman, a future machine could recover it from a recording made today; if it was agreed with ML-KEM, the recording stays locked.

Because KMS is where companies already keep the keys protecting databases, backups and customer data, the post argues, teams can start shielding long-lived data without rebuilding their key management from scratch.

Sizes, hybrids and what a KEM doesn't do

The dev.to author, who uses ML-KEM-768 in a small, unaudited encrypted messenger, reports some practical friction. An ML-KEM-768 public key is 1,184 bytes and its ciphertext 1,088 bytes, against a 32-byte X25519 public key, so protocols need redesign rather than a drop-in swap. Size limits in databases, message queues and URL fields are where migrations quietly break.

Hybrid designs, running ML-KEM alongside a classical algorithm, are the sensible default right now, the author argues, since classical algorithms have decades of cryptanalysis behind them while ML-KEM has only two years as a standard. AWS's own earlier KMS change was hybrid, and its documentation treats hybrid as the migration path.

A KMS feature also doesn't make an application post-quantum by itself. It provides storage and an API; teams still decide which data needs protection, which sessions use the new keys, and how their protocols handle the larger key material. Data encrypted through RSA key transport elsewhere is unaffected. And ML-KEM doesn't solve authentication: it establishes a shared secret without proving who is on the other end, which is why ML-DSA support matters just as much. An unauthenticated key exchange invites person-in-the-middle attacks.

Why it matters

NIST's final transition report, published October 27, one day after the AWS announcement according to the dev.to post, deprecates quantum-vulnerable public-key cryptography after 2030 and disallows it under NIST standards after 2035. For data with a long shelf life, such as medical records, legal archives and stored messages, that deadline is closer than it looks.

The bigger shift is infrastructural. Post-quantum cryptography has mostly lived in libraries, standards documents and research projects. Shipping ML-KEM inside a managed key vault turns the migration into a configuration choice backed by the same hardware, policies and audit logs companies already rely on. The remaining unknowns, including no announced pricing, three excluded regions and no adoption data, are reasons to plan carefully rather than to wait.