ML-KEM Key Management: How to Generate, Store and Rotate Post-Quantum Keys (2026)

ML-KEM key management is the set of controls for generating, storing, distributing, rotating and destroying the keys used by ML-KEM, the post-quantum key-encapsulation mechanism standardized by NIST in FIPS 203. Most ML-KEM keys are ephemeral and live for a single TLS handshake; the static ones need the same custody as any long-term private key, with two new details: larger keys, and a 64-byte seed that is as sensitive as the private key itself.

Key establishment is the part of your cryptography exposed to "harvest now, decrypt later": traffic recorded today with RSA or ECDH key exchange can be decrypted once a large enough quantum computer exists. That is why NIST's draft transition plan and the US federal timeline put key establishment first, and why ML-KEM is the first post-quantum algorithm most organizations will run in production, often already through hybrid TLS in recent OpenSSL builds.

This guide covers the FIPS 203 key sizes, how ML-KEM key management differs from RSA and ECDH, hybrid TLS with X25519MLKEM768, where ML-KEM keys should live, a lifecycle table, the NIST IR 8547 and CNSA 2.0 deadlines, the wider PQC key management picture (ML-DSA, SLH-DSA and the key hierarchy), and migration planning.

---

Table of Contents

1. What Is ML-KEM?
2. ML-KEM Parameter Sets and Key Sizes
3. Why ML-KEM Key Management Differs from RSA and ECDH
4. Comparison: RSA and ECDH vs ML-KEM Key Management
5. Hybrid Post-Quantum TLS and X25519MLKEM768
6. Where ML-KEM Keys Live: Ephemeral vs Static
7. The ML-KEM Key Lifecycle
8. Deadlines: NIST IR 8547 and CNSA 2.0
9. PQC Key Management: Beyond ML-KEM
10. How to Plan Your ML-KEM Migration
11. How DuoKey Fits
12. FAQ

---

What Is ML-KEM?

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is specified in FIPS 203, which NIST published on 13 August 2024. In NIST's words, it is a key-encapsulation mechanism that two parties can use "to establish a shared secret key over a public channel". Its security rests on the Module Learning with Errors problem, which is believed to resist attacks by quantum computers.

Two points matter for key management:

• ML-KEM is a KEM, not a signature scheme. It replaces RSA key transport and (EC)DH key agreement. It does not sign anything. Certificates, code signing and authentication move to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205), covered in our ML-DSA certificates and post-quantum PKI guide.
• A KEM has three operations, not two. KeyGen produces an encapsulation key ek (public) and a decapsulation key dk (private). Encaps(ek) returns a ciphertext and a 32-byte shared secret. Decaps(dk, ciphertext) recovers the same shared secret.

ML-KEM at a glance

ML-KEM vs Kyber. ML-KEM is not byte-for-byte the same as the CRYSTALS-Kyber submission. The NSA's CNSA 2.0 FAQ notes that the CRYSTALS algorithms "had a variety of versions" with tweaks made before the FIPS was published. Implementations of pre-standard Kyber, such as the early X25519Kyber768Draft00 TLS group, do not interoperate with ML-KEM and should be upgraded.

ML-KEM is one of three NIST post-quantum standards, alongside ML-DSA (FIPS 204) and SLH-DSA (FIPS 205); our post-quantum cryptography overview compares them.

NIST's companion recommendation, SP 800-227 (final, September 2025), explains how to use KEMs safely, including static versus ephemeral keys, data at rest and hybrid constructions. Read it alongside FIPS 203 when you write an ML-KEM policy.

---

ML-KEM Parameter Sets and Key Sizes

FIPS 203 approves three parameter sets. The sizes below are from FIPS 203, Table 3; the security categories from Section 8.

For comparison, an X25519 public key is 32 bytes.

Which one to pick. FIPS 203 states: "NIST recommends using ML-KEM-768 as the default parameter set, as it provides a large security margin at a reasonable performance cost." It also advises using the strongest parameter set that is practical when you first establish protection, to avoid a later transition. National security systems follow CNSA 2.0, which points to ML-KEM-1024 (see Deadlines).

