How to check if connection uses ML-KEM (TLS and IKEv2)

To check whether a connection uses ML-KEM, you look at what the handshake actually negotiated, not at what the configuration says. In TLS 1.3 that means finding group codepoint 0x11EC (X25519MLKEM768) in the ServerHello. In IKEv2 it means finding Transform ID 36 (ML-KEM-768) in an Additional Key Exchange transform, followed by IKE_INTERMEDIATE messages.

This matters most where encrypted traffic crosses networks you don’t control: links between OT sites, connections into cloud environments, and remote engineers reaching control systems. Both TLS and IKEv2 negotiate the key exchange, so a peer that doesn’t support or doesn’t prefer ML-KEM can quietly bring the session down to classical elliptic-curve Diffie-Hellman. The session still works and still looks encrypted, so nobody notices.

Why verify the handshake instead of the configuration?

Configuration only shows what each side is willing to do. The handshake shows what happened. The stated reason for hybrid key exchange is the risk of traffic being recorded now and decrypted later. An IETF Internet-Draft on TLS key shares warns that “a TLS connection that negotiated a non-post quantum key share can be recorded decrypted in the future.”

Regulators and standards bodies have set dates for this transition:

• NIST IR 8547 (final, October 2026): US federal high value assets and high impact systems must adopt post-quantum cryptography for key establishment by December 31, 2030, and NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035.
• EU Coordinated Implementation Roadmap (June 2025): the European Commission states that “All Member States should start transitioning to PQC by the end of 2026”, with high-risk use cases moved by the end of 2030 at the latest.

NIST’s position is just as direct: “Organizations should begin applying these standards now to migrate their systems to quantum-resistant cryptography.”

What do the IANA codepoints for ML-KEM look like in the ClientHello and IKE_INTERMEDIATE messages?

In TLS, ML-KEM appears as a named group from the IANA TLS Supported Groups registry. In IKEv2, it appears as a Key Exchange Method Transform ID that is shared across the transform types in the IANA IKEv2 Transform Type registry. The tables below list the values you’ll actually see on the wire.

TLS 1.3 named groups (RFC 10024)

RFC 10024, published in August 2026, defines three hybrid key agreement mechanisms for TLS 1.3 - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. IANA has registered these in the TLS Supported Groups registry.

These codepoints show up in two ClientHello extensions: supported_groups (extension type 10) and key_share (extension type 51). For X25519MLKEM768, RFC 10024 gives this figure:

• Client share: 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519) (RFC 10024, 2026).
• Server share: 1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519) (draft-kwiatkowski-tls-ecdhe-mlkem-03, 2024).

There’s a byte-order detail that matters when you read raw hex. For X25519MLKEM768, the order of shares in the concatenation has been reversed, so the ML-KEM encapsulation key comes first and the 32-byte X25519 share comes last.

IKEv2 transforms (RFC 9370 and the ML-KEM draft)

RFC 9370 adds seven transform types. Additional Key Exchange 1 (ADDKE1) with IANA-assigned value 6 runs up to ADDKE7 at value 12. The allowed Transform IDs for these transform types are the same as the IDs for Transform Type 4, so they all share a single IANA registry for Transform IDs. ML-KEM-512, ML-KEM-768 and ML-KEM-1024 use IDs 35, 36 and 37.

For ML-KEM-768 in IKEv2, the Key Exchange payload data is 1184 octets from the initiator and 1088 octets from the responder (draft-ietf-ipsecme-ikev2-mlkem-00, April 2025).

How can I tell whether my TLS connection negotiated X25519MLKEM768 or fell back to classical ECDH?

Look at the key_share extension in the ServerHello. If it names 0x11EC and carries a 1120-byte share, the connection is hybrid. If it names 0x001D and carries a 32-byte share, the connection fell back to classical X25519. The TLS 1.3 ServerHello is sent in cleartext, so a passive capture is enough and you don’t need to decrypt anything.

Go through the handshake in this order:

1. ClientHello, supported_groups: is 0x11EC in the list at all? If it isn’t, the client never offered ML-KEM, so you have a client configuration problem, not a negotiation problem.
2. ClientHello, key_share: did the client send a 1216-byte share for 0x11EC up front, or only a 32-byte X25519 share?
3. HelloRetryRequest: if the client sent only X25519 but listed 0x11EC as supported, a server that prefers the hybrid group answers with a HelloRetryRequest naming 0x11EC. You’ll then see a second, larger ClientHello. That second ClientHello is a good sign.
4. ServerHello, key_share: this is the final answer. Check both the group and the length.
5. Protocol version: a connection that negotiates TLS 1.2 can’t use these groups at all. Treat any TLS 1.2 session on a path that should be quantum-safe as a fallback.

One OT-specific point: the hybrid ClientHello is more than 1,200 bytes and often spans more than one TCP segment. Older inspection devices or protocol-aware firewalls in plant networks sometimes handle that badly, which pushes clients back to a smaller, classical ClientHello. When ML-KEM disappears from one path only, check what sits in the middle of that path.

