AWS KMS exposes ML-KEM to encapsulate keys against quantum computers

October 26, 2026. AWS Key Management Service (KMS) opens ML-KEM keys, the post-quantum key-encapsulation mechanism standardized by NIST under FIPS 203. April 2026. AWS had already turned on hybrid post-quantum TLS built on ML-KEM by default across KMS, Secrets Manager, ACM, Payment Cryptography, and S3. August 2024. NIST published its first post-quantum standards, FIPS 203 and FIPS 204. Why it matters: until now, AWS’s post-quantum work was mostly invisible, tucked under TLS; now KMS exposes the raw key-establishment primitive, and you can wire it into your own protocol.

What the update actually changes

KMS’s ML-KEM support covers all three specifications in FIPS 203: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. Each maps to a rising security level on the same module-lattice algorithm — the “lattice” family that resists quantum attack where RSA and ECDH collapse under Shor’s algorithm.

Two new operations hold it together. The Encapsulate API takes a public key and produces a random 32-byte shared secret plus its encrypted form, the ciphertext. The Decapsulate API recovers that shared secret from the ciphertext using the matching private key. The private key is protected inside FIPS 140-3 Level 3 validated HSMs, and the GetPublicKey API lets you export the public key to encapsulate locally with AWS-LC, OpenSSL, or Bouncy Castle.

The important nuance is the mechanism itself. Unlike a key-agreement scheme such as ECDH — where each party contributes a share — a KEM generates the secret from the recipient’s public key alone. The secret it returns is cryptographically random: you can use it directly as key material, or feed it through a KDF to derive several distinct keys and nonces.

The flow, in commands

# 1. Create an ML-KEM-768 key pair (KeyUsage ENCAPSULATE_DECAPSULATE)
aws kms create-key \
  --key-spec ML_KEM_768 \
  --key-usage ENCAPSULATE_DECAPSULATE \
  --description "post-quantum encapsulation key"

# 2. Export the public key — the private key never leaves KMS
aws kms get-public-key --key-id <key-id> \
  --query PublicKey --output text > mlkem-768.pub

# 3. Sender side: encapsulate a 32-byte shared secret
aws kms encapsulate --key-id <key-id> \
  --encryption-algorithm ML_KEM_768

# 4. Recipient side: decapsulate to recover the same secret
aws kms decapsulate --key-id <key-id> \
  --encryption-algorithm ML_KEM_768 \
  --ciphertext-blob fileb://ciphertext.bin

The ciphertext from step 3 travels freely; only the recipient, holding the private key in KMS, can recover the secret from it. AWS recommends verifying that the public key you receive came from the expected party before using it to encapsulate.

The missing piece: hybrid

One piece the ecosystem is still waiting for is turnkey hybrid encryption. The IETF’s PQ-HPKE draft (Post-Quantum Hybrid Public Key Encryption) combines into a single operation encapsulation of the secret, a KDF to derive an AES key and an IV, then AES-GCM encryption of the message. AWS says it is tracking this standardization closely as a post-quantum replacement for RSA-based encryption. Until then, assembling those blocks yourself is possible — and that is exactly what ML-KEM in KMS lets you do cleanly.

Hybrid matters for more than convenience. The hybrid post-quantum TLS AWS already enables combines ML-KEM with a classical method (usually ECDH): if ML-KEM were broken tomorrow, the classical part still preserves confidentiality. That caution is warranted — ML-KEM is young, and its at-scale deployment has only a few years of history. A native deployment — ML-KEM only, with no classical fallback — makes sense only if you accept that risk explicitly.

Why now, and not “someday”

The threat has a name: harvest now, decrypt later. An adversary recording your encrypted traffic today does not need a quantum computer yet: they only have to store the data until quantum computing matures, then retroactively break the RSA or ECDH layer that protects your session keys. For data that must stay confidential for years — banking secrets, medical records, state secrets, trade secrets — the risk is real today.

The regulatory calendar adds concrete pressure. The post-quantum migration schedules asked for by authorities (NIST in the US via IR 8547, ANSSI in France) set milestones toward the end of the decade. An organization that waits for quantum to arrive before migrating has already lost: the collection window has already opened.

Verdict

KMS’s ML-KEM support is not a cosmetic addition — it is the moment AWS stops “doing post-quantum for you” and hands you the building block to do it yourself, in your own key transport.

If you design a key-exchange protocol or system, adopt ML-KEM-768 as the default specification: it sits between ML-KEM-512 (lighter, thinner margin) and ML-KEM-1024 (heavier, for maximum requirements), and the private key stays locked in a FIPS 140-3 Level 3 HSM. If you are migrating an RSA key-encryption system, target hybrid ML-KEM plus a classical method while your counterparts are still catching up on post-quantum. If you only do TLS with AWS services, the hybrid TLS enabled by default since April 2026 already covers you — but check your KMS key policies and rotation, because a protected transport layer does not protect a badly managed secret. In every case, one rule holds: post-quantum is migrated before you need it, never after.

References

• AWS What’s New — AWS Key Management Service now supports ML-KEM for post-quantum key encapsulation (October 26, 2026)
• AWS KMS Developer Guide — Post-quantum keys in AWS KMS
• AWS KMS Developer Guide — ML-KEM key specs
• AWS — AWS Support for Post-Quantum Confidentiality
• NIST — FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST — IR 8547, Transition to Post-Quantum Cryptography Standards