AWS KMS goes post-quantum with ML-KEM key encapsulation
KMS adds NIST FIPS 203 post-quantum key encapsulation: ML-KEM-512/768/1024, Encapsulate and Decapsulate APIs, private keys in FIPS 140-3 Level 3 HSMs.
DevOps, Architecture, Security
Nobody knows when a quantum computer able to break RSA will show up, and the people claiming a date are usually selling something. I've heard "what's our quantum deadline?" asked in calendar format more than once. There isn't one. The catch is harvest now, decrypt later, and the KMS announcement names it directly: an adversary records today's key-establishment exchange, then recovers the shared secret once quantum hardware is powerful enough. The attacker's timeline is a question mark, which is why this particular migration can't be scheduled by quarter.
AWS shipped two small answers to that last week. KMS now supports Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) for post-quantum key encapsulation, and Aurora PostgreSQL added post-quantum TLS key exchange on versions 18 and up. Both are config-level changes, and both are the kind a security review eventually asks about anyway.
What AWS shipped
ML-KEM is the post-quantum cryptography standard NIST published as FIPS 203 . A key-encapsulation mechanism lets two parties establish a shared secret: run Encapsulate with a public key and you get a random 32-byte shared secret plus its ciphertext; run Decapsulate on that ciphertext with the matching private key and you recover the same secret. NIST designed ML-KEM to replace the classical key-establishment schemes, DH/ECDH key agreement and RSA-based key transport, with its IR 8547 roadmap laying out the transition.
KMS supports all three ML-KEM key specs defined in FIPS 203: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. The private key of an ML-KEM key pair stays protected in FIPS 140-3 Level 3 validated hardware security modules. The public key is meant to travel: the GetPublicKey API exports it for partners, client applications, or external systems, which can then run the encapsulation locally with libraries like AWS-LC, OpenSSL, or Bouncy Castle.
Availability is every Region where KMS runs except Middle East (UAE), Middle East (Bahrain), and China Regions.
The Aurora half is the same problem at the transport layer: post-quantum TLS key exchange for data in transit, on Aurora PostgreSQL versions 18 and higher. You modify the ssl_groups parameter and pick cryptographic groups from Amazon Aurora PostgreSQL's allow list so the selection matches your organization's security standards.
Setup, which is API work
The announcement names the APIs instead of pasting CLI text, so the walkthrough sticks to what the post and the KMS Developer Guide key-spec reference cover:
- Provision an ML-KEM key pair in KMS at one of the three specs. The private key lands in the FIPS 140-3 Level 3 HSMs and stays there.
- Export the public key with GetPublicKey and distribute it to whoever establishes secrets with you: partners, client applications, external systems.
- The other side encapsulates. Through the KMS Encapsulate API, the public key produces a random 32-byte shared secret plus ciphertext. They can also encapsulate locally with AWS-LC, OpenSSL, or Bouncy Castle, which is what the exportable key is for.
- You call Decapsulate on the ciphertext; the private key in the HSM recovers the same 32 bytes.
- Both sides now hold the same random 32-byte shared secret. What your protocol does with those bytes is your design decision; the APIs stop at establishing it.
For Aurora, versions 18 and higher support modifying ssl_groups, and the cryptographic groups come from the Amazon Aurora PostgreSQL allow list.
Tips worth more than the setup guide
Inventory the classical paths first. The KMS calls are the fast half of the migration. The slow half is finding every place DH/ECDH key agreement or RSA key transport still runs in your estate: mTLS handshakes, partner integrations, some service that wraps secrets in RSA because someone was in a hurry. NIST's IR 8547 roadmap is the checklist to sort those findings against.
The exportable public key is the design point, so use it. Partners without AWS accounts can encapsulate in their own environment with AWS-LC, OpenSSL, or Bouncy Castle while your private key never leaves an HSM. A crypto migration that doesn't demand every counterparty join your platform is rarer than it should be.
Stage the Aurora change on one cluster. ssl_groups on PostgreSQL 18 or higher is version-gated, so fleets below 18 keep classical TLS until they upgrade. The announcement says nothing about how older client drivers negotiate the new groups, and TLS group changes are precisely the kind of parameter edit that surprises old clients.
Costs
Neither announcement lists new pricing. Encapsulate, Decapsulate, and GetPublicKey are KMS API calls, so they fall under KMS's existing per-request billing, and the Aurora item is a parameter edit with no price attached. If AWS publishes a pricing page for this before you ship, read it first.
The security-review agenda
- The scope is transit. The KMS part establishes shared secrets and the Aurora part encrypts connections in transit. Nothing retroactively rescues exchanges already recorded under classical schemes; the inventory above is where the risk lives.
- The private key stays inside FIPS 140-3 Level 3 validated HSMs. That's the sentence to carry into the compliance narrative when someone asks where the key material lives.
- The 32-byte shared secret is yours after Decapsulate returns it. Neither announcement specifies the protocol that consumes it, so treat those bytes as live key material end to end and audit wherever your code touches them.
- Region availability excludes Middle East (UAE), Middle East (Bahrain), and China Regions. If your footprint includes those, plan around the gap.
There's still no calendar entry for quantum decryption and I won't pretend a parameter change closes that gap. But key exchange that resists being recorded is cheaper to add now than to explain to an auditor later. Both of these switches take minutes to pull. The inventory takes longer, and it's the part that matters.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article