Hybrid vs. pure PQC: how to sequence a safe cutover

Connect to a modern browser and the TLS handshake you get may already carry two key exchanges: X25519 and ML-KEM-768, combined so that breaking either one is not enough. That hybrid is not a compromise between old and new. It is a specific engineering decision about what happens if one of the two algorithms turns out to be weaker than believed.

Most organizations will run hybrid before pure post-quantum cryptography, and the sequencing is where migrations stall. The choice is not ideological. It depends on who controls the other end, how long the data must stay secret, and what your verifiers accept.

Hybrid is a hedge, not a destination

A hybrid group runs a classical key exchange and a post-quantum key encapsulation in parallel, then combines both shared secrets through a key derivation function. The session is secure if either component holds. Combined groups such as X25519MLKEM768 are specified in IETF drafts and implemented in major TLS stacks, which is why hybrid is available now rather than after a standards cycle.

The hedge cuts both ways. It protects you against a quantum attack on the classical exchange, and against an unexpected weakness in ML-KEM. What it does not do is remove the classical algorithm from your compliance evidence, which matters if your obligation names ML-KEM.

Where hybrid is the right default

Hybrid key exchange belongs wherever you do not control both endpoints.

External TLS: browsers, partner APIs, mobile applications, and device fleets on refresh cycles you do not set.
Long-confidentiality data: traffic that must stay secret for a decade or more, where you want the classical layer to keep protecting it if ML-KEM is broken.
Anywhere a downgrade to classical must remain possible for a defined window without a code change.

The common property is uncertainty about the peer. Hybrid lets you make progress without requiring the other side to upgrade first.

Where pure PQC is expected

Pure post-quantum cryptography means no classical component in the exchange or the signature. There are places where that is the expected answer rather than an option.

National security systems. CNSA 2.0 approves ML-KEM and ML-DSA, and new acquisitions are expected to be compliant by default from January 1, 2027. If you sell into that market, your evidence will name those algorithms, not a hybrid construction.

Closed ecosystems. When both ends are yours and upgradable on your schedule, the compatibility argument for hybrid disappears and the extra bytes are pure cost.

Signature chains with constrained verifiers. A firmware bootloader has a fixed memory budget. Two signatures may not fit, which pushes you toward one post-quantum signature rather than a dual scheme.

Hard classical sunsets. NIST IR 8547, still an initial public draft, proposes deprecating classical public-key algorithms after 2030 and disallowing them after 2035. A hybrid that retains a classical component is transitional, not a compliant end state under that proposal.

The costs are measurable, so measure them

Dimension	Hybrid	Pure PQC	What to test
Key share size	Roughly 1.2 KB extra per side for ML-KEM-768	Same post-quantum share, no classical share	ClientHello size and packet count
Certificate size	Classical or dual chains	ML-DSA signatures measured in kilobytes	Chain depth times signature size
Handshake latency	Usually no extra round trip, more bytes	Similar	Lossy and high-latency links

Two effects deserve attention before a pilot. A ClientHello large enough to exceed the initial congestion window can require an extra flight on lossy links, which shows up as latency rather than failure. TLS inspection appliances that do not recognize a new group may fail the handshake or silently negotiate something else, which is worse because it looks like success. Measure both with the inspection stack you deploy, not with a clean lab path.

Certificates complicate what key exchange does not

Key exchange is per-session and ephemeral, which makes it the easy half of the migration. Certificates are identity: chained, cached, pinned, distributed to trust stores, and validated by code you may not control.

An ML-DSA leaf certificate requires the client to support ML-DSA in path validation. Older clients fail closed, at connection time, with an error your support desk will see.
Chain size multiplies. Three certificates, each carrying a post-quantum signature and public key, produce a handshake that no longer fits comfortably in a single flight.
Trust store distribution has its own cadence: operating system roots, browser roots, Java trust stores, container base images, device firmware. Each is a separate project with a separate owner.
Dual-certificate serving, classical for old clients and post-quantum for new ones, requires a selection mechanism such as SNI-based routing, and a way to know which population is which.
Revocation infrastructure signs things too. A CRL signed with RSA is a signature that outlives its algorithm, and OCSP responders need the same treatment as the certificates they describe.

Key exchange and certificate migration are separate programs with separate dates. Treating them as one is the most common planning error here.

Rollback has to be designed before the pilot

Hybrid is popular partly because it is reversible. Make the reversibility real.

Keep the classical group in the preference list during the pilot. Put the switch at the termination layer, not in application code, so reverting is a configuration change. Monitor handshake failure rate by client type, because a small percentage of failures is a support queue rather than a metric. Name the rollback trigger and the person who can pull it before the pilot starts.

One caveat that rarely appears in runbooks: rolling back to classical is safe for availability and unsafe for confidentiality. If a flow carries data with a fifteen-year confidentiality requirement, reverting re-exposes it from the moment of the change. Rollback decisions need a data class attached, not just an error rate.

A four-stage sequencing model

Stage one: pilot. One internal service, one instrumented client population, hybrid TLS, with failure rate and latency measured against a classical baseline. The output is evidence, not a press release.

Stage two: hybrid by default externally. Enable hybrid for all external TLS termination. Keep classical available for named exceptions, each with an owner and an expiry date, and report the exception list monthly so it shrinks.

Stage three: pure PQC where required. National security systems, closed ecosystems, and new deployments where both ends are yours. Signature migration lands here too, since verifier constraints usually force a single algorithm rather than a dual scheme.

Stage four: decommission classical. Remove classical-only cipher suites and certificates, with a documented exception list tied to a date. NIST IR 8547 points at 2035, and treating that as the outer boundary rather than a target keeps the program honest.

Each stage needs a gate: the CBOM updated, monitoring in place, rollback tested. A stage that ends without those is a stage you will repeat.

Diversity is the reason to keep the cutover reversible

NIST selected HQC in March 2025 as a backup key encapsulation mechanism, and its standard is still in development. The argument for caring is concentration risk: ML-KEM’s security rests on module-lattice problems, and a cryptanalytic advance would affect every deployment at once.

Hybrid with a classical algorithm is one hedge. A second, structurally different post-quantum algorithm is another. That is a decision for the late 2020s, but it is only available if your architecture can swap a KEM without a code change in five services.

That is the real deliverable. Not the winning algorithm, but the ability to change your mind on a schedule you control: algorithm choice in configuration, recorded in the CBOM; libraries with post-quantum support and a validated module path; certificate profiles that can carry new algorithms; and a harness that pushes a candidate through the pipeline before production.

Teams with that capability will absorb HQC, a revised ML-KEM parameter set, or whatever else the standards bodies produce. Teams without it will treat each of those as a re-architecture.