In the Protocols MOC

up:: The Transition MOC

In the Protocols

Applied post-quantum cryptography is the work of getting the quantum-safe standards running inside the protocols that carry real traffic, chiefly TLS, IPsec, and SSH, plus the token and federation layers like JWT and SAML, through the libraries that implement them, so the new algorithms protect live connections instead of sitting in a standards document. Every one of these protocols follows the same shape: a public-key handshake that a quantum computer breaks, wrapped around a symmetric data channel that survives, and the migration swaps the handshake for a quantum-safe one while keeping the protocol itself. The rule that governs the entire hub, and the reason applied PQC is a rollout problem rather than a switch, is that a protocol is only as quantum-safe as its weakest deployed endpoint.

Map of content

A short overview of applied post-quantum cryptography in the protocols, and the index that routes you to every note in this section. Skim it to get oriented, then follow the links to go deep.

The short version:

• The new algorithms do nothing until they run inside a protocol. This hub is where ML-KEM and ML-DSA meet real network traffic.
• Every affected protocol splits the same way: a quantum-vulnerable public-key handshake (key exchange plus signatures) around a durable symmetric data channel (AES-256), so the fix targets the handshake and keeps the protocol.
• Key exchange migrates first because it’s the harvest-now-decrypt-later half, and the shared mechanism is hybrid key exchange, one classical algorithm and one post-quantum algorithm run together so the session holds if either survives.
• Signatures migrate on a slower track because they’re Non-HNDL: a forged signature needs a quantum computer live at the moment of use, so JWT, SAML, and certificate authentication are real but later.
• A protocol goes quantum-safe only when every endpoint on the path negotiates the new handshake, so one un-migrated load balancer, VPN gateway, or jump host reopens the exposure for everything behind it. Coverage across endpoints is what closes it.

Picture a new currency being introduced across a city. A bill is only useful in a transaction where both the payer and the merchant accept it, so the day one shop still takes only the old currency, every customer at that counter falls back to the old money. The currency itself is sound, and the printing presses have shipped the new bills. What decides whether a purchase actually happens in the new currency is coverage across the counter: both sides have to accept it. Post-quantum protocols work the same way. The algorithm is standardized and the libraries have shipped it, and whether a given connection is actually protected comes down to both endpoints, and every middlebox between them, handling the new handshake.

What does “post-quantum in the protocols” actually mean?

It means changing the public-key pieces inside a protocol’s handshake, while leaving the protocol and its symmetric data channel in place. Every protocol in this hub bundles several cryptographic jobs into one connection, and only the public-key jobs face the quantum threat:

1. Key exchange agrees on the secret keys that encrypt the session. Classical key exchange (ECDH, DH, or RSA key transport) is broken by Shor’s algorithm, and it’s the piece an attacker can record today and decrypt later.
2. Authentication proves identity with digital signatures (RSA, ECDSA, Ed25519). Those are also broken by Shor’s algorithm, but a forged signature only helps an attacker in real time, so there’s nothing to record.
3. Symmetric encryption protects the actual data (AES-GCM, ChaCha20-Poly1305). Grover’s algorithm only weakens it, and a 256-bit key answers that, so this channel is a strengthen-in-place item rather than a replacement.

So “is TLS quantum-safe?” or “is our VPN quantum-safe?” has no single answer. The honest answer names which mechanism is doing each job in a given deployment, because the key exchange, the signature, and the bulk cipher each face the quantum threat on a different clock. That split is the first thing to internalize, and it’s identical across TLS, IPsec, and SSH.

Which protocols carry the quantum exposure, and how does each migrate?

The protocols that matter are the ones carrying long-lived confidential traffic and the ones underwriting identity. Each migrates by swapping its public-key mechanism, and each has a characteristic deployment catch.

