FIPS 203 defines three parameter sets for ML-KEM. The choice between them carries real implications for performance, security margin, and integration architecture. This article works through what each set provides, where the actual performance cost sits (not where architects typically assume it sits), and which set belongs in which deployment context. It closes with the integration architecture point that generates the most confusion in enterprise deployments: ML-KEM handles key exchange, not authentication. They are separate migration tracks.

The three ML-KEM parameter sets: what they are and what they provide

NIST FIPS 203 (August 2024) specifies ML-KEM in three parameter sets, each mapped to a NIST security level:

ML-KEM-512 is security level 1, equivalent in attack cost to exhausting an AES-128 key. Public key: 800 bytes. Ciphertext: 768 bytes. Shared secret: 32 bytes.

ML-KEM-768 is security level 3, equivalent in attack cost to exhausting an AES-192 key. Public key: 1,184 bytes. Ciphertext: 1,088 bytes. Shared secret: 32 bytes.

ML-KEM-1024 is security level 5, equivalent in attack cost to exhausting an AES-256 key. Public key: 1,568 bytes. Ciphertext: 1,568 bytes. Shared secret: 32 bytes.

For comparison, an X25519 Diffie-Hellman public key is 32 bytes. A P-256 public key is 64 bytes uncompressed. The sizes above are not small. The shared secret output, 32 bytes regardless of parameter set, feeds into a standard key derivation function to produce the symmetric session key, consistent with the TLS 1.3 key schedule design.

ML-KEM is an IND-CCA2 secure key encapsulation mechanism: it is secure against adaptive chosen-ciphertext attack, which is the appropriate security property for a KEM used in TLS key exchange. The security proof for the underlying CRYSTALS-Kyber construction (as ML-KEM was known before standardisation) is given in Bos et al. 2018, with follow-on analysis published throughout the NIST evaluation period.

Benchmark performance: CPU cost, bandwidth overhead, and hardware constraints

Here is where the counterintuitive result sits: ML-KEM is computationally faster than X25519 for key operations. The CRYSTALS-Kyber reference implementation benchmarks, published at pq-crystals.org, show key generation, encapsulation, and decapsulation times on the order of tens of microseconds on modern x86-64 hardware without AVX2 optimisation. X25519 completes in approximately 150 to 200 microseconds on comparable hardware. With AVX2 (standard on server-class CPUs), ML-KEM times roughly halve. CPU load is not the deployment concern for ML-KEM. Bandwidth is.

An ML-KEM-768 hybrid TLS 1.3 handshake, X25519 plus ML-KEM-768, the configuration deployed by Cloudflare and Google Chrome, transmits both the ML-KEM-768 public key (1,184 bytes) and the ciphertext (1,088 bytes). The handshake overhead versus a pure X25519 handshake is approximately 2.27 KB. For most enterprise and web applications, this is negligible in the context of a TLS handshake that already transmits certificates. For high-frequency low-latency environments, financial trading infrastructure, real-time communications systems making thousands of connections per second, it warrants a load test before production deployment.

QUIC (HTTP/3) introduces a specific constraint. The QUIC Initial packet has a default size limit of 1,200 bytes before address validation (per IETF RFC 9000). ML-KEM-1024's public key is 1,568 bytes, it does not fit in a single QUIC Initial packet without fragmentation or limit adjustment. ML-KEM-768 (1,184 bytes) fits within the limit. This is a practical reason why ML-KEM-768 is the parameter set commonly chosen for QUIC deployments, independent of the security margin argument.

