Post-quantum TLS for defense APIs: hybrid handshakes in production

Every defense API in production today is protected by a key exchange – typically X25519 or an elliptic curve – that a sufficiently capable quantum computer will eventually break. That machine does not exist yet, but the data crossing those APIs has a confidentiality lifetime measured in years or decades. An adversary can record the encrypted traffic now and decrypt it later, once the hardware arrives. Post-quantum TLS closes that window by adding a quantum-resistant key encapsulation mechanism to the handshake. This article covers how to deploy it on real defense APIs: the hybrid ML-KEM handshake, the certificate question, the performance and bandwidth impact, and a phased rollout that does not break a single existing client.

The harvest-now-decrypt-later threat model

The reason post-quantum TLS is urgent has nothing to do with whether a cryptographically relevant quantum computer exists today. It is about the asymmetry between when data is captured and when it is decrypted. An adversary with the resources to tap and store traffic can archive the encrypted sessions of a defense API indefinitely. The moment a quantum computer capable of running Shor's algorithm at the required scale becomes available, every stored session whose key exchange used a classical algorithm is retroactively exposed. We treat this quantum threat timeline in depth elsewhere; the operational takeaway for an API team is simple. If your data must stay secret beyond the arrival of practical quantum computing, the migration cannot wait for that arrival – by then the captured traffic is already compromised.

This is why authentication and confidentiality have different urgency. A forged signature only matters at the moment of the connection – a quantum computer that breaks signatures in 2035 cannot retroactively forge a 2026 handshake that already completed. Confidentiality is the opposite: it must hold for the entire retention life of the data. Post-quantum TLS therefore prioritizes the key exchange first and defers the signature migration, which is exactly the sequencing CNSA 2.0 and the broader standards bodies recommend.

Hybrid handshakes: belt and suspenders

The standardized post-quantum key encapsulation mechanism is ML-KEM (FIPS 203, derived from CRYSTALS-Kyber). In principle a TLS 1.3 handshake could use ML-KEM alone. In practice, defense deployments use a hybrid handshake that runs ML-KEM and a classical algorithm together and combines their outputs.

The mechanism is straightforward. During the TLS 1.3 key exchange the client and server each derive two shared secrets – one from the classical algorithm (X25519) and one from ML-KEM-768. The two secrets are concatenated and fed into the TLS key schedule as a single combined secret. The session key is therefore derived from both. An attacker must break both algorithms to recover the session: the classical one resists today's adversaries, and ML-KEM resists a future quantum adversary.

The hybrid approach is deliberately conservative. ML-KEM is new, and the cryptographic community's confidence in any algorithm grows with years of scrutiny. Combining it with the battle-tested X25519 means that even if an implementation flaw or unexpected weakness is later found in the post-quantum component, the session is no weaker than today's classical TLS. The cost of carrying both is modest, and for defense workloads the conservatism is worth it.

The named group: X25519MLKEM768

In TLS 1.3 the hybrid construction is exposed as a single named group in the supported_groups extension. The widely deployed form is X25519MLKEM768, which pairs X25519 with ML-KEM-768 (the security-level-3 parameter set, appropriate for most CNSA 2.0 targets). The server advertises the group, the client offers a key share for it, and negotiation proceeds exactly as it does for any other group. Crucially, this means hybrid TLS slots into the existing TLS 1.3 negotiation machinery – there is no new protocol layer, only a new group identifier and a larger key share.

Performance and bandwidth: where the cost actually lands

A common assumption is that post-quantum cryptography is slow. For ML-KEM that is wrong. The lattice operations behind ML-KEM-768 key generation, encapsulation, and decapsulation are fast – frequently faster than the elliptic-curve scalar multiplication of the classical algorithm they accompany. On a modern server core, the ML-KEM operations in a hybrid handshake add well under a millisecond. CPU is not the constraint.

The real cost is bytes on the wire. An ML-KEM-768 public key is about 1184 bytes and the ciphertext about 1088 bytes. Added to the classical X25519 share, the hybrid key exchange contributes roughly 2.3 KB across the ClientHello and ServerHello. The consequence that matters operationally: the ClientHello, which is comfortably under 1400 bytes with classical-only groups, now exceeds a single network packet. On a clean network this is invisible. On a lossy or constrained link – a satellite backhaul, a congested tactical radio bearer – the extra packet introduces a new opportunity for loss and retransmission, and the handshake-failure tail can grow.

This reframes the rollout risk. The thing to measure is not handshake CPU time but ClientHello fragmentation behavior and middlebox tolerance across the specific network paths a defense API actually serves. An API that is only ever reached over a healthy data-center fabric will see essentially no impact; one reached from disadvantaged tactical links needs careful validation before the hybrid group is turned on.