Protocol	The exposed piece	How it migrates	The catch
TLS	ECDHE key exchange (harvestable); RSA / ECDSA cert signatures (slower)	Hybrid group X25519MLKEM768 in the TLS 1.3 handshake, then PQC certificate signatures later	Oversized ClientHello crosses the single-packet boundary and old middleboxes drop it
IPsec	IKE Diffie-Hellman key exchange (harvestable); IKE_AUTH signatures (slower)	RFC 9370 multiple key exchanges add an ML-KEM exchange alongside classical (EC)DH	Both tunnel gateways are usually owned by different orgs and must upgrade in lockstep
SSH	ECDH / Curve25519 key exchange (harvestable); host and user keys (slower)	mlkem768x25519-sha256, the OpenSSH default since release 10.0	A legacy jump host or bastion in the path silently drags the session back to classical
JWT	RS256 / ES256 token signature	Re-sign tokens with ML-DSA (JOSE alg values from RFC 9964)	Every verifier must accept the new alg first, and kilobyte signatures overflow header and cookie limits
SAML	RSA / ECDSA assertion and metadata signature (XML Signature)	Re-sign assertions and federation metadata with ML-DSA	One identity provider’s key is trusted by every service provider it federates to

Source: K. Kwiatkowski, P. Kampanakis, B. Westerbaan, D. Stebila, “Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,” draft-ietf-tls-ecdhe-mlkem, datatracker.ietf.org.

Source: CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov, “Multiple Key Exchanges in IKEv2,” RFC 9370, May 2023, datatracker.ietf.org.

Source: OpenSSH, “Post-Quantum Cryptography,” openssh.com/pq.html.

Source: M. Prorock, O. Steele, “ML-DSA for JOSE and COSE,” RFC 9964, May 2026, datatracker.ietf.org.

The pattern to hold onto: the top three (TLS, IPsec, SSH) are confidentiality-first migrations driven by harvest-now-decrypt-later, and the bottom two (JWT, SAML) are signature-forgery migrations with no harvesting clock but a large blast radius. Both halves are covered in depth in their own notes; this hub is the map of how they fit together.

Why is a protocol only as quantum-safe as its weakest endpoint?

Because every one of these protocols negotiates its algorithms between two ends, and a session uses the new handshake only when both ends, and every device on the path, support it. This is the load-bearing rule of applied PQC, and it shows up three ways:

1. Coverage beats capability. If a modern browser supports X25519MLKEM768 but the load balancer it reaches doesn’t, the handshake falls back to classical key exchange and the HNDL window stays open. One un-migrated reverse proxy, CDN edge, VPN gateway, or SSH bastion reopens the exposure for everything behind it, so what closes the exposure is coverage across the whole population of endpoints.
2. Silent fallback hides the gap. The fallback to a classical algorithm is designed to be seamless, so a connection that quietly dropped to classical key exchange looks identical to a protected one. That’s why OpenSSH added a warning when a non-post-quantum key agreement is negotiated, and why confirming the negotiated group on real traffic is a distinct step from enabling it.
3. Ossification breaks the middle. The post-quantum key share is far larger than a classical one, and a long tail of middleboxes was built assuming the old size. In TLS the oversized ClientHello crosses a single-packet boundary and some old gear drops it; in IPsec the large ML-KEM value forces the IKE_INTERMEDIATE exchange (RFC 9242) to carry it. Two perfectly configured endpoints still fail if a third box between them refuses the bigger handshake.

Source: V. Smyslov, “Intermediate Exchange in IKEv2,” RFC 9242, May 2022, datatracker.ietf.org.

Source: Cloudflare, “Defending against future threats: Cloudflare goes post-quantum,” blog.cloudflare.com.

This is what makes applied PQC a rollout tracked endpoint by endpoint, defensible with a cryptographic bill of materials, rather than a box checked once. Underneath all of it is a crypto-agility question: endpoints that can negotiate a new group and retire an old one migrate cleanly, and endpoints hard-wired to one algorithm have to be re-architected or replaced first.

How does hybrid key exchange make a protocol quantum-safe?

Hybrid key exchange runs a classical key agreement and a post-quantum one together in the same handshake and derives the session key from both, so the connection stays secure as long as either half remains unbroken. It’s the single mechanism shared across TLS, IPsec, and SSH, and it’s the defining move of the whole transition because it closes the harvesting window without betting everything on a young lattice algorithm.

The construction differs only in the wire details:

