Hybrid deployment: running classical and PQC side by side
Hybrid combines a classical algorithm with a PQC one so security holds if either survives. Why it's the default transition state for key exchange, when it applies to signatures, and the risks to manage.
Hybrid buys insurance during the uncertain middle
A hybrid construction runs a classical algorithm and a post-quantum one together and combines their outputs, so the result is secure if either component is. For key exchange it is the mainstream transition strategy — it protects against harvest-now-decrypt-later immediately while hedging against a newly discovered flaw in a young PQC algorithm. For signatures the calculus differs, because hybrid roughly doubles size and cost.
PQC algorithms are new, and new cryptography sometimes breaks — the PQC selection process itself saw candidates fall to classical attacks late in the game. Hybrid deployment is the hedge: by requiring an attacker to break both a well-understood classical algorithm and the new PQC one, you get post-quantum protection now without betting everything on an algorithm that has had far less cryptanalysis than RSA has endured.
Hybrid key exchange
The canonical case is TLS: a hybrid named group like X25519MLKEM768 performs both an X25519 exchange and an ML-KEM-768 encapsulation, then combines the two shared secrets into one session key. Break only the classical half (with a future quantum computer) and the ML-KEM half still protects the key; find a flaw in ML-KEM and X25519 still protects it. This dual assurance is exactly why hybrid is the default for confidentiality during the transition — the stakes (retroactive decryption of harvested traffic) are high and the PQC algorithms are still maturing.
Hybrid signatures — a genuine trade-off
For signatures the argument is weaker. A hybrid signature (classical + PQC) means two signatures to generate, transmit, and verify — roughly doubling size and cost — and signatures are not subject to harvest-now-decrypt-later, so the urgency that drives hybrid key exchange does not apply. The reasonable positions are: use hybrid signatures where the artifact is extremely long-lived and you want maximum hedge (roots of trust, firmware), and accept pure PQC signatures elsewhere once you trust the algorithm. Decide per domain and record the rationale.
A hybrid that can be stripped to classical isn't hybrid
The security of a hybrid rests on an attacker being forced to break both components. If the protocol lets an active attacker negotiate away the PQC half and fall back to classical-only, you have downgrade risk that defeats the purpose. Ensure the combiner binds both shares together and that negotiation has a floor preventing a silent drop to classical-only when both sides actually support PQC.
Operational realities of running two algorithms
- **Larger messages** — hybrid handshakes carry both key shares, increasing bandwidth and sometimes packet counts; validate against MTU and middleboxes.
- **More CPU** — you run two exchanges instead of one; measure the cost, which is usually modest but non-zero.
- **Combiner correctness** — the way the two secrets are combined must be a standardized, secure construction, not an ad-hoc concatenation.
- **Clear exit criteria** — decide in advance what would let you drop the classical component and go pure-PQC, so hybrid is a transition state, not a permanent one.
Think of hybrid as the shape of the migration's middle years, not its end state. You adopt it to be safe while the standards settle and the algorithms accumulate cryptanalysis; you plan, from the start, for the conditions under which you would simplify back to a single (post-quantum) algorithm.