X25519Kyber768Draft00 to X25519MLKEM768 migration guide

The X25519Kyber768Draft00 to X25519MLKEM768 migration replaces a pre-standard hybrid key exchange with its standardised successor. The old group pairs X25519 with a draft version of Kyber768 under TLS codepoint 0x6399. The new one pairs X25519 with ML-KEM-768 from FIPS 203 under codepoint 0x11EC, as defined in RFC 10024. The two cannot negotiate with each other.

Many organisations running OT and critical infrastructure turned on early post-quantum hybrids in 2023 and 2024 to protect long-lived data against “harvest now, decrypt later” collection. Those early settings now sit in gateways, jump hosts, cloud load balancers and remote-access clients. The draft group has been formally obsoleted, so the task is to retire it without creating a gap in protection.

What is the difference between X25519Kyber768Draft00 and X25519MLKEM768?

Both combine X25519 with a 768-level lattice KEM. They differ in which version of the algorithm they use, which codepoint they carry, the order in which the two parts are encoded, and their standing in the IANA registry.

X25519Kyber768Draft00 uses Kyber768 as submitted in Round 3 of the NIST competition. The IETF hybrid design draft specifies the FIPS 202 variant of that submission, built on SHA-3 and SHAKE. FIPS 203, published on 13 August 2024, standardised a modified algorithm called ML-KEM. NIST lists every change from CRYSTALS-KYBER in Appendix C. These changes affect how the shared secret is computed, so a draft Kyber implementation and an ML-KEM implementation produce different keys from the same inputs.

The byte sizes are almost the same, so packet captures and MTU behaviour hardly change:

• X25519MLKEM768 client share: 1216 bytes, of which 1184 are the ML-KEM-768 encapsulation key and 32 are X25519 (IETF RFC 10024, August 2026).
• X25519Kyber768Draft00 server share: 1120 bytes, made up of a 32-byte X25519 share and a 1088-byte Kyber ciphertext (IETF draft-tls-westerbaan-xyber768d00-02, 2023).

Is pre-standard Kyber still secure to use in a VPN or TLS connection?

A hybrid connection on the draft group is still at least as strong as plain X25519, because the session key holds as long as either part is unbroken. The Kyber draft itself, however, is a dead end: it is obsoleted, unvalidated and increasingly unsupported.

The hybrid structure is the safety net. NIST’s Dustin Moody summarised the purpose of hybrid schemes as follows: they “Reduces risks from uncertainty if either is broken.” Even if the draft Kyber component were weakened, the X25519 part would still protect the session against classical attackers.

The bigger risks are operational. The pre-standard code paths no longer get attention from maintainers. Test results do not carry over either: one recent reproducibility study points out that a result for a Kyber candidate revision is not automatically a result for final FIPS 203 ML-KEM. For a VPN that protects SCADA traffic or historian replication with a ten-year confidentiality requirement, the protocol is not the main exposure. The exposure is the endpoint that stops offering the draft group after a firmware update and quietly falls back to classical-only key exchange.

Can Kyber draft and final ML-KEM peers interoperate during a migration?

No. The two groups have different codepoints and different internal algorithms, so a post-quantum key exchange only happens when both peers share at least one of the two groups. What actually happens depends on what each side offers in its supported_groups and key_share extensions.

In TLS 1.3 the client lists every group it accepts in supported_groups, but sends actual key material (key_share) for only one or two of them. That gives three typical outcomes:

• Overlap with a key share: the server selects the shared hybrid group and the handshake completes in one round trip.
• Overlap without a key share: the server sends a HelloRetryRequest, and the client resends with the right key share. This adds a full round trip, which matters on satellite, cellular or radio links to remote substations.
• No hybrid overlap: both sides settle on X25519 or P-256. The connection works, nothing logs an error, and the post-quantum protection is gone.

NIST SP 1800-38C was written for exactly this kind of problem: finding and fixing compatibility issues between quantum-ready implementations in a controlled, non-production environment before they reach the field. NIST’s NCCoE Migration to PQC project grew from 14 collaborators at its July 2022 kickoff to more than 50 by September 2025 (NIST NCCoE, 2025). That growth gives an idea of how much interoperability work this change requires across the ecosystem.

