Upgrading Edge Ingress to Hybrid Post-Quantum Key Exchange (ML-KEM-768) "Harvest Now, Decrypt Later" (HNDL) is not a future vulnerability—adversaries are actively intercepting and storing encrypted traffic passing through UK internet exchanges. For UK engineering teams handling sensitive customer data, IP, or financial payloads with a 5+ year shelf-life, securing transit channels requires moving to hybrid key encapsulation right now. The UK National Cyber Security Centre (NCSC) guidance prioritises hybrid implementations as the bridge to complete quantum resistance: pairing classical curves with lattice-based algorithms so that legacy compliance and performance remain intact while establishing post-quantum security. Here is a practical tutorial to audit and test hybrid PQC on your ingress layer: 1. Understand the Hybrid Mechanism Instead of negotiating a single secret over classical Elliptic Curve Diffie-Hellman (ECDH), hybrid key exchange (such as X25519Kyber768Draft00 / X25519MLKEM768) performs two handshakes simultaneously inside TLS 1.3: Classical component: Standard X25519 ensures backward compatibility and baseline cryptographic guarantees. Lattice component: ML-KEM-768 (standardised from Kyber) provides quantum-resistant encapsulation. The resulting shared secret is derived through HKDF (HMAC-based Extract-and-Expand Key Derivation Function) from both public keys, meaning an adversary must break both schemes to decrypt the payload. 2. Audit Client Hello Sizes and MTU Fragmentation ML-KEM-768 public keys and ciphertexts are significantly larger than classical 32-byte X25519 keys (~1,184 bytes). Verify whether your edge proxies, WAFs, or upstream cloud load balancers drop Client Hello packets exceeding typical MTU thresholds (1,500 bytes). Ensure your ingress gateway supports TCP segmentation and TLS fragmentation properly without dropping truncated handshakes. 3. Configure Ingress Testing (Envoy / OpenSSL 3.x / BoringSSL) In your edge proxy configuration (e.g., Envoy or modern NGINX built against an ML-KEM-capable OpenSSL/BoringSSL branch): Verify supported TLS 1.3 cipher suites and key exchange groups: YAML tls_certificates: - certificate_chain: { filename: "/etc/ssl/certs/ingress.crt" } private_key: { filename: "/etc/ssl/private/ingress.key" } tls_params: tls_minimum_protocol_version: TLSv1_3 ecdh_curves: - X25519MLKEM768 - X25519 Deploy the configuration to a canary staging cluster. 4. Validate via CLI Test your endpoint using a PQC-enabled build of curl or openssl: Bash openssl s_client -connect api.staging.internal:443 -tls1_3 -curves X25519MLKEM768 Inspect the output to confirm Temp Key: ML-KEM-768 + X25519 was successfully agreed upon during the TLS 1.3 handshake. Discussion Question Has your team audited packet fragmentation risks for larger PQC key exchanges on existing reverse proxies, or are you waiting for cloud ingress providers to toggle it by default? CTA (Join Techawks UK) Join the Techawks UK community to connect with local systems engineers, platform leads, and cloud architects deploying resilient, quantum-ready infrastructure.