The seed. ML-KEM key generation starts from two 32-byte random values, d and z. FIPS 203 allows you to store this 64-byte seed and re-derive the key pair later, but adds that "it is sensitive data and shall be treated with the same safeguards as a decapsulation key."

---

Why ML-KEM Key Management Differs from RSA and ECDH

1. A different interface. With ECDH, each side combines its private key with the peer's public key. With RSA key transport, the sender picks a secret and encrypts it. ML-KEM is neither: the encapsulating party gets a fresh shared secret and a ciphertext, and only the holder of dk can recover that secret. Libraries, HSM APIs and key-wrapping workflows built around encrypt/decrypt or derive need a new encapsulate/decapsulate path. PKCS#11 3.2 adds exactly that (see the FAQ).

2. Ephemeral and static keys follow different rules. SP 800-227 is explicit: "If an application uses an ephemeral key pair, the key pair shall be used for only one execution of key-establishment via a KEM and shall be destroyed as soon as possible after its use." A static ML-KEM key, by contrast, is a long-term private key that needs custody, backup and rotation.

3. Two private formats to manage. A private ML-KEM key can be stored as the 64-byte seed, as the expanded dk (1,632 to 3,168 bytes), or both. SP 800-227 notes that "some applications might call for storing keys using only a short seed, while other applications might call for storing keys in an expanded format that allows for faster computations." Your policy must state which format is stored, exported and backed up, because a seed-only backup cannot be restored into a system that accepts only dk, and vice versa.

4. Proof of possession changes. A KEM key cannot sign a certificate request. SP 800-227 says a party that uses someone else's static encapsulation key "must have assurance of the other party's ownership of the key", obtained from a certificate authority or through proof of possession plus identity verification. Expect enrollment flows for ML-KEM certificates to differ from the CSR-with-signature model you use for RSA.

5. Input checking is mandatory. FIPS 203 requires Encaps and Decaps to run only on checked inputs (Section 7). Importing a key from an untrusted source is therefore a validation step, not just a file copy.

6. Larger objects. Bigger keys and ciphertexts affect TLS handshakes, database columns, attribute limits and HSM storage quotas.

---

Comparison: RSA and ECDH vs ML-KEM Key Management

---

Hybrid Post-Quantum TLS and X25519MLKEM768

X25519MLKEM768 is a TLS 1.3 key-exchange group that runs ML-KEM-768 and X25519 in parallel and combines both shared secrets, so the session stays secure as long as either algorithm holds. It is standardized in RFC 10024, "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3" (Standards Track, August 2026), which was published from the IETF draft draft-ietf-tls-ecdhe-mlkem.

RFC 10024 defines three groups:

One detail trips up implementers: in X25519MLKEM768 the ML-KEM part comes first in the key share and in the concatenated shared secret, while the two NIST-curve groups put the ECDH part first.

What this means for key management: nothing to store. In hybrid TLS 1.3, the client generates a fresh ML-KEM key pair per handshake, sends the 1,184-byte encapsulation key, and the server answers with a ciphertext. Both key pairs are ephemeral and destroyed after the handshake, exactly like ECDHE today. The server still authenticates with its existing RSA or ECDSA certificate.

It is also already deployed. Browser and server support, handshake-size issues and configuration examples are in our hybrid post-quantum TLS guide. OpenSSL 3.5.0 (8 April 2025) added ML-KEM, ML-DSA and SLH-DSA and changed "the default TLS keyshares ... to offer X25519MLKEM768 and X25519". To check whether a server negotiates it:

# OpenSSL 3.5 or later
openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i -E "group|temp key"

---

Where ML-KEM Keys Live: Ephemeral vs Static

The first decision is which keys need management at all.

For static keys, SP 800-227 sets the baseline: private data (seeds and decapsulation keys) "needs to be stored within the cryptographic module in a manner that is secure against both leakage and unauthorized modification", and import and export "needs to be performed in a secure manner". In practice: generate inside the KMS or HSM, keep dk non-exportable unless backup requires a wrapped export, and expose only Decaps to applications.

---

The ML-KEM Key Lifecycle

Use this table as a starting point for a static ML-KEM key policy. Ephemeral TLS keys need only the generation and destruction rows, and those are handled by the TLS library.