On hardware security modules and embedded devices, the picture is more constrained. Kannwischer et al. (2019) benchmarked ML-KEM on ARM Cortex-M4 class microcontrollers. ML-KEM-512 requires roughly 1 to 2 milliseconds for key generation on that class of device, viable for TLS-like protocols. ML-KEM-1024 takes roughly 3 to 5 milliseconds. More significant: not all current FIPS 140-3 validated HSMs support ML-KEM natively. [ASSUMED, verify HSM ML-KEM support status against current firmware announcements from Thales Luna, Entrust nShield, Utimaco, and AWS CloudHSM before finalising this claim; HSM support evolves rapidly as firmware updates are released.] Architects planning HSM-dependent deployments should confirm firmware roadmaps with their HSM vendor before setting deployment timelines.

Which parameter set to use: the decision framework

NSA CNSA 2.0 (September 2022) mandates ML-KEM-1024 for US National Security Systems. The NSA's choice of security level 5 reflects the requirement for the highest available security margin in NSS contexts. Commercial organisations are not bound by CNSA 2.0 parameter requirements. NIST FIPS 203 explicitly supports all three parameter sets for non-NSS deployment.

The decision table for most enterprise deployments:

Use case Recommended parameter set Rationale
General enterprise TLS (web, API, VPN) ML-KEM-768 Security level 3, manageable handshake overhead, IETF X-Wing standard (RFC 9496)
NSS and equivalent high-assurance systems ML-KEM-1024 CNSA 2.0 mandated for NSS; maximum security margin for highest-assurance contexts
Constrained IoT and embedded devices ML-KEM-512 Operationally viable; review if data confidentiality lifetime exceeds 15 years
CA infrastructure and HSM key exchange ML-KEM-1024 Root of trust contexts, maximum security margin is justified regardless of NSS obligation

ML-KEM-768 is the correct default for general enterprise deployment. Security level 3 provides a security margin with no known quantum or classical attack approaching it, and the X-Wing hybrid construct standardised in IETF RFC 9496 specifies X25519 plus ML-KEM-768 as the combination. ML-KEM-512 is appropriate for constrained environments but should not protect data with a confidentiality requirement extending beyond approximately 2040, given the narrower security margin of level 1.

The "NSA said ML-KEM-1024" query comes up regularly. The NSA said ML-KEM-1024 for National Security Systems. It is not a recommendation for commercial enterprise use. The performance and bandwidth cost of ML-KEM-1024 over ML-KEM-768 is rarely justified outside the contexts in the table above.

Where ML-KEM fits in the TLS and IPsec stack

This is the architectural clarification that matters most for enterprise architects planning their deployment sequence.

