ML-KEM key reuse risks: is reusing a key pair safe?

ML-KEM key reuse is when one ML-KEM key pair (encapsulation key plus decapsulation key) gets used for more than one key establishment, across connections, sessions or rekeys, when it should be generated fresh each time. ML-KEM is the post-quantum KEM standardised in FIPS 203. It can survive reuse cryptographically, but reuse weakens forward secrecy, and current TLS and NIST guidance now forbid it for ephemeral keys.

This matters a lot for organisations that run OT and critical infrastructure. Site-to-site tunnels, edge-to-cloud links and remote access sessions often stay up for months. Traffic recorded today could be decrypted once a cryptographically relevant quantum computer exists. Below we cover what the standards say, why the IETF TLS Working Group tightened the rules, and how to check your own equipment.

Is it safe to reuse an ML-KEM key pair across multiple connections?

On the cryptography alone, mostly yes: ML-KEM was built to stay secure when a key pair is reused. As an operational practice for ephemeral key exchange, no. Reuse reduces forward secrecy, and both NIST SP 800-227 and the current TLS 1.3 specification require ephemeral keys to be used once.

The IETF draft that defines standalone ML-KEM for TLS 1.3 sets out both sides. It says ML-KEM is explicitly designed to be secure in the event that the keypair is reused, satisfying IND-CCA security via a variant of the Fujisaki-Okamoto (FO) transform. The same section adds that while it is recommended that implementations avoid reuse of ML-KEM keypairs to ensure forward secrecy, implementations that do reuse MUST ensure that the number of reuses abides by bounds in [FIPS203] or subsequent security analyses of ML-KEM.

One rule has no exceptions at all: Implementations MUST NOT reuse randomness in the generation of ML-KEM ciphertexts, it follows that ML-KEM ciphertexts also MUST NOT be reused. You may see a vendor argue that “ML-KEM is IND-CCA secure, so reuse is fine”. That statement is true about the algorithm. It says nothing about the forward secrecy of your traffic.

Why has TLS 1.3 changed key share reuse from SHOULD NOT to MUST NOT?

The original RFC 8446 discouraged reusing key shares but did not ban it. Its replacement, RFC 9846 (the result of draft-ietf-tls-rfc8446bis), turns that into a hard requirement. The reasons: reuse undermines forward secrecy, has caused real implementation weaknesses with classical groups, and conflicts with NIST’s definition of “ephemeral”.

What the IETF TLS Working Group documented

Earlier versions of draft-ietf-tls-mlkem described the old position plainly: TLS 1.3 does not prohibit key re-use; some implementations may use the same ephemeral public key for more than one key establishment at the cost of limited forward secrecy. That flexibility had a track record. In related work on deprecating old key exchanges, the working group noted that public key reuse, either via non-ephemeral cipher suites or reused keys with ephemeral cipher suites, can lead to timing side channels that may leak connection secrets. The same draft concluded that reusing ephemeral DHE keys invalidates forward secrecy properties of these connections.

The current text is unambiguous. RFC 9846 was published in July 2026 and obsoletes RFC 8446 and is the current specification of TLS 1.3. New post-quantum group drafts now point to it directly. One of them, by J. Preuß Mattsson and S. Ruohomaa, states: “An MLKEM1024X448 key share, or any of its components, MUST NOT be reused for multiple connections, as required by TLS 1.3 [RFC9846].”

How NIST SP 800-227 lines up

NIST took the same line independently. Requirement RS6 in NIST SP 800-227 says that 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 must be destroyed as soon as possible afterwards. Presenting the publication, Gorjan Alagić (UMD / NIST) summed up the new definitions as “”ephemeral” = use once, then destroy”. Anything else counts as static, and static keys come with baggage: must prove it belongs to you!

This settles an older grey area. The SP 800-227 initial public draft still allowed that a party might decide to use ekA for multiple connections but only for a brief period of time, which is typically still considered an ephemeral setting. The final version separates the two cases strictly.

How does reusing ML-KEM keys affect forward secrecy against harvest now, decrypt later?

Reuse ties every session that used the key pair to one decapsulation key. If that key leaks, all of those recorded sessions can be decrypted together. The window of exposure is however long the key pair lived, not a single handshake.

