Abstract

NIST’s finalization of ML-KEM (formerly CRYSTALS-Kyber) and ML-DSA (formerly CRYSTALS-Dilithium) in August 2024 converted post-quantum cryptography from a research concern into an immediate engineering problem for enterprise security teams. As of early 2026, major TLS stacks have shipped experimental or production-grade support, but actual enterprise migration remains fragmented. This article examines the technical architecture of hybrid key exchange in TLS 1.3, the tooling landscape for discovering classical-crypto dependencies, and the prioritization logic for which traffic warrants migration first.

The Hybrid Key Exchange Model

Hybrid key exchange - pairing a classical algorithm like X25519 with a post-quantum KEM in a single TLS handshake - is the IETF-recommended migration path. The combined shared secret is fed through a KDF such that breaking the session requires breaking both algorithms simultaneously. OpenSSL 3.x with the OQS (Open Quantum Safe) provider and BoringSSL (deployed in Chrome 124+) both support the X25519Kyber768Draft00 and the standardized X25519MLKEM768 group identifiers. The practical consequence is roughly 1-2 KB of additional handshake data and measurable latency increases on high-volume endpoints - observed at around 1-5 ms in benchmarks on 2025-era hardware, depending on hardware acceleration availability for ML-KEM’s NTT operations.

Crypto-Dependency Discovery

The harder problem for most enterprises is not enabling hybrid TLS on a load balancer - it is finding every place that classical asymmetric cryptography appears in the estate. Certificate authorities, VPN endpoints, code-signing pipelines, SSH keys, JWT signing keys, encrypted backup keys, and hardware security module configurations all represent distinct migration surface. Tools emerging to address this include Cryptosense Analyzer, IBM’s Crypto Bill of Materials (CBOM) tooling, and open-source scanners like crt-scanner that index certificate transparency logs for an organization’s domain space. None of these provide complete coverage; a combination of network interception (inspecting TLS handshakes at the proxy layer) and static code analysis for crypto API calls is the current best practice.

Prioritization Logic

Not all traffic needs post-quantum protection immediately. The threat model driving urgency is “harvest now, decrypt later” - adversaries storing today’s ciphertext to decrypt once a sufficiently powerful quantum computer exists. The prioritization question is therefore: what data, if decrypted in 10-15 years, represents unacceptable harm? Long-lived government secrets, health records with lifetime privacy requirements, and authentication credential material used to sign long-duration certificates are in the first tier. High-frequency ephemeral session traffic - user web sessions, telemetry - is lower priority because the decrypted content has no long-term value. Teams should apply this triage before committing migration budget, since full TLS estate migration is a multi-year project for any organization with significant infrastructure.