ML-KEM replaces the ephemeral key exchange in TLS 1.3, not the certificate authentication. In a TLS 1.3 handshake, two distinct cryptographic operations occur: the ephemeral key exchange (which establishes the session key) and the certificate-based authentication (which verifies the server's identity). ML-KEM covers the first. The second still uses ECDSA or RSA signatures on the certificate, which are separately quantum-vulnerable and require migration to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). Deploying ML-KEM for key exchange provides HNDL protection immediately for data in transit. It does not provide quantum-resistant certificate authentication. That is a subsequent work stream.

In TLS 1.3, ML-KEM-768 is negotiated via the supported_groups extension using IANA codepoint 0x11EC for the X-Wing hybrid scheme (X25519 plus ML-KEM-768). [ASSUMED: verify the current IANA codepoint assignment for the X-Wing hybrid scheme against the IANA TLS Supported Groups Registry at https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml before relying on this specific value in implementation work; codepoint assignments can be updated.] The application layer, cipher suites for record-layer encryption (AES-GCM, ChaCha20-Poly1305), and certificate infrastructure are unaffected. The change is isolated to the key exchange component of the handshake. Architects who understand this separation avoid blocking the HNDL-protective ML-KEM deployment on the more complex certificate infrastructure migration that follows it.

For IPsec IKEv2, the relevant specification is IETF RFC 9370 ("Multiple Key Exchanges in IKEv2," 2023). ML-KEM-768 is supported as an additional key exchange method, combined with a classical DH group (such as DH group 19, P-256) within IKEv2 negotiations. The configuration approach mirrors the hybrid TLS model: classical security is maintained for backwards compatibility, and the ML-KEM component provides HNDL protection for traffic from the point of deployment.

Key encapsulation in both TLS and IKEv2 operates in ephemeral mode. A new ML-KEM key pair is generated per session. The ML-KEM private key is not persistent and does not accumulate over time. Forward secrecy is maintained. Architects should not conflate the ML-KEM ephemeral session key with the long-lived signing key on the certificate, they are distinct components with distinct migration requirements.

Library and toolchain support: what is available now

OpenSSL 3.5 includes ML-KEM support. [ASSUMED, verify that OpenSSL 3.5, released in 2025, explicitly supports NIST FIPS 203 ML-KEM rather than only the pre-standardisation Kyber variant; this distinction is material in FIPS-regulated environments where the FIPS 203 designation is required.] BoringSSL, used by Google Chrome, has supported X25519 plus ML-KEM-768 in production since 2023. LibreSSL, wolfSSL, and mbedTLS have post-quantum integration paths. Java supports ML-KEM through the Bouncy Castle provider and the NIST PQC reference implementations via the JCA architecture.

FIPS 140-3 validation is in progress for ML-KEM implementations. As of the knowledge cutoff for this article, implementations were beginning to receive NIST CMVP validation. Organisations in US federal contexts requiring FIPS 140-3 validated cryptographic modules should check the CMVP database at https://csrc.nist.gov/projects/cryptographic-module-validation-program for currently validated ML-KEM implementations before deploying in regulated environments.

Crypto agility is the architectural principle that makes iterative migration feasible. An application that hardcodes "ML-KEM-768" in its TLS configuration rather than delegating to a configurable cryptographic policy layer requires code changes if parameter set guidance changes. The NIST CSWP 04282021 crypto agility guidance (2021) recommends algorithm negotiation at the cryptographic service layer. Building crypto agility into new systems from deployment is less expensive than retrofitting it later.

Certificate authority infrastructure is not affected by ML-KEM deployment. Updating TLS key exchange to use ML-KEM does not require any change to existing PKI certificates, CAs, OCSP, or CRL infrastructure. Certificate signature migration to ML-DSA is a subsequent, independent work stream. Architects who understand this separation can deploy ML-KEM for HNDL protection without waiting for a more complex CA migration programme to complete.

A deployment sequence for enterprise architects

The sequence below reflects the dependency structure, not a timeline with specific years. The HNDL-protective steps are first because they are both the highest priority and the most operationally straightforward. HSM and embedded device migration are last because they have the longest lead times and the most constrained options.

  1. Inventory TLS endpoints and classify by parameter set requirement, data confidentiality lifetime, and QUIC vs TCP deployment context.
  2. Verify TLS library version and confirm ML-KEM availability. For OpenSSL deployments, confirm the version supports FIPS 203 ML-KEM specifically.
  3. Deploy X25519 plus ML-KEM-768 hybrid on external-facing TLS infrastructure first. This is the HNDL priority and the operational risk is well-characterised. The IETF RFC 9496 X-Wing construct is the standard; use it.
  4. Extend hybrid key exchange to internal east-west TLS on high-sensitivity data flows and VPN infrastructure (IKEv2 via RFC 9370).
  5. Address HSM and embedded device ML-KEM support on a separate track. Confirm firmware roadmaps with vendors. Schedule firmware updates around operational windows. This track runs in parallel, not sequentially after steps 3 and 4.
  6. Plan certificate signature migration to ML-DSA (FIPS 204) as a subsequent programme, beginning with root CA and intermediate CA replacement and working down to leaf certificates. This is not a prerequisite for ML-KEM deployment.

For the broader PQC migration context, certificate hierarchies, long-lifecycle signing infrastructure, and the PKI migration planning that follows ML-KEM deployment, see our analysis at PQC in PKI migration planning and the FIPS 203/204/205 implementation decision map.

Sources