AWS KMS adds ML-KEM key pairs with Encapsulate and Decapsulate APIs
Victoria Shinder1 min readAWS Key Management Service now supports ML-KEM, the module-lattice key-encapsulation mechanism standardised by NIST as FIPS 203. AWS frames it as the replacement for classical key establishment — Diffie-Hellman and ECDH key agreement and RSA key transport — that NIST's migration roadmap, IR 8547, sets out, and as the answer to "harvest now, decrypt later", where a recorded key exchange is broken once a capable quantum computer exists.
KMS offers all three key specs in the standard: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. A new Encapsulate API takes the public key and returns a random 32-byte shared secret together with its ciphertext; Decapsulate recovers the secret from that ciphertext with the private key. The private half never leaves KMS's HSMs, which are validated to FIPS 140-3 Level 3. The public key can be exported with GetPublicKey, so a partner or client can run the encapsulation locally with a library such as AWS-LC, OpenSSL or Bouncy Castle.
ML-KEM is available in every Region where KMS runs, except Middle East (UAE), Middle East (Bahrain) and the China Regions.
What it means
The useful pattern here is asymmetric: the side that holds the KMS key never has to expose a private key, while the other side needs nothing but a public key and a mainstream library. That makes a managed service a reasonable place to start post-quantum key establishment for service-to-service secrets. The Region exclusions matter for anyone with data-residency constraints in the Gulf or China — those workloads still need a classical or self-managed path.