Network Architecture & Verification

What the Organisation Can and Cannot Control

ML-KEM is available. The question is: available where, and to whom?

The honest answer is: you can control your own TLS termination points. If your organisation runs Cloudflare, F5 BIG-IP, or a similar edge that you configure, you can enable ML-KEM there. You can verify it is negotiating. You can measure the gap between what you have and what you want.

What you can't control is the outbound path. Specifically, any TLS session initiated from inside your network to a third-party endpoint. SaaS applications, partner APIs, vendor portals, cloud services your users connect to directly. If PII or sensitive data flows from your network to those endpoints, the TLS negotiation happens between your user's device (or your outbound proxy) and a server you don't own. Whether that session uses ML-KEM is entirely the vendor's decision. You can't configure it. You can only ask them where they're on their roadmap.

The Architecture: Two TLS Legs

For traffic coming into the organisation (inbound HTTPS to your published services), there's no single TLS tunnel from the user's browser all the way to the backend. TLS terminates and re-originates at each inspection or routing point. In a standard CDN plus load balancer setup, that means two separate TLS legs, each independently configured, each with its own ML-KEM status. Getting Leg 1 right does not automatically fix Leg 2.

Vendor PQC Status

F5 BIG-IP Configuration

tmsh modify ltm profile \
  client-ssl <name> \
  ciphers "DEFAULT:\
+SecP256r1ML-KEM-768" \
  options { no-tlsv1 \
  no-tlsv1-1 }

Getting OpenSSL 3.5+

Worth flagging upfront: a common error when verifying ML-KEM negotiation from the command line looks like a server problem but is entirely a client problem. The openssl s_client command needs OpenSSL 3.5.0+ to even know what X25519MLKEM768 is. Older versions refuse with a hard error, and depending on your shell and OS, you might be running an older version than you think.

Step 1: Which openssl are you actually calling?

which openssl
openssl version

openssl list -tls-groups | grep MLKEM

Step 2: Fix by platform

# Confirm you are in Git Bash with the right binary
which openssl   # should show: /mingw64/bin/openssl
openssl list -tls-groups | grep MLKEM

# Install build dependencies
sudo apt install -y build-essential wget

# Download OpenSSL 3.5.0 source
wget https://github.com/openssl/openssl/releases/download/openssl-3.5.0/openssl-3.5.0.tar.gz
tar xzf openssl-3.5.0.tar.gz && cd openssl-3.5.0

# Configure with rpath. This is the important part
./Configure --prefix=/usr/local/openssl35 \
            --openssldir=/usr/local/openssl35 \
            -Wl,-rpath,/usr/local/openssl35/lib64

make -j$(nproc) && sudo make install

# Verify
/usr/local/openssl35/bin/openssl version

# Add a shell function to ~/.bashrc
cat >> ~/.bashrc << 'EOF'
openssl35() {
  LD_LIBRARY_PATH=/usr/local/openssl35/lib64 \
    /usr/local/openssl35/bin/openssl "$@"
}
EOF
source ~/.bashrc

openssl35 version   # should show OpenSSL 3.5.0

Running the Verification

Once you have a working OpenSSL 3.5+ binary, the command is the same everywhere. The line to look for in the output is Negotiated TLS1.3 group: X25519MLKEM768.

openssl s_client \
  -connect your-hostname:443 \
  -tls1_3 \
  -groups "X25519MLKEM768:x25519" \
  -CAfile /etc/ssl/certs/ca-certificates.crt \
  -brief