If you need a portable key file for testing, OpenSSL 3.5 shows the seed choice directly. By default it keeps the seed; this command writes only the FIPS 203 dk:

openssl genpkey -provparam ml-kem.retain_seed=no -algorithm ml-kem-768 -out priv-only.pem

Use such software keys for testing only.

---

Deadlines: NIST IR 8547 and CNSA 2.0

NIST IR 8547. NIST's Transition to Post-Quantum Cryptography Standards is still an initial public draft (published 12 November 2024; comments closed 10 January 2025). For key establishment it proposes that finite-field DH/MQV, elliptic-curve DH/MQV and RSA key establishment at 112 bits of security be deprecated after 2030, and that these algorithms at 112 bits and 128 bits or more be disallowed after 2035. As a draft, these dates show NIST's direction rather than final rules.

CNSA 2.0. National security systems in the US follow NSA's CNSA 2.0 suite. An NSA-authored IETF Internet-Draft profiling TLS for CNSA 2.0 (draft-becker-cnsa2-tls-profile) states that "CNSA 2.0 requires the use of ML-KEM-1024 for key establishment in TLS". The NSA's CNSA 2.0 FAQ lists ML-KEM-1024 "for all classification levels". CNSA 2.0 algorithms are required in new national security system acquisitions from 1 January 2027 and mandated by 31 December 2031; see the CNSA 2.0 timeline. How these dates interact with the civilian federal timeline is covered in our US post-quantum regulation guide covering NIST, OMB and CNSA 2.0.

---

PQC Key Management: Beyond ML-KEM

PQC key management applies key lifecycle controls (generation, storage, distribution, rotation, backup, destruction and audit) to post-quantum keys and to the key hierarchy that protects them. ML-KEM is one part of it. A complete post-quantum key management policy also covers signature keys and the keys at the top of your hierarchy.

The three NIST post-quantum key types

Sizes are from FIPS 203, FIPS 204 (Table 2, ML-DSA-44/65/87) and FIPS 205. Stateful hash-based signatures (LMS and XMSS, NIST SP 800-208) add one more rule: the signer must never reuse a one-time key, so state must be backed up and synchronised with great care. Symmetric keys are not the problem: AES-256 stays acceptable, and CNSA 2.0 requires it.

Start at the root of the key hierarchy

A post-quantum leaf key protected by a classical parent is only as strong as that parent. If an RSA key wraps your key-encryption keys, or a key is exported under RSA-OAEP, a recorded copy of that exchange is exposed to "harvest now, decrypt later" even if every data key below it is quantum-safe. In practice:

• Symmetric key hierarchies (AES-256 master keys and KEKs inside an HSM) do not need a new algorithm. Check how keys enter and leave the hierarchy instead.
• Asymmetric wrapping and transport (RSA key transport, ECDH-based wrapping, BYOK imports) should move to ML-KEM or to symmetric key wrapping on a dated plan.
• Root and issuing CA keys move to ML-DSA or SLH-DSA first in your signature plan, because every certificate below them inherits their algorithm. See the ML-DSA certificates and post-quantum PKI guide.

What to ask your KMS and HSM vendors

Post-quantum key management fails in practice where a key store cannot hold the new objects. For each HSM, cloud KMS and secrets manager, ask for dated answers on:

1. Key generation for ML-KEM, ML-DSA and SLH-DSA inside the module, and the parameter sets supported.
2. API support: PKCS#11 3.2 mechanisms, KMIP, or the vendor's own API, including encapsulate and decapsulate for ML-KEM.
3. Export and backup formats (seed or expanded key, IETF LAMPS encodings) and whether a backup can be restored into another vendor's module.
4. Validation status (FIPS 140-3 certificates that list the post-quantum algorithms).
5. Hybrid support: whether the store can hold a classical and a post-quantum key under one policy during the transition.

Keep the answers in your cryptographic inventory so the PQC migration roadmap can schedule each key store.

---

How to Plan Your ML-KEM Migration

