PQC for TLS / VPN / SSH: Practical Migration Constraints (2026)

Last updated: October 23, 2026

If you’re trying to “do PQC,” it’s tempting to start with a sentence like: “We’ll switch to post‑quantum algorithms.” In practice, protocol migrations don’t fail because the algorithms are unknown – they fail because the ecosystem is messy:

  • clients and servers upgrade on different timelines,
  • middleboxes dislike new handshake shapes,
  • packet sizes hit MTU limits,
  • libraries lag behind standards (or implement drafts differently),
  • and compliance requirements (FIPS, procurement) constrain what you can actually ship.

This guide is about those real constraints for the three protocols that show up everywhere:

  • TLS 1.3 (web + APIs + service-to-service)
  • IKEv2/IPsec (VPNs and site-to-site tunnels)
  • SSH (admin access and automation)

It’s deliberately practical: what’s standardized now, what’s emerging, and what breaks when you try to deploy it.

The up-to-date baseline: what’s standardized vs what’s still moving

NIST: the PQC primitives are standardized

For key establishment and signatures, NIST has approved PQC FIPS standards:

NIST announcement (Aug 2024): https://www.nist.gov/news-events/news/2024/08/announcing-approval-three-federal-information-processing-standards-fips

IETF: TLS and SSH have “how to use PQC in the protocol” docs now

As of 2026, you can point to concrete IETF RFCs for hybrid post‑quantum key agreement in TLS 1.3 and in SSH:

IKEv2/IPsec: ML‑KEM integration is in IETF draft form

For IKEv2, the ML‑KEM work is specified in an ipsecme working group draft:

This draft is very explicit about real deployment constraints like packet size and fragmentation risk (more on that below).

The recurring constraint across all three: interoperability beats cryptography

In protocol migrations, the real question is rarely “is ML‑KEM secure?” It’s:

“Can every endpoint and dependency in the path handle the new handshake?”

For each protocol, you have at least four moving parts:

  1. client implementation (browser, agent, CLI, device)
  2. server implementation (service, gateway, VPN headend, sshd)
  3. cryptographic library (OpenSSL/BoringSSL/etc., sometimes embedded)
  4. network path (proxies, DPI, NATs, MTU, fragmentation behavior)

Crypto changes modify wire behavior (sizes, extensions, negotiation), and the network path reacts.

TLS 1.3: what changes with PQC (and what breaks)

TLS PQC migration is primarily about key establishment (KEM/hybrid groups) rather than certificate signatures in the short term.

What’s standardized for TLS PQC in 2026

Two key TLS documents to know:

There is also ongoing IETF work to define ML‑KEM as NamedGroups for TLS 1.3 more generally (not only the hybrid groups). As of mid‑October 2026, draft-ietf-tls-mlkem is in the RFC Editor queue:
https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

Practical TLS constraints you hit first

1) Handshake size and “new handshake shape”

PQC key material is bigger than classical ECDHE shares. That can increase:

  • ClientHello size (supported groups + key shares)
  • ServerHello/handshake messages depending on negotiation

Bigger handshakes are not automatically a problem – but they can trigger latent issues:

  • middleboxes with small parsing limits
  • proxies doing TLS inspection that don’t recognize new groups
  • logging/telemetry systems that start capturing huge blobs

2) Middleboxes and TLS interception

TLS interception stacks often lag modern TLS behavior, and PQC/hybrid negotiation is new behavior. Even if your endpoints support it, the intercepting device may not.

A practical deployment tip: if you run TLS interception (enterprise proxies), treat PQC/hybrid rollout like a protocol upgrade – test on representative paths first.

3) “Client-first” reality for public-facing TLS

For public internet TLS, you can upgrade your servers tomorrow, but adoption is gated by client support (browsers, OS TLS stacks, enterprise agents). That’s why most production plans look like:

  • start PQC/hybrid in controlled environments (internal services, test rings)
  • monitor handshake failures closely
  • expand only when client coverage is acceptable

4) FIPS expectations and “approved mode” constraints

If you operate in FIPS-constrained environments, you may need:

  • FIPS-validated cryptographic modules
  • specific algorithm/parameter sets
  • operational documentation about “approved mode”

This is less about TLS itself and more about what your compliance boundary will permit.

VPN (IKEv2/IPsec): the MTU problem is not a footnote

IKEv2 is a negotiation protocol that runs over the network paths you don’t fully control (VPN links, NATs, constrained networks). PQC key exchange payloads can get big enough that packet size becomes a primary design constraint.

What the IETF IKEv2 ML‑KEM draft says (and why it matters)

The ipsecme draft for ML‑KEM in IKEv2 explicitly calls out that:

  • ML‑KEM can be used alone or as an additional key exchange alongside a traditional exchange (hybrid PQ/T)
  • higher-security parameter sets (ML‑KEM‑768 / ML‑KEM‑1024) can push IKE_SA_INIT messages beyond typical path MTUs
  • IKE_SA_INIT cannot be fragmented in the same way as later messages, so fragmentation risk is a real deployment limiter
  • one motivation for hybrid in IKEv2 is to avoid fragmentation pressure with large key exchange payloads

Source (draft text): https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/

Practical IKEv2 migration constraints

1) UDP packet size, fragmentation, and “it works in the lab”

IKEv2 commonly runs over UDP. When packets exceed path MTU, fragmentation and packet loss behavior varies wildly across networks and NAT devices.

So even if a scheme is standardized, your deployment plan must answer:

  • are we relying on fragmentation?
  • do we have reliable transport options?
  • do we control the path MTU?

If your answer is “we’re not sure,” you should not roll out large PQC payloads broadly yet.

2) Multiple key exchanges complicate negotiation and interoperability

