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 }

Check Without Installing Anything

You do not need a custom OpenSSL build to test a public-facing server. Two options work without any setup at all.

Option 1 - Your browser (the most realistic test)

Chrome 124+, Edge 124+, and Firefox 132+ already advertise X25519MLKEM768 in the TLS client hello by default. Visit a site and if the server supports ML-KEM, the browser negotiates it automatically. You can see exactly what was negotiated in the browser's own security panel, which is the closest thing to a real user session.

If the Key Exchange field shows X25519 or P-256, the server is TLS 1.3 but classical only. Same connection, different algorithm in the key_share slot.

Option 2 - SSL Labs (Qualys)

SSL Labs has been the industry standard for TLS server analysis for years. It runs a full handshake from Qualys infrastructure and reports what cipher suites, groups, and protocol versions the server actually supports, not just what it claims to.

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