How do I find devices that still negotiate the obsolete Kyber draft codepoints?

Look for 0x6399 and 0x639A in TLS ClientHello and ServerHello messages, using passive capture first and active probing second. In OT networks, passive methods should come first.

Passive discovery

Capture handshakes on SPAN or TAP ports at zone boundaries, such as the IT/OT DMZ, cloud egress points and the remote-access concentrator. The supported_groups and key_share extensions are not encrypted in TLS 1.3, so any packet analyser can filter on the group values. Record four things for each flow: the groups the client offers, the group in its key share, the group the server selects, and whether a HelloRetryRequest occurred. A ClientHello of about 1.2 KB or more that spans two TCP segments is a good sign that a hybrid is being offered.

Active probing

For servers and gateways under your control, send a ClientHello that offers only 0x6399. If the server accepts it, it still supports the draft. Repeat with only 0x11EC to confirm it is ready for ML-KEM. Run these probes in maintenance windows, and avoid controllers and embedded devices whose TLS stacks may react badly to unexpected input.

Logs and configuration review

Many TLS terminators can log the negotiated group, so turn that on before you change anything. Then review configuration files and policy templates for named group lists that contain “Kyber” or “Draft00”. NIST SP 1800-38B, the cryptographic discovery volume of the same NCCoE series, describes how to turn such findings into a prioritised inventory.

Non-TLS tunnels

IKEv2 and other VPN protocols that trialled Kyber before FIPS 203 often used private or pre-standard identifiers. These do not appear as TLS codepoints at all. Inventory them separately, by checking firmware versions and exported tunnel policies against vendor documentation.

Does the pre-standard Kyber key exchange count as quantum-safe for compliance?

In most compliance contexts, no. Frameworks that refer to NIST standards refer to ML-KEM as specified in FIPS 203, and draft Kyber is not FIPS 203.

RFC 10024 makes the distinction concrete: for X25519MLKEM768 in FIPS-oriented deployments, the ML-KEM component is the part that must be a certified implementation. No validation path exists for a Round 3 Kyber implementation. Even a correct FIPS 203 implementation is not automatically sufficient, as NIST notes in the standard itself: “conformance to this standard does not ensure that a particular implementation is secure.”

The deadlines that drive this work come from the classical side:

• NIST proposed timeline: quantum-vulnerable algorithms at 112-bit security strength are deprecated after 2030, and quantum-vulnerable algorithms are disallowed after 2035 (NIST, Dustin Moody, March 2025).

An auditor reviewing a 2026 inventory will treat 0x6399 as an obsolete experimental setting, not as evidence of post-quantum readiness. Record it as a finding with a remediation date.

How do I remove deprecated hybrid groups from gateway and client configurations without breaking connections?

Change servers before clients, accept both groups for a limited period, and only remove the draft once your telemetry shows no remaining 0x6399 negotiations. Doing this in reverse order produces silent classical fallbacks.

Some practical details matter in OT settings. Remote clients on vendor laptops often update on their own schedule, so leave phase 2 running long enough to cover a full patch cycle. In phase 3, also list the MLKEM group in the client’s key share, not only in supported_groups. Otherwise every connection pays for a HelloRetryRequest. Phase 5 works only where you control both ends, such as site-to-site tunnels and links between your own data centre and your cloud tenancy. On internet-facing services, forcing a hybrid group would lock out legitimate classical clients.

Links between sites and cloud environments can also be moved off the TLS layer entirely. For example, Quantum Network’s QPN gateway sits at each end of a connection and encrypts at Layer 3 using a hybrid key agreement whose post-quantum part is ML-KEM per FIPS 203. Both handshakes are renewed every two minutes, and the post-quantum algorithm can be changed if necessary. The same rules apply to this kind of design: keep an inventory of which algorithm each tunnel actually runs, and plan the next algorithm change before you need it.