1. TLS negotiates the named group X25519MLKEM768 (codepoint 0x11EC), pairing classical X25519 with ML-KEM-768, in the same supported_groups slot TLS already used for a classical curve.
2. IPsec uses RFC 9370 to add an ML-KEM key exchange in one of seven additional slots alongside the classical (EC)DH group, and mixes every result into the tunnel key.
3. SSH negotiates mlkem768x25519-sha256, the OpenSSH default since release 10.0 in April 2025.

Source: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, csrc.nist.gov.

The hybrid is a transitional design, not a permanent one. The classical half is exactly what a quantum computer breaks, so it’s carried as a hedge against an undiscovered flaw in the young post-quantum scheme, and it’s meant to retire once ML-KEM is trusted on its own. A hybrid with no exit plan quietly becomes permanent overhead, so planning the classical half’s retirement is part of doing hybrid correctly. The full mechanics, the codepoints, the byte sizes, and the ordering rules live in TLS 1.3 Hybrid Key Exchange.

Why does key exchange migrate first and signatures later?

Because the two run on different clocks, and the difference is HNDL versus Non-HNDL exposure. Key exchange is harvestable: an attacker records an encrypted session today, stores it, and decrypts it years later once a capable quantum computer exists. Any traffic that must stay confidential for a decade is exposed the moment it’s captured, so the harvesting window is already open. That urgency is why TLS, IPsec, and SSH all move key exchange first.

Signatures are the reverse. A forged certificate signature, a forged JWT, or a forged SAML assertion only helps an attacker in real time, at the moment of authentication, so there’s nothing to record and no deferred payoff. That makes the signature side genuinely less time-critical, and it also makes it harder to roll out, because it touches the entire identity and certificate ecosystem: certificate authorities, trust stores, every verifier that must accept a new algorithm. The replacement is ML-DSA as the general-purpose signature, with SLH-DSA where a conservative hash-based signature is preferred, and composite certificates carry both a classical and a post-quantum signature during the overlap so old and new verifiers each validate what they understand.

The signature side is less urgent on the clock, and it carries a bigger blast radius per key. One identity provider’s SAML signing key underwrites every service that federates to it, and one JWT issuer’s key underwrites every token that trusts it, so central high-privilege issuers still belong near the front of the plan even though the harvesting clock isn’t running on them.

Which libraries actually ship post-quantum protocols?

The protocols migrate through the libraries that implement them, and the library layer is where “standardized” turns into “deployable.” Support is broad as of 2026, and the load-bearing distinction is between an algorithm being present in a library and that algorithm being inside a FIPS-validated cryptographic module.