Forward secrecy is exactly the property that defeats harvest-now-decrypt-later. In the IETF’s words, it protects against adversaries who record encrypted conversations in the hope of decrypting them later. In a hybrid key exchange, the classical part gives no protection against a future quantum adversary, so the ML-KEM part carries all of the post-quantum forward secrecy. The working group recommends the hybrid approach. It moved the hybrid X25519MLKEM768 group to recommended status, and the shepherd writeup notes that this clearly indicates that hybrid approach is recommended over the pure approach by the working group. Hybrid does not, however, make a reused ML-KEM key harmless.

Long-lived OT links have a further problem. A TLS key update during a session does not establish new forward-secret key material. While this is generally not an issue for short-lived sessions, it can pose a security risk for long-lived connections, such as those in industrial IoT or telecommunication networks. What counts is how often a full key exchange with fresh key pairs happens, not how often traffic keys are derived again.

Do encryption gateways reuse ML-KEM keys to save CPU on low-power hardware?

Some implementations have historically cached ephemeral keys to save computation, and ML-KEM is no different in principle. For ML-KEM, though, the CPU argument is weak, and the reuse breaks current standards.

Key caching was a known optimisation in the classical era. That is why the old TLS text had to acknowledge implementations that reused ephemeral keys. For ML-KEM the saving is small: key generation is a fast lattice operation, not a costly exponentiation. A TLS Working Group presentation at IETF 116 observed that modern ephemeral key exchange algorithms like x25519 are very fast and have small message overhead. Kyber is even faster. On constrained OT hardware, the larger message size of ML-KEM is usually a bigger factor than the CPU cost of generating a key.

So when you evaluate a gateway, ask the vendor directly whether keys are cached, and for how long. If the answer cites CPU savings, the relevant question is how much recorded traffic a single key protects. One example of a design that limits that window: Quantum Network’s Quantum Gateway uses a hybrid key agreement with ML-KEM as the post-quantum part, and both the classical and post-quantum handshakes renew every two minutes. Whatever product you use, the vendor should be able to document its rekey interval and its key-generation behaviour separately.

How can I check whether a gateway or VPN generates fresh ML-KEM keys for each handshake?

Capture several handshakes, force rekeys, and compare the public key material: a fresh encapsulation key every time is the minimum you should accept. Then back the capture up with documentation and reboot tests, because packet captures cannot show what happens to private keys.

For TLS-based connections

In TLS 1.3, the client generates an ML-KEM encapsulation/decapsulation key pair (pk, sk) and sends the encapsulation key pk in the key_share extension of the ClientHello. The server runs Encaps with pk to produce a ciphertext ct and a shared secret. A practical test:

• Capture at least ten consecutive handshakes on a mirror port or tap. On an air-gapped segment you can do this entirely offline.
• Extract the key_share value for the negotiated hybrid or ML-KEM group from each ClientHello and ServerHello. Hash each value and compare the hashes.
• Any repeated client encapsulation key means key pair reuse. Any repeated server ciphertext means a fault that the standards prohibit outright.
• Run the test again after a restart and under heavy load. Caching sometimes only kicks in when connection rates are high.

For Layer 3 gateways and non-TLS tunnels

Many site-to-site gateways do not use TLS, and their handshake formats may be proprietary. In that case, look at how the key-exchange payloads are carried during the rekey interval. If the post-quantum public values sit in identifiable fields, check them for repetition in the same way. If they are encapsulated, ask for a test mode or log output that records a fingerprint of each generated encapsulation key.

Questions to put to the vendor in writing

• Is a new ML-KEM key pair generated for every handshake and every rekey, or only on a timer?
• Are decapsulation keys ever written to persistent storage or kept across reboots?
• Are private keys destroyed straight after decapsulation, as NIST SP 800-227 RS6 requires?
• Which FIPS 203 parameter set is used, and can the post-quantum algorithm be changed later?

What are the key dates and figures for ML-KEM key handling?

The rules on single-use ML-KEM keys took final shape between 2025 and 2026. The figures below are the reference points to use when you write procurement requirements.

NIST SP 800-227 says an ephemeral 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. For organisations protecting links between sites, clouds and remote users, that sentence works as the test for any gateway or VPN. ML-KEM can tolerate reuse, but forward secrecy against harvest-now-decrypt-later only holds if each key is used once and then destroyed.