How do you confirm in a packet capture that IKEv2 used an ML-KEM additional key exchange?

Find the responder’s IKE_SA_INIT reply and check that it returns an ADDKE transform with ID 36 (or 35 or 37). Then check that one IKE_INTERMEDIATE exchange (type 43) per negotiated additional key exchange follows before IKE_AUTH. The first check is in cleartext. The second you confirm from the exchange types and message sizes.

Under RFC 9370, additional key exchanges negotiated via newly defined transforms MUST take place in a series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange. That means a correct capture on UDP 500 (or UDP 4500 after NAT detection) looks like this:

• IKE_SA_INIT request: the SAi1 proposal lists Transform Type 4 (for example ID 31) plus Transform Type 6 with ID 36, along with the INTERMEDIATE_EXCHANGE_SUPPORTED notification.
• IKE_SA_INIT response: SAr1 returns exactly one ADDKE1 transform. ID 36 means ML-KEM-768 was accepted. NONE means the peer declined it.
• IKE_INTERMEDIATE pair: exchange type 43 in both directions. The encrypted request has to be larger than the 1184-octet key it carries, and it may arrive as IKE fragments (RFC 7383), which is expected.
• IKE_AUTH: only after the IKE_INTERMEDIATE pair.

RFC 9370 spells out the failure mode: if the initiator includes NONE in all of the ADDKE Transform Types and the responder selects this value for all of them, then no IKE_INTERMEDIATE exchanges performing additional key exchanges will take place. A capture that goes straight from IKE_SA_INIT to IKE_AUTH has no post-quantum contribution.

To see method number 36 inside the KEi(1) payload itself, you have to decrypt the SK payload. Do this in a lab: export the IKE SA keys from a test gateway and load them into your protocol analyser. Also note that the draft cautions that IKE_SA_INIT messages using ML-KEM-768 or ML-KEM-1024 Key Exchange Method identifiers 36 and 37 respectively could exceed typical MTUs. That’s why ML-KEM normally appears as an additional key exchange rather than in Transform Type 4.

How can you continuously monitor for silent fallback to non-quantum-safe key exchange on site-to-site tunnels?

Make fallback a hard failure in policy, then alert on handshake metadata at every tunnel setup and every rekey. A one-off capture proves the state of one session. Continuous monitoring proves the state of every session after that.

Close the door in policy first

On IKEv2 responders, require ADDKE1 = ML-KEM and leave NONE out of the proposal. Then a peer that can’t do ML-KEM fails to connect, and the tunnel never comes up classical without anyone noticing. On TLS servers in front of cloud and remote-access services, offer only hybrid groups on paths that must be quantum-safe.

Then watch the signals

In OT networks you can collect these signals passively from a SPAN port or network tap at the site edge, so no agent is needed on the control systems. Add a scheduled synthetic probe that offers only the hybrid group to each TLS endpoint. That way a server-side configuration regression shows up within a day, not at the next audit.

Some purpose-built gateways don’t run standard IKEv2 or TLS for their tunnels. Quantum Network’s QPN, for example, combines a classical part and an ML-KEM part into one session key and renews both handshakes every two minutes. The gateway sends no telemetry, so for any gateway like this, ask which local handshake logs it provides for your own monitoring.

What evidence of hybrid post-quantum key exchange should be kept for auditors and regulators?

Keep evidence of what was negotiated, captured over time, alongside the policy that required it. Configuration screenshots show intent. Handshake records show the outcome.

• Policy baseline: the exported IKE proposals and TLS group lists for each site, cloud and remote-access path, kept under version control with change tickets.
• Negotiation records: for each session, a timestamp, peer identity, negotiated TLS group or IKEv2 KE and ADDKE transform IDs, and the exchange sequence. Hash and keep these records according to your retention policy.
• Reference captures: a small set of packet captures per path, taken at commissioning and after changes, with a checksum and a note on how they were taken.
• Key freshness: NIST SP 800-227 (final, September 2025) requires that 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. Comparing captured key_share or KE values across sessions shows they never repeat.
• Exception register: each fallback alert, its cause, its owner and when it was fixed. Auditors usually trust a well-kept exception log more than a clean dashboard.
• Algorithm references: map each negotiated identifier to FIPS 203, RFC 10024, RFC 9370 and RFC 9242, so a reviewer can trace each codepoint back to its standard.

How common is hybrid TLS in practice?

It helps to put your own measurements next to public baselines. A 2026 study of UK internet sectors found:

• Overall support: 1,788 of the 4,063 reachable HTTPS endpoints supported at least one evaluated post-quantum key-exchange group (arXiv 2608.02147, 2026).
• Per group: X25519MLKEM768 was supported on 1,787 HTTPS endpoints, compared with 161 HTTPS endpoints for SecP256r1MLKEM768.

For an operator of critical infrastructure, this means the cloud and SaaS endpoints you connect to vary. Some will negotiate the hybrid group, others won’t, and only your own handshake records show which is which.