Read this first
ML-KEM (FIPS 203) replaces the way two parties agree on a secret key — RSA key transport and (EC)DH agreement — with a key-encapsulation mechanism. It does not touch signatures; RSA and ECDSA signatures are a separate migration to ML-DSA/SLH-DSA. Key exchange lives in far more places than TLS, the messages get bigger, and most deployments adopt a hybrid rather than pure ML-KEM. Find every instance first, then stage the change protocol by protocol.
Almost every secure channel starts by establishing a shared symmetric key over an insecure medium, and until now that step relied on RSA key transport or Diffie-Hellman agreement over finite fields or elliptic curves. Both are broken by a cryptographically-relevant quantum computer, which is why they are the first thing to move — and why data protected by them today is already exposed to harvest-now-decrypt-later. ML-KEM is the NIST-standardized replacement. Migrating to it is conceptually simple and operationally broad: the algorithm swap is well-defined, but the number of places key exchange hides is what makes this a program rather than a patch.
Where classical key exchange actually lives
TLS is the obvious front door — and often the easiest, because the ecosystem has moved fastest there (see migrating TLS to hybrid). But classical key establishment is embedded across the estate, and each surface migrates on its own timeline with its own tooling:
- **Transport protocols** — TLS, SSH, and IPsec/IKEv2 in VPNs each negotiate a fresh shared secret per session using (EC)DH.
- **Messaging and email** — S/MIME and secure messaging apps (X3DH-style handshakes) establish per-recipient or per-session keys asymmetrically.
- **Data at rest** — envelope encryption wraps a data key under a key-encrypting key; that wrapping is frequently RSA key transport.
- **Tokens and bespoke protocols** — JOSE/COSE key agreement and in-house application handshakes reinvent key exchange, often invisibly.
You will not find these by inspecting the obvious services. A cryptographic inventory is what turns "we use RSA and ECDH somewhere" into an enumerated, prioritized list of migration surfaces.
What changes when you move to a KEM
The interaction pattern shifts to encapsulate-and-decapsulate: the initiator encapsulates a fresh shared secret to the peer's public (encapsulation) key and sends the resulting ciphertext; the peer decapsulates it with its private key to recover the same secret. This replaces both RSA key transport and the (EC)DH round-trip. The mechanics are familiar; the sizes are not.
- **Messages grow.** ML-KEM-768 uses a 1184-byte encapsulation key and a 1088-byte ciphertext, versus 32–384 bytes for a classical public value. The derived shared secret is 32 bytes.
- **Framing and buffers must be revisited.** Protocol fields, MTU assumptions, record sizes, and storage columns sized for small classical values will silently truncate or fragment larger KEM material.
- **Performance profile flips.** ML-KEM operations are fast, but the bytes on the wire dominate — latency effects show up in round-trips and fragmentation, not CPU.
ML-KEM replaces key exchange only — not your signatures
The most common scoping error is folding certificate and code-signing changes into a KEM migration. ML-KEM does not sign anything. RSA and ECDSA signatures migrate separately to ML-DSA (FIPS 204) or SLH-DSA. Conflating the two produces a plan that is wrong on both timeline and testing. Keep the key-exchange migration and the signature migration on distinct tracks.
Hybrid or pure, and how to stage it
Most deployments use a hybrid — a classical exchange concatenated with ML-KEM, such as X25519MLKEM768 — so the session stays secure if the classical part or the young post-quantum part is later found weak, while immediately defeating harvest-now-decrypt-later. Pure ML-KEM is chosen where a profile mandates it, for example CNSA 2.0 for US national security systems. Default to hybrid unless a requirement says otherwise.
The inventory defines scope, not the obvious front door
A recurring failure mode: teams migrate TLS, announce they are "quantum-safe," and leave SSH, IPsec VPNs, S/MIME, and at-rest envelope keys on classical crypto for years. The real scope is whatever the cryptographic inventory enumerates — not the one protocol that had the easiest library support.
Stage the work so each protocol moves safely and reversibly, slotting into the broader migration roadmap:
- **Inventory** every place key exchange happens, down to library and protocol version.
- **Prioritize** by exposure and data shelf life — long-lived confidential data behind internet-facing key exchange goes first.
- **Enable hybrid** wherever the protocol and peers support it, keeping a classical fallback path.
- **Interoperability-test** against the actual peers you talk to, not just a reference implementation.
- **Monitor** handshake success rates and latency in production, and keep the fallback until confidence is established.
How quantakrypto helps
We run the cryptographic inventory that finds every RSA and (EC)DH key exchange across TLS, SSH, VPNs, email, messaging, and data at rest; we sequence and execute the migration to hybrid or pure ML-KEM protocol by protocol with fallback and interoperability testing; and we validate conformance and train your teams (certification) so the KEM pattern and the signature migration stay correctly separated. Start with the inventory — it, not the obvious front door, defines the real scope of the work.