IKEv2 supports multiple key exchanges (and the ecosystem is already complex). PQC adds new combinations and new failure modes.

One safe operational preference: standardize on a small number of approved combinations rather than “anything negotiates.”

3) Vendor headends and appliances move slower

Unlike TLS (where you might swap libraries in apps), VPN headends are frequently appliances with slower upgrade cycles. Your migration may be gated by:

  • vendor support for ML‑KEM key exchange
  • ability to do the negotiation without fragmentation problems
  • support for reliable transport if needed

This is why PQC VPN migration often starts with a constrained pilot (one site-to-site tunnel on a known path) rather than a global rollout.

SSH: PQC is already mainstream operationally (if you’re on OpenSSH)

SSH is one place where “PQC/hybrid” isn’t just a standards discussion; it has been deployed in real implementations for years.

What’s standardized for SSH PQC/hybrid

Two relevant IETF RFCs:

OpenSSH reality (useful because it’s candid and operational)

OpenSSH maintains an up-to-date PQC status page that explains which KEX algorithms it supports and when it made them default:

This is one of the clearest “what should I do tomorrow?” references for SSH migration because it’s tied to real versions and default behavior.

Practical SSH migration constraints

1) Client/server version skew

In SSH, mismatch is common:

  • your laptop client may be modern
  • the server may be ancient (or vendor-locked)
  • automation (CI runners, network devices) may lag far behind

So “turning on PQC KEX” can be as simple as upgrading servers – or it can be blocked by vendor firmware.

2) Policy and compliance controls can override defaults

Even when OpenSSH supports PQC KEX by default, enterprise hardening baselines sometimes pin KexAlgorithms lists. Your migration plan needs to check:

  • what is allowed by config baselines
  • what automation images ship with
  • whether old servers disable newer methods

3) Visibility and user experience

OpenSSH 10.1 introduces warnings when a session is not using a post‑quantum key exchange (per the OpenSSH PQ page). That kind of UX behavior can be extremely helpful operationally: it turns “silent downgrade” into “visible signal.”

The practical rollout plan (TLS/VPN/SSH)

Phase 1: Inventory and select a constrained pilot

Pick one or two flows per protocol where you control most variables:

  • TLS: an internal service-to-service path (same clients, same load balancers)
  • VPN: one site-to-site IKEv2 tunnel over a known MTU path
  • SSH: a controlled fleet of bastion hosts

Success criteria should be measurable:

  • handshake success rate
  • error rates
  • performance/latency impact
  • operational failure modes (retries, timeouts)

Phase 2: Upgrade endpoints before you “enable PQC”

In all three protocols, you’ll get better results by:

  • upgrading clients and servers first
  • verifying baseline behavior
  • then enabling PQC/hybrid negotiation

This reduces the “is it the new algorithm or is it the old box?” debugging spiral.

Phase 3: Monitor the right signals (not just “is it on?”)

For TLS:

  • handshake failures by client population
  • changes in ClientHello size and rejection patterns
  • middlebox-related errors (often clustered by network)

For IKEv2:

  • negotiation failures by path
  • fragmentation-related packet loss symptoms (timeouts, retransmits)
  • any transport fallback behavior

For SSH:

  • negotiated KEX algorithm distribution
  • fleet compliance with allowed KEX lists
  • warnings indicating non-PQ KEX usage (where available)

Phase 4: Standardize on “approved combinations”

Avoid “anything goes.” You want:

  • a small set of approved algorithms/groups
  • a policy for fallback when the peer doesn’t support PQC/hybrid
  • a plan to remove legacy options later

This is where crypto agility becomes real: policy + telemetry + change control.

Common mistakes (what wastes time)

  • Treating TLS, VPN, and SSH as “the same migration.” They are three different ecosystems.
  • Enabling new options globally without a controlled pilot (you’ll learn about one bad middlebox the hard way).
  • Ignoring MTU/fragmentation realities for IKEv2.
  • Assuming “hybrid everywhere” is free. Hybrid exists for good reasons, but it adds complexity and payload size.
  • Focusing on certificates first for TLS PQC. For most orgs, the earliest practical wins are in key establishment negotiation, not CA signature algorithms.

FAQ

Is PQC in TLS 1.3 “standardized” yet?

Hybrid key exchange construction and specific hybrid groups combining ECDHE with ML‑KEM are standardized in IETF RFCs (RFC 9954 and RFC 10024, both 2026). There is also an IETF document to define ML‑KEM as NamedGroups for TLS 1.3 that, as of October 2026, is in the RFC Editor queue.

Why does IKEv2 PQC migration talk so much about MTU?

Because key exchange payload sizes can exceed typical path MTUs, and IKEv2 commonly runs over UDP across unpredictable networks. Fragmentation and packet loss behavior varies, so packet sizing becomes a first-order constraint rather than an implementation detail.

Is SSH ahead of TLS and VPN in PQC adoption?

In practice, yes – at least in the OpenSSH ecosystem. SSH has widely deployed hybrid key exchanges and has IETF RFCs documenting them (including 2026 RFCs), and OpenSSH provides clear operational guidance on which KEX algorithms it supports and prefers.

Do I have to deploy “PQC-only” to get value?

Not necessarily. Hybrid key exchange is widely used as a transition approach: the goal is that the session key remains secure if at least one component remains secure. That said, hybrids add complexity and can increase handshake sizes, so deploy them deliberately.

Where should we start if we’re overwhelmed?

Start with one protocol in a controlled environment:
* SSH on bastions is often the simplest,
* internal TLS (service-to-service) is often the next easiest,
* VPN/IKEv2 is often the most sensitive to network constraints and should be piloted carefully.

Further reading (primary sources)

Scroll to Top