1. Inventory first. Find where RSA and ECDH key establishment happens: TLS endpoints, VPNs, key-wrapping keys, KMS and HSM keys, code. Start with a cryptographic inventory and keep it as a CBOM (cryptography bill of materials).
2. Split ephemeral from static. Ephemeral TLS and VPN key exchange is an upgrade project (libraries, load balancers, middleboxes that must handle larger handshakes). Static KEM keys are a key management project.
3. Turn on hybrid where you can. Enable X25519MLKEM768 on endpoints you control and measure how often it is negotiated. Certificates stay as they are.
4. Check your key stores. Ask each HSM, KMS and secrets manager vendor for dated support of ML-KEM key objects, encapsulate/decapsulate operations, seed vs dk storage and wrapped export.
5. Write the policy. Parameter set, storage format, cryptoperiod, backup format, destruction, and who may decapsulate. Use the lifecycle table above.
6. Make the algorithm a policy decision. Hard-coded algorithms make every change a release; a crypto-agility platform moves that choice to central policy.
7. Measure continuously. Cryptographic posture management keeps the inventory current and tracks remediation; a PQC migration roadmap ties this to dates and owners.

---

How DuoKey Fits

DuoKey addresses the inventory and policy steps above. According to DuoKey's documentation:

• Discovery. DuoKey's PQC Scanner, the discovery engine of DuoKey CPM, finds certificates and keys on filesystems, keystores and cloud KMS (AWS, Azure, GCP), and its Domain Scanner can detect post-quantum key exchange. It flags RSA and ECDSA as quantum-vulnerable, lists ML-KEM as informational, and produces a CBOM and a Quantum Readiness Score. You can start with the free Quantum Readiness Score, which needs no access to internal systems.
• Policy instead of hard-coded algorithms. With the Crypto Agility Plane (CAP), developers declare a data class and a purpose rather than an algorithm. A central tenant policy resolves the algorithm, post-quantum posture (classical, hybrid or pqc_only), key reference and backend at runtime. The hybrid posture with ML-KEM and ML-DSA is available out of the box. Moving to PQC-only is a policy edit; application code does not change.
• Keys stay in your backends. CAP holds no key material. It reaches backends through PKCS#11 and KMIP, including Securosys HSMs, Azure Key Vault, AWS KMS, Google Cloud KMS, HashiCorp Vault and OpenBao. MPC is an optional vault backend for threshold key custody, where no single host holds a complete key. Which backends hold ML-KEM keys natively depends on each backend's own support.
• One console and audit trail. DuoKey Cockpit provides RBAC and ABAC, tenant isolation and a cryptographically chained audit log.
• Post-quantum keys in the vault. Post-quantum and hybrid keys are generated and used inside a vault that supports them (the DuoKey Software Vault or a Securosys HSM). Cockpit exports ML-KEM, ML-DSA and SLH-DSA private keys in the IETF LAMPS encodings that OpenSSL 3.5 reads, which keeps backups portable.

CAP runs on DuoKey Cockpit today through a REST API and Java/Spring Boot and .NET/EF Core reference clients; packaged SDKs are on the roadmap. For anything not listed here, such as a specific HSM model's ML-KEM support, contact DuoKey.

---

FAQ

Q: What is ML-KEM key management?

It is the set of controls for generating, storing, distributing, rotating, backing up and destroying ML-KEM keys, the post-quantum KEM keys defined in FIPS 203. Ephemeral keys used in hybrid TLS need only correct configuration; static keys need full lifecycle management in a KMS or HSM, including protection of the 64-byte seed.

Q: What is PQC key management?

PQC key management is the lifecycle management of post-quantum keys (ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures) and of the key hierarchy above them. It covers where keys are generated and stored, which formats are backed up, how classical wrapping keys are replaced, and which KMS and HSM products support the new algorithms. See PQC Key Management: Beyond ML-KEM.

Q: What is ML-KEM?

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the post-quantum key-encapsulation mechanism standardized by NIST in FIPS 203 on 13 August 2024. Two parties use it to agree on a 32-byte shared secret over a public channel. It comes in three parameter sets, ML-KEM-512, -768 and -1024, with ML-KEM-768 as NIST's recommended default.

Q: Is ML-KEM the same as Kyber?