Ecosystem	Library	Post-quantum support	Production / FIPS status
C, general TLS	OpenSSL 3.5 (Apr 8, 2025)	Native ML-KEM, ML-DSA, SLH-DSA + hybrid TLS groups	Validated module is still 3.1.2 (pre-PQC); 3.5.4 submitted for FIPS 140-3 on Oct 9, 2025, CMVP pending
C, AWS ecosystem	AWS-LC + s2n-tls	ML-KEM (validated), ML-DSA; hybrid groups via s2n-tls	ML-KEM validated in the AWS-LC 3 module (CMVP #5314 / #5298), FIPS 140-3 Level 1
Rust	rustls (default aws-lc-rs backend)	X25519MLKEM768 prioritized by default since 0.23.27 (May 2025)	Default hybrid group labeled pre-standardization; FIPS via the aws-lc-rs FIPS build
Go	standard library crypto/mlkem + crypto/tls (Go 1.24); Cloudflare CIRCL for more	Auto X25519MLKEM768 in stdlib TLS; CIRCL adds PQC signatures and experimental certs	Stdlib for plain TLS; no CMVP-validated CIRCL module
SSH	OpenSSH 10.0 (Apr 2025)	mlkem768x25519-sha256 default key exchange; experimental PQC auth in 10.4	Inherits FIPS posture from the platform crypto or vendor build
Research, prototyping	liboqs (Open Quantum Safe) + oqs-provider	Broadest algorithm coverage (ML-KEM, ML-DSA, SLH-DSA, HQC, and research candidates)	Not FIPS-validated; maintainers advise against production use

Source: OpenSSL 3.5 final release, openssl-library.org; OpenSSL 3.5.4 FIPS submission, openssl-library.org.

Source: AWS Security Blog, “AWS-LC FIPS 3.0, first cryptographic library to include ML-KEM in FIPS 140-3 validation,” aws.amazon.com.

Source: rustls 0.23.27 release notes, github.com/rustls/rustls; Go crypto/mlkem, pkg.go.dev.

The good news the table carries: for a large amount of infrastructure, gaining post-quantum key exchange is a dependency upgrade rather than a rewrite. A Go 1.24 TLS server, a default rustls service, an OpenSSH 10.0 host, and an OpenSSL 3.5 endpoint with the hybrid groups enabled all reach the new key exchange without application-code changes. The libraries have their own hub context in the Go deeper section below.

Why is “the library supports it” not the same as “we’re compliant”?

Because a regulated deployment must run a validated cryptographic module, and shipping an algorithm in open source is a different event from that algorithm passing validation. Two distinctions decide this, and both trip people up:

1. Reference implementation versus certified module. liboqs is the industry’s PQC reference library, and its own maintainers state it should not guard sensitive data in production, because it carries no validation. A regulated system reaches ML-KEM through a certified build such as AWS-LC instead, whose module holds a completed CMVP certificate.
2. CAVP versus CMVP. CAVP validates that an algorithm implementation is correct in isolation, and CMVP validates the whole cryptographic module that ships it. A compliance gate turns on the module certificate, so an algorithm’s presence in source code, even correct source code, says nothing about whether a FIPS-bound system can use it.

Source: liboqs repository, github.com/open-quantum-safe/liboqs; NIST CMVP, csrc.nist.gov.

The clearest live example is OpenSSL: the code has done hybrid post-quantum TLS since 3.5 in April 2025, and the CMVP-validated OpenSSL module is still the pre-quantum 3.1.2, so a FIPS-bound estate has a feature date and a compliance date that are years apart. Conflating them is the most common way a library-level PQC plan goes wrong, and it’s why any roadmap tracks the validated-module date separately from the release date.

How do you know a protocol actually migrated?

You confirm it on the wire and in the configuration, because the presence of the protocol tells you nothing about its cryptographic posture. An HTTPS padlock, a working VPN, or an SSH prompt all look identical whether the handshake used a classical or a hybrid key exchange. Three facts follow:

1. The negotiated group is the ground truth. A packet capture of the handshake shows which key-exchange group the two ends actually selected, which is the only proof that the hybrid was used rather than merely offered. A connection can silently fall back to classical and still succeed.
2. Configuration inspection beats a live scan. A network scanner sees what one handshake negotiated, and it misses what an endpoint merely permits as a fallback. Reading the server configuration (TLS cipher and group settings, sshd_config KexAlgorithms, IKE proposals) is what reveals the real permitted posture.
3. The evidence rolls up to a CBOM. Tracking which endpoints negotiate which algorithms, across every vendor-controlled surface, is exactly what a cryptographic bill of materials captures, and it’s the artifact that makes the migration defensible to a board and an auditor. Many of these surfaces are vendor-controlled, so their timeline is a vendor dependency to track rather than internal work.

Common misconceptions

• “Quantum computers break TLS and VPNs and SSH.” The protocols hold. Two public-key pieces inside each (key exchange and signatures) are the vulnerable parts, and the fix swaps those mechanisms while keeping the protocol, the tunnel, and the symmetric data channel.
• “We’re on TLS 1.3, so we’re quantum-safe.” TLS 1.3 fixed forward secrecy and cleaned up the handshake, and it still uses classical ECDHE by default. Quantum safety is a separate step: negotiating a hybrid group like X25519MLKEM768.
• “Enabling the hybrid group is a config flag and we’re done.” The flag is the easy part. A session goes hybrid only when both endpoints, and every middlebox between them, support it, so the real work is coverage across every load balancer, gateway, bastion, and vendor surface in the path.
• “The certificate problem is the urgent one.” It’s the reverse. Certificate and token signatures need a quantum computer live at the moment of use, so there’s nothing to harvest. Key exchange is harvestable today, which makes it the piece to migrate first.
• “The library supports ML-KEM, so my regulated system can use it.” A FIPS-bound deployment needs a CMVP-validated module. An algorithm present in source, even correct source, doesn’t satisfy that gate until the module carrying it is validated.
• “Symmetric encryption needs replacing too.” It needs a larger key, not a new algorithm. AES-256 keeps a comfortable margin against Grover’s algorithm, so the data channel is a strengthen-in-place item.

Questions people ask

What’s the first protocol to migrate? TLS, because it carries the largest volume of long-lived confidential traffic and its key exchange is harvestable today. The move is enabling hybrid key exchange (X25519MLKEM768) across every TLS termination point, then post-quantum certificate signatures on a slower track.

Do I have to rewrite my applications? Usually not. TLS is typically terminated by a web server, load balancer, or gateway, IPsec by an appliance, and SSH by the platform, so post-quantum key exchange comes from upgrading that library or firmware and enabling the hybrid group, not from application code. Signature migration for JWT and SAML touches token and identity configuration rather than business logic.

What’s the one mechanism behind all of this? Hybrid key exchange, running a classical and a post-quantum key agreement together and mixing both into the session key, so the connection stays secure as long as either half holds. It’s the same idea in TLS, IPsec, and SSH, differing only in wire encoding.

Why does the handshake sometimes break in production? Size. The post-quantum key share is roughly a kilobyte where a classical one is tens of bytes, so it can spill past boundaries old middleboxes assumed. In TLS that’s the oversized ClientHello; in IPsec it’s why the IKE_INTERMEDIATE exchange exists. Testing the whole network path, including every middlebox between the two endpoints, is what catches it.

Which is more urgent, key exchange or signatures? Key exchange, clearly. It’s harvestable today, so a recorded session is a future liability. Signatures are Non-HNDL and need a live quantum computer to forge, so they’re a real but slower-clock problem, weighted by blast radius rather than a harvesting deadline.

Is any of this deployable today? Yes, for key exchange. Hybrid TLS ships in OpenSSL 3.5, rustls, and Go 1.24; hybrid SSH is the OpenSSH 10.0 default; hybrid IPsec is standardized in RFC 9370 with vendor firmware catching up. Post-quantum signatures and FIPS-validated modules trail behind on their own timelines.

How do I prove a connection is actually protected? Confirm the negotiated group on the wire with a packet capture, and read the endpoint configuration for what it permits as a fallback. Roll that evidence into a CBOM so the posture is defensible rather than assumed.

Go deeper

Protocols: TLS · TLS 1.3 Hybrid Key Exchange · X25519MLKEM768 and the TLS hybrid named groups · Mutual TLS · QUIC · IPsec · PQC in IPsec and IKEv2 (post-quantum VPNs, RFC 9370 to add an ML-KEM exchange alongside classical (EC)DH and RFC 8784 pre-shared keys for the harvest-now gap) · Virtual Private Network (VPN) · WireGuard · Secure Shell (SSH) · PQC in SSH (the OpenSSH key-exchange migration in depth, sntrup761x25519 then mlkem768x25519 as the release-10.0 default, with signatures still experimental) · JWT · SAML · PQC in DNSSEC

The modern KEM-based protocols: HPKE (Hybrid Public Key Encryption) (the modern KEM plus KDF plus AEAD standard, RFC 9180) · KEMTLS (authenticating the TLS handshake with KEMs in place of signatures) · MLS (Messaging Layer Security) (the IETF group-messaging standard, RFC 9420) · Double Ratchet (Signal’s per-message forward-secrecy ratchet)

Applied signing: Code Signing (proving software and firmware came from a trusted publisher and wasn’t tampered with, the first signing surface to migrate because firmware roots of trust are long-lived) · PQC in Firmware and Code Signing (why firmware and secure boot use the stateful hash-based signatures LMS and XMSS from SP 800-208 rather than ML-DSA, the state-management burden, and the long-lived-device motivation)

Enterprise authentication: FIDO2, WebAuthn, and Passkeys (passwordless authentication rests on classical ECDSA, EdDSA, and RSA signatures, so it moves the quantum problem from the password to the signature, and the FIDO Alliance is scoping ML-DSA into the credential format) · PQC in Kerberos and Active Directory (Kerberos’s symmetric AES core is largely resistant, and the exposed surface is PKINIT certificate pre-authentication and the AD certificate authority, with Microsoft’s Windows PQC roadmap now shipping ML-KEM and ML-DSA) · PQC in OAuth 2.0 and OIDC (the authorization-flow surfaces beyond token signing, DPoP proof-of-possession, mTLS-bound tokens, the private_key_jwt client assertion, and signed authorization requests, that every SaaS API and B2B integration runs on)

Encrypted mail: S-MIME and OpenPGP (the two standards for end-to-end encrypted and signed email, where the encrypted half is a clear harvest-now-decrypt-later target because mail sits in archives for years while a classical key wraps each message) · PQC in S-MIME and CMS (the IETF LAMPS migration: ML-DSA in CMS and X.509 via RFC 9882 and RFC 9881, and ML-KEM through the KEMRecipientInfo structure of RFC 9629)

Secure messaging: Signal PQXDH (Signal’s post-quantum key agreement, adding ML-KEM to the classical X3DH handshake to protect the initial shared secret, Apple’s Level 2) · Apple iMessage PQ3 (Apple’s protocol applying ML-KEM to both the initial key establishment and the ongoing rekeying, Apple’s Level 3)

Deployment status: Cloud and Browser PQC Status (where the major clouds and browsers actually stand on hybrid post-quantum TLS today, AWS, Cloudflare, Chrome, and Firefox, with live adoption figures flagged to verify at citation)

The libraries that ship it: OpenSSL · OpenSSH · AWS-LC · BoringSSL · wolfSSL · BouncyCastle PQC Provider · Cloudflare CIRCL · rustls · liboqs (Open Quantum Safe)

Validation and firmware: FIPS 140-3 (the module validation a post-quantum implementation needs before federal deployment) · NIST SP 800-193 (firmware resiliency, where code signing is a priority post-quantum surface)

Scale and interoperability: Cryptographic Interoperability (the fault line that opens after the standards publish, when old and new endpoints must coexist) · PQC in the Web PKI (CA-Browser Forum) (how the public certificate ecosystem moves to PQC, with shorter certificate lifetimes as the agility groundwork) · Merkle Tree Certificates (MTC) (making web PKI’s post-quantum certificate sizes practical at internet scale)

In the hardware: PQC in Hardware (HSMs, TPMs, PKCS11) (post-quantum support in HSMs, TPMs, and smart cards through PKCS#11 3.2 and TPM 2.0 v1.85, where the load-bearing distinction is CAVP algorithm testing versus a completed FIPS 140-3 CMVP module certificate)

Where it gets hard: Constrained-Device PQC (running the new algorithms on IoT sensors, smart cards, and embedded controllers, where artifact size, not speed, is the binding constraint)

In the long-lived verticals: PQC in Automotive and V2X (vehicle security across a 15-to-20-year service life) · PQC in Medical Devices (decade-plus device lifetimes and FDA guidance) · PQC in Satellites and Space (unpatchable long-mission spacecraft) · PQC in Payments (EMV and PCI) (the payment card ecosystem, from terminal to issuer) · PQC for OT, ICS, and SCADA (industrial control systems with decade-scale hardware, the air-gap myth, gateways, and the symmetric pre-shared-key path that needs no public-key math on the endpoint) · PQC in 5G and Mobile Networks (the 5G-core surfaces, SUCI subscriber-privacy ECIES on the SIM, 5G-AKA, and the SEPP N32 inter-operator TLS, standardized by 3GPP and ETSI)

The standards these protocols carry are in The New Standards; the shared migration ideas (hybrid cryptography, crypto-agility, and the CBOM that inventories it all) sit one level up in the transition. The protocol foundations these build on (TLS as a concept, PKI, key exchange) are in Foundations.

---

Everything here is the map, given freely. When your team needs its own protocol estate found, its harvestable key exchange prioritized, and a hybrid rollout sequenced across every endpoint, appliance, and vendor surface, defensible to your board and your auditor, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.