The certificate question: confidentiality first, authentication later

A frequent point of confusion is whether deploying post-quantum TLS requires reissuing every certificate. For the first phase, it does not. The hybrid handshake protects the key exchange – the part of TLS that establishes the session's confidentiality – and that is the only part exposed to the harvest-now-decrypt-later attack. Server authentication continues to use the existing RSA or ECDSA certificate chain.

There is a practical reason to defer signature migration beyond the threat-model argument. The standardized post-quantum signature algorithms, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), produce far larger signatures and public keys than ECDSA. A certificate chain built on ML-DSA can be an order of magnitude larger, which inflates every handshake and stresses constrained clients. The certificate-authority ecosystem, the browser and OS trust stores, and most client TLS stacks are not yet ready to validate post-quantum signature chains at scale. Forcing post-quantum authentication today would break far more than it protects.

The correct sequencing, consistent with the CNSA 2.0 guidance for defense, is therefore: deploy hybrid key exchange now to defeat harvest-now-decrypt-later, keep classical authentication, and migrate signatures to ML-DSA in a separate, later phase once the CA chain and your client population can support it. Treating these as two independent migrations is what keeps each one tractable.

Phased rollout without breaking clients

The single most important principle for a non-disruptive rollout is that the hybrid named group must be additive. You enable X25519MLKEM768 alongside the classical groups, not instead of them. TLS 1.3 group negotiation is backward compatible by design: a modern client that offers the hybrid group gets it; an older client that offers only X25519 falls back cleanly to the classical group on the same endpoint. No client is broken by the server simply knowing how to speak a new group.

From there, the rollout is an exercise in measurement. First, inventory every TLS termination point – edge load balancers, API gateways, service-mesh sidecars, origin servers – and the crypto library at each, because the upgrade story is only as good as the least-capable terminator. A hardware appliance with frozen firmware that cannot speak ML-KEM becomes the gating constraint and must be identified before any promises are made.

Second, turn the hybrid group on in additive mode behind a feature flag and instrument the negotiated key-exchange group for every completed handshake. That telemetry tells you the real fraction of traffic already protected and surfaces the clients and networks that never upgrade. Third – and only once telemetry shows near-universal hybrid negotiation on a route – you may optionally enforce the hybrid group on the highest-sensitivity endpoints by removing classical fallback there, while the rest of the API stays additive. Enforcement is the last step, applied narrowly, with a tested rollback to additive mode always available.

This sequencing matters for the same reason it does in any cryptographic migration program – the migration is a long-lived, reversible state transition, not a switch. For organizations planning the broader cryptographic transition around their APIs, the CNSA 2.0 migration roadmap places TLS key exchange in the context of the full algorithm inventory and timeline.

Operational guardrails for defense APIs

Beyond negotiation, a few guardrails separate a hardened deployment from a fragile one. Pin the minimum protocol to TLS 1.3 on post-quantum-capable routes; the hybrid construction only exists in 1.3, and allowing a downgrade to 1.2 reintroduces a classical-only key exchange. Disable session-resumption paths that would let a connection skip a fresh hybrid key exchange unless the resumption itself carries forward post-quantum protection. And ensure your observability stack records both the TLS version and the negotiated group, so that a regression – a library downgrade, a misconfigured gateway – shows up as a drop in hybrid share rather than silently reverting your APIs to classical-only confidentiality.

Crypto-agility is the property that makes all of this maintainable over the multi-year horizon the migration actually spans. ML-KEM-768 is the right parameter set for most defense APIs today, but the standards will evolve, named groups will be added, and your highest-classification routes may eventually require ML-KEM-1024. Configuration, not code, should decide which groups an endpoint offers, so that raising the post-quantum security level or retiring a deprecated group is an operational change rather than a redeployment. The same agility applies in reverse: if a flaw is found in a deployed group, you want to disable it across the fleet in minutes. Treat the supported-groups list as a managed, versioned policy, and your APIs stay quantum-safe through the entire transition rather than at a single point in time.

Testing the rollout before it reaches production

Validate the hybrid handshake against the full diversity of your client population before enabling it broadly. Stand up a staging endpoint that offers X25519MLKEM768 additively and drive it with every client type that touches the API in the field – current SDKs, embedded clients on constrained hardware, and any third-party integrators. Record the negotiated group for each so you know which clients upgrade and which silently stay classical. Pay particular attention to clients behind inspection proxies or government gateways, because those are where the enlarged ClientHello is most likely to be dropped. A staging pass that exercises the real network topology, not just a clean lab link, is what lets you enforce hybrid on a sensitive route later with confidence rather than hope.