AWS KMS Adds Post-Quantum ML-KEM Key Exchange

Amazon Web Services says its Key Management Service (KMS) now supports ML-KEM, the post-quantum key-exchange method standardised by the US National Institute of Standards and Technology (NIST). Customers can create ML-KEM key pairs in all three sizes NIST defines, with the private half held inside AWS’s hardware security modules.

AWS announced the change on 26 October in a What’s New post, and its KMS developer guide and API reference now document the new keys. The feature is available in every region where KMS runs, except Middle East (UAE), Middle East (Bahrain) and the China regions.

What AWS has added

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is set out in NIST’s FIPS 203 standard. It lets two parties agree on a shared secret, which they can then use to encrypt data between them. KMS supports all three of the standard’s key specs: ML-KEM-512, ML-KEM-768 and ML-KEM-1024, from smallest to strongest.

Two new API calls do the work. According to AWS, Encapsulate uses the public key to produce a random 32-byte shared secret together with an encrypted form of it, called the ciphertext. Decapsulate uses the matching private key to recover the same secret from that ciphertext. The documentation says the secret can be used directly as key material or fed through a key derivation function to make several keys.

AWS says the private key is protected in hardware security modules validated to FIPS 140-3 Level 3, and its guide says that key “never leaves AWS KMS unencrypted”. The public key can be exported with the existing GetPublicKey call and handed to partners or client apps, which can then encapsulate secrets locally. AWS names AWS-LC, OpenSSL and Bouncy Castle as libraries that can do this.

The documentation adds some practical detail. The ciphertext is 768 bytes for ML-KEM-512, 1,088 bytes for ML-KEM-768 and 1,568 bytes for ML-KEM-1024. If a ciphertext has the wrong length, Decapsulate returns an error; otherwise it always returns a 32-byte value, even when the ciphertext was altered or made with a different key. AWS calls this “implicit rejection”, a security feature that helps protect against chosen-ciphertext attacks. Because the response gives no sign of whether the ciphertext was valid, the guide tells both parties to confirm they derived the same secret before using it.

Why key exchange is the urgent part

AWS frames the launch around the “harvest now, decrypt later” threat. An attacker records an encrypted exchange today and stores it, then recovers the shared secret years from now, once a powerful enough quantum computer exists. Data that must stay secret for a decade or more is already exposed to that risk, even though no such computer exists yet.

That is why key exchange comes before signatures in most migration plans. A forged signature only matters once quantum machines arrive, but a recorded key exchange can be broken after the fact. AWS says NIST designed ML-KEM to replace the classical methods for this job, Diffie-Hellman and elliptic-curve Diffie-Hellman key agreement and RSA-based key transport. NIST’s final roadmap, published on 27 October, deprecates those classical methods after 2030 and names ML-KEM-768 as its default for post-quantum key establishment.

How soon the threat arrives is still argued over. Researchers keep lowering their estimates of the machine needed: Iceberg Quantum, for example, has claimed RSA-2048 could fall to fewer than 100,000 qubits. For a cloud provider, putting ML-KEM into its main key service turns post-quantum key exchange from a research project into an option most customers can switch on.

The move also fits a pattern among large infrastructure firms of building post-quantum protection into key management rather than leaving it to each application. Cloudflare took a similar route last week when it wrapped regional private keys in post-quantum encryption in its GeoKey Manager beta.

Gaps and open questions

The launch has limits. Encapsulate and Decapsulate are unavailable in the China regions, according to the API reference, and the What’s New post also excludes the UAE and Bahrain regions without giving a reason. Neither source gives pricing for the new operations. The keys are a building block: customers still have to change their own software to use the shared secrets, and AWS has not said when other services will use ML-KEM keys from KMS automatically.