Post-quantum TLS ML-KEM hybrid key exchange is the mechanism by which a TLS 1.3 handshake combines a classical elliptic-curve algorithm with the NIST-standardised ML-KEM lattice-based key encapsulation, so that a session key remains secure even if either algorithm alone is broken. For European government bodies, hospitals, financial institutions and legal firms, this is not a future-proofing exercise: it is an immediate risk-management decision driven by adversaries who are recording encrypted traffic today.
Why TLS 1.3 is the primary harvest-now-decrypt-later target
TLS 1.3 is the backbone of virtually every sensitive communication in regulated infrastructure, from citizen-facing government portals and hospital patient APIs to inter-bank settlement layers and legal document exchange platforms. That ubiquity makes it the most valuable corpus for harvest-now-decrypt-later (HNDL) collection.
In an HNDL attack, a capable adversary, typically a nation-state signals-intelligence service, intercepts and stores ciphertext in bulk without attempting real-time decryption. The stored sessions become readable once a cryptographically relevant quantum computer (CRQC) is available. The threat is asymmetric: the attacker bears the cost of storage now and the cost of compute later, while the defender has only a finite window to rotate keys before the data’s sensitivity period expires.
The data categories most exposed are precisely those handled by regulated European organisations: health records with multi-decade retention obligations under GDPR Article 9, legally privileged communications, classified government traffic, and long-term financial contracts subject to DORA and MiFID recordkeeping rules. A TLS session protecting a hospital API in 2025 may remain sensitive in 2035, well within plausible CRQC timelines cited by ENISA and national cybersecurity agencies.
What IETF draft-ietf-tls-hybrid-design specifies as the transition path
The IETF TLS Working Group’s draft-ietf-tls-hybrid-design defines the concrete mechanism for combining classical and post-quantum algorithms within a single TLS 1.3 key exchange. The draft specifies that the two component shared secrets are concatenated and fed into the TLS key schedule, ensuring that the resulting session key is only compromised if both algorithms are simultaneously broken.
The working group states directly: “Hybrid mechanisms that combine a classical and a post-quantum algorithm provide a hedge against both the failure of the post-quantum algorithm and the failure of the classical algorithm due to a cryptographically relevant quantum computer.” This framing is significant for compliance officers: hybrid is not a weaker compromise but a stronger position than either algorithm alone during a transition period where confidence in new post-quantum algorithms is still accumulating.
The companion draft, IETF draft-ietf-tls-mlkem, translates NIST FIPS 203 into concrete TLS 1.3 named groups. It registers X25519MLKEM768 as the primary hybrid group and defines pure ML-KEM-512, ML-KEM-768 and ML-KEM-1024 groups for environments where classical interoperability is no longer a constraint. Both drafts are on the IETF standards track and are already implemented in OpenSSL 3.x, BoringSSL and recent versions of the Rustls library.
Hybrid versus pure post-quantum key exchange: when each applies
The distinction between hybrid and pure post-quantum key exchange has direct operational consequences for regulated sector deployments.
| Mode | Algorithm combination | Recommended for | Risk profile |
|---|---|---|---|
| Hybrid (X25519MLKEM768) | X25519 + ML-KEM-768 | All externally facing TLS endpoints during migration period | Secure if either algorithm holds; backward compatible with classical-only peers via negotiation |
| Pure ML-KEM-768 | ML-KEM-768 only | Internal service meshes between fully upgraded nodes; air-gapped sovereign environments | Full PQC protection; no classical fallback; requires both sides to support FIPS 203 |
| Pure ML-KEM-1024 | ML-KEM-1024 only | Long-lived government-to-government tunnels; classified infrastructure under national guidance | Highest security margin; larger keys increase handshake size by an additional ~0.5 KB versus ML-KEM-768 |
ETSI TS 103 744 (March 2025), the European standardisation of quantum-safe hybrid key exchanges, aligns with the IETF approach and explicitly endorses X25519MLKEM768 as the recommended hybrid combination for European infrastructure operators. For NIS-2 essential entities, deploying this hybrid on all externally facing TLS termination points satisfies the spirit of the upcoming mandatory PQC requirements without breaking existing client stacks that do not yet support post-quantum named groups.
Impact on certificate lifetimes, handshake size and performance
Key exchange and authentication are separate concerns within the TLS 1.3 architecture, and this separation matters for planning. Deploying ML-KEM hybrid key exchange does not require immediate certificate replacement: existing RSA-2048 or ECDSA P-256 certificates continue to serve the authentication function. However, the IETF ML-DSA drafts and the NIS Cooperation Group roadmap both identify post-quantum authentication (ML-DSA, standardised as NIST FIPS 204) as the next migration layer, particularly for internal PKI roots and long-lived code-signing certificates.
On handshake size: ML-KEM-768 public keys are 1,184 bytes and ciphertexts are 1,088 bytes, compared to 32 bytes for an X25519 public key. A hybrid TLS 1.3 handshake therefore adds roughly 2.2 KB to the exchange. NIST SP 1800-38C, the quantum-resistant cryptography interoperability report, documents testing across representative network infrastructure and confirms this overhead is operationally manageable for standard web and API workloads. The report identifies constrained IoT devices and sub-millisecond latency-sensitive financial trading APIs as the scenarios requiring individual assessment rather than blanket deferral.
IBM’s Cost of a Data Breach Report 2023 recorded the global average breach cost at USD 4.45 million, the highest in the report’s 18-year history. For regulated European organisations subject to GDPR fines (up to 4% of global annual turnover under Article 83(5)), NIS-2 incident reporting obligations and DORA operational resilience requirements, the cost calculus of deferring PQC migration is unfavourable even before accounting for the long-tail risk of HNDL decryption.
The EU NIS Cooperation Group PQC Roadmap and sector migration milestones
The EU NIS Cooperation Group PQC Roadmap v1.1, published in June 2025, provides the authoritative European policy framework for post-quantum migration. It applies to essential entities under NIS-2 (energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure) and to important entities in adjacent sectors.
ENISA has stated: “Organisations should start their migration to post-quantum cryptography now, prioritising long-lived data and high-value communications, because the window to act before cryptographically relevant quantum computers arrive is narrowing.” The roadmap translates this urgency into concrete milestones:
- By end of 2025: complete a full cryptographic inventory, classify assets by data sensitivity lifetime and exposure surface, and identify all TLS termination points including load balancers, API gateways and internal service-to-service calls.
- By 2026: deploy hybrid key exchange (X25519MLKEM768 or equivalent) on all externally facing TLS endpoints; begin laboratory testing of pure ML-KEM on internal service meshes.
- By 2027: essential entities should achieve broad quantum-safe key exchange coverage on externally facing services; initiate certificate authority migration planning for ML-DSA.
The roadmap explicitly maps these milestones to NIS-2 Article 21 obligations on cryptography and to DORA Article 9 ICT security requirements, providing the compliance linkage that CISOs and DPOs need to justify budget allocation internally.
Inventorying and prioritising TLS endpoints without breaking compatibility
A practical PQC migration for a government ministry, hospital network or financial institution starts with endpoint classification, not with deploying new TLS libraries. The three-tier inventory model recommended by NIST SP 1800-38C and aligned with the NIS Cooperation Group roadmap structures work as follows.
Tier 1, externally facing web gateways and citizen portals, carries the highest HNDL exposure because session captures are trivial for any network-adjacent adversary. These endpoints should receive hybrid key exchange first, because modern browsers (Chrome 124+, Firefox 127+) already support X25519MLKEM768 natively, meaning no client-side changes are required. Load balancers running nginx 1.25+ with OpenSSL 3.x or HAProxy with an appropriate PQC build can enable the hybrid group with a single configuration change, using TLS_AES_256_GCM_SHA384 with the X25519MLKEM768 named group added to the supported groups list.
Tier 2, API layers and machine-to-machine services, requires checking whether API client libraries on both sides support the hybrid group. Where they do not, the TLS negotiation falls back to X25519 automatically because IETF draft-ietf-tls-hybrid-design specifies that unknown named groups are simply skipped during negotiation. This backward-compatibility property is what makes the hybrid approach low-risk to deploy incrementally.
Tier 3, internal service meshes (Kubernetes ingress controllers, service-mesh sidecars such as Envoy or Linkerd), represents the highest operational complexity because mutual TLS (mTLS) configurations involve both key exchange and certificate-based authentication. For these environments, piloting pure ML-KEM-768 in isolated namespaces while maintaining hybrid on the perimeter is the recommended sequencing.
For organisations operating sovereign infrastructure in Switzerland under the revised Federal Act on Data Protection (revFADP), the combination of jurisdictional isolation and post-quantum TLS on all external-facing endpoints represents a defensible, audit-ready posture. Compliance officers documenting this posture for GDPR Article 32 (appropriate technical measures) or DORA Article 9 (ICT security) should reference FIPS 203, ETSI TS 103 744, and the NIS Cooperation Group roadmap version number and publication date in their technical and organisational measures documentation, providing the specific standards citations that supervisory authorities expect.
FAQ
What is harvest-now-decrypt-later and why does it make TLS 1.3 urgent to upgrade?
Harvest-now-decrypt-later is a strategy where adversaries record encrypted TLS sessions today and store them until a cryptographically relevant quantum computer becomes available to break the session keys retrospectively. Because TLS 1.3 protects data in transit for services ranging from API calls to citizen portals, any session captured today could expose its plaintext payload years from now. Data with a long sensitivity lifetime, such as health records, legal files or classified government communications, is therefore at immediate risk even before quantum hardware exists.
What is the practical difference between X25519MLKEM768 hybrid and pure ML-KEM-768?
X25519MLKEM768 combines the classical X25519 elliptic-curve Diffie-Hellman with ML-KEM-768 in a single key exchange, so the session key is only compromised if both algorithms are broken simultaneously. Pure ML-KEM-768 relies entirely on the lattice-based algorithm. Hybrid is the recommended transition mechanism under draft-ietf-tls-hybrid-design because it maintains security even if a flaw is discovered in the new post-quantum algorithm, making it the safer choice for regulated environments during the migration period.
Does switching to post-quantum TLS require replacing existing certificates?
Key exchange and authentication are separate concerns in TLS 1.3. Deploying ML-KEM hybrid key exchange does not immediately require replacing RSA or ECDSA certificates, because authentication and key encapsulation are handled by different mechanisms in the handshake. However, the IETF ML-DSA drafts and the NIS Cooperation Group roadmap both recommend beginning a parallel migration of certificates to post-quantum signature algorithms (ML-DSA, FIPS 204) before 2027, particularly for long-lived certificates used in internal PKI and code signing.
How large is the additional handshake overhead from ML-KEM, and is it operationally significant?
ML-KEM-768 public keys and ciphertexts are each roughly 1 KB, compared to 32 bytes for X25519. This means a hybrid TLS 1.3 handshake grows by approximately 2 to 3 KB in total. NIST SP 1800-38C interoperability testing showed this is manageable on modern infrastructure and adds negligible latency on standard connections. Constrained IoT devices and high-frequency, low-latency API endpoints in financial trading systems warrant individual assessment, but for typical government portals, healthcare APIs and enterprise gateways the overhead is operationally acceptable.
Which sectors face the earliest NIS Cooperation Group migration deadlines?
The EU NIS Cooperation Group PQC Roadmap v1.1 (June 2025) applies its earliest milestones to essential entities in energy, finance, health and digital infrastructure. These sectors are expected to complete a cryptographic inventory and risk classification by end of 2025, begin hybrid key exchange deployment on externally facing services by 2026, and achieve broad quantum-safe key exchange coverage by 2027. Important entities in sectors such as postal services, waste management and manufacturing follow the same framework but with slightly extended timelines.