ML-KEM is the standardized version of CRYSTALS-Kyber, but the two are not identical: the algorithm was adjusted before FIPS 203 was published. Pre-standard Kyber implementations do not interoperate with ML-KEM.

Q: Is ML-KEM approved for CNSA 2.0?

Yes, at the ML-KEM-1024 parameter set, which the NSA requires for all classification levels in national security systems. ML-KEM-512 and ML-KEM-768 are NIST-approved but are not the CNSA 2.0 choice.

Q: Is ML-KEM a replacement for RSA?

Partly. ML-KEM replaces RSA (and ECDH) for key establishment: key transport and key agreement. It does not replace RSA signatures; for those, NIST standardized ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). During the transition, ML-KEM is usually combined with X25519 or ECDH in a hybrid.

Q: What is X25519MLKEM768?

A hybrid TLS 1.3 key-exchange group that combines ML-KEM-768 with X25519, standardized in RFC 10024 with code point 0x11EC. The client share is 1,216 bytes, the server share 1,120 bytes, and the combined shared secret 64 bytes. OpenSSL 3.5 offers it by default.

Q: Can an HSM store ML-KEM keys?

It depends on the HSM and its firmware. The PKCS#11 3.2 standard (OASIS Standard, June 2026) defines ML-KEM key objects (CKK_ML_KEM), a key-pair generation mechanism (CKM_ML_KEM_KEY_PAIR_GEN), C_EncapsulateKey and C_DecapsulateKey, and attributes for both the seed (CKA_SEED) and the decapsulation key (CKA_VALUE). Whether a given HSM implements them, and with which validation status, is a question for its vendor.

Q: Should I store the ML-KEM seed or the decapsulation key?

Either is allowed. FIPS 203 permits storing the 64-byte seed and re-deriving the key pair, as long as the seed gets the same safeguards as the decapsulation key. Choose one canonical format per system, and make sure your backup format can be imported where you would restore it.

Q: Which ML-KEM parameter set should I use?

NIST recommends ML-KEM-768 as the default and advises the strongest parameter set that is practical. Use ML-KEM-1024 where CNSA 2.0 applies or your policy requires security category 5.

Q: Do I need new certificates to use ML-KEM in TLS?

Not for hybrid key exchange. X25519MLKEM768 changes the key exchange, not authentication, so your existing RSA or ECDSA certificates keep working. Certificates change when you migrate signatures to ML-DSA.

---

Conclusion: ML-KEM Key Management Checklist

ML-KEM changes less about key management than its key sizes suggest, as long as you separate the two cases. Ephemeral keys in hybrid TLS are a configuration task you can start this quarter. Static keys need a policy that covers the seed, the KEM interface and proof of possession.

• An inventory shows where RSA and ECDH key establishment is used
• X25519MLKEM768 is enabled and monitored on endpoints you control
• Static ML-KEM use cases are listed, each with an owner
• Each KMS and HSM has dated support for ML-KEM keys and encapsulate/decapsulate
• The policy states parameter set, storage format (seed, dk, or both), cryptoperiod, backup and destruction
• Seeds are protected with the same controls as decapsulation keys
• Algorithm choice is controlled by policy, not hard-coded in applications
• Migration dates follow NIST IR 8547 and, where relevant, CNSA 2.0

---

References

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST SP 800-227: Recommendations for Key-Encapsulation Mechanisms
• NSA: CNSA 2.0 and Quantum Computing FAQ (Ver. 2.2, October 2026, PDF)
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
• NIST SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes
• Cloud Security Alliance: Post-Quantum Key Management Starts at the Root
• NIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards
• RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3
• IETF Datatracker: draft-ietf-tls-ecdhe-mlkem
• OASIS PKCS #11 Specification Version 3.2
• IETF Internet-Draft: CNSA 2.0 TLS profile (draft-becker-cnsa2-tls-profile-05)
• OpenSSL 3.5 release notes
• OpenSSL 3.5: EVP_PKEY-ML-KEM
• DuoKey Docs: Crypto Agility Plane SDK
• DuoKey Docs: PQC Scanner
• DuoKey Docs: Key Export in Standard Formats