Protecting the Network Before the Network Is Ready

At a glance

• Your board may not sign off on exposure that a feasible mitigation could reduce.
• The slowest dependency in your migration should not set the risk timeline for the data that crosses it.
• Waiting is not neutral. A later upgrade cannot protect traffic that has already been collected.
• An outside key source can bring protection forward on selected corridors and make the next cryptographic change less of a forklift.

The first installment in this series, The Four Clocks of PQC Migration — and Why They Don't Agree, ended on a design choice: let quantum-safe keying move on a different lifecycle from the infrastructure carrying the traffic. I asked you to hold that thought. Here is where it gets used.

A migration program can be on schedule and still leave material exposure in place. The plan for applications, certificates, VPNs and firewalls is credible, and the major suppliers are all heading towards post-quantum cryptography (PQC). Yet the interconnect carrying the longest-lived data still runs on encryptors with years of service life left and a native upgrade nobody can date. In my conversations with CISOs at large enterprises, this is the exposure that reaches the board agenda early, and the one boards are least comfortable accepting when a feasible mitigation exists.

That is the vendor clock and the execution clock at work, with the adversary clock ignoring both. Harvest-now-decrypt-later (HNDL) collection does not wait for anyone’s upgrade. What has been captured stays captured, and an upgrade planned for 2029 does nothing for traffic collected in 2027. Nobody has watched an archive get smaller.

So: does the most sensitive traffic really have to move at the speed of the slowest dependency in the estate?

Start where traffic aggregates

The first piece argued that the useful unit of prioritization is often the data flow, not the individual asset or endpoint. WAN backbones, data-center interconnects and private-cloud paths aggregate traffic from hundreds or thousands of applications. Thousands of endpoints may need to move over several years, and that plan remains active. Meanwhile, a far smaller number of corridors may carry a disproportionate share of the data that has to stay confidential longest.

Protecting a corridor does not make the applications behind it quantum-safe, and it does nothing for PKI, signing or traffic that takes another route. It reduces confidentiality exposure on that path while the wider migration carries on underneath. The test I apply: which corridors carry data whose confidentiality lifetime is longer than the migration path in front of them?

Three routes to protection

Stay with the interconnect. Native PQC may well be on the vendor roadmap, but the capability still has to reach each application, product family and hardware generation, then survive procurement, testing, change control and a production window. The last part is where programs quietly lose a year or two.

There are three routes from here:

1. Wait for native PQC. Protection starts when vendor support reaches the deployed product and hardware generation and your implementation is done. It is the longest trajectory of the three.
2. Accelerate selected corridors. Where native support already exists somewhere in the stack, move the highest-risk paths first. Upgrade software or protocol support, and replace only the device that blocks you. This is easier said than done across a heterogeneous estate, and hard to run as a coherent program.
3. Supplement the encryptor’s key establishment. Where the existing equipment accepts an external key, add PQC-derived material, with quantum key distribution (QKD) where the fiber and data lifetime justify it. Selected corridors move forward while the vendor and execution clocks keep running for the rest of the estate. It may be the least familiar of the three.

Put dates on it. Say the data must stay confidential until 2040 and native support reaches this hardware in 2029. Everything the corridor carries between now and 2029 stays exposed for its full lifetime, because nothing done in 2029 reaches back. Start now and the unprotected stretch shrinks to the time it takes to put the key path into service. The calculation needs no date for a cryptographically relevant quantum computer. It counts only what was carried before protection began.

The economics point the same way. The mitigation touches one layer: a key source and a policy layer feeding the encryptors you already own. It does not replace those encryptors, rewrite applications or wait for a refresh cycle. Set against the cost of the full migration program, it is a fragment, and it takes the longest-lived traffic out of the exposure window first. That ratio is hard to ignore.

Change where the keys come from

This is the part that gets lost when people say “PQC support”. AES-256 is not what Shor’s algorithm threatens. The vulnerable dependency that HNDL turns into a real exposure is how fresh keys are established. So leave the box alone and change where the keys come from. An existing encryptor can stay in place while an additional quantum-safe key source contributes to the session keying through a supported external interface.

Native PQC lives inside the vendor platform and follows its release, hardware and certification cycle. An external source can run the same NIST-standardized ML-KEM (FIPS 203) in a separate key-management layer and hand the result to an encryptor that already accepts outside keys. The math can be identical. The dependency is not: the key side no longer waits for that vendor’s native PQC implementation, neither in this migration cycle nor in the next.

At IonQ, Clarion KX provides that key-management and policy layer, and can combine external keys from PQC- and QKD-based sources. For IP-routed environments, the Solteris appliance hosts Clarion KX platform functions, underpinned by an embedded, NIST Entropy Source Validation (ESV) certified on IID SP 800-90B, quantum random number generator (QRNG) entropy source.

That creates two different kinds of value:

1. Earlier mitigation. Selected corridors gain quantum-safe key material while native migration continues across the wider estate.
2. Cryptographic agility. Once the external key path and policy layer exist, the next algorithm or standards rollover has another route into production without automatically triggering another infrastructure refresh.

The first reduces exposure ahead of the migration. The second turns the next cryptographic change from a multi-year forklift into something much closer to a policy update.

Long-lived data should not rest on one assumption

Once an external key path exists, it does not have to depend on one source. For many corridors, NIST-standardized PQC is enough. Others may use pre-shared material or hybrids. On a set of controlled-fiber corridors, QKD adds a further option, alongside PQC and never instead of it.

Standardization does not retire assumption risk. On 1 October 2026 Germany’s Federal Office for Information Security (BSI) advised against new Classic McEliece deployments after fresh cryptanalysis put its security level substantially below what had been assumed, months after the algorithm was standardized in ISO/IEC 18033-2. BSI reports no practical attack on the recommended parameters. That is not the point. Cryptographic assumptions can move faster than deployed infrastructure.

Combine PQC-derived material with another PQC family, or with QKD-derived material, and defeating one source is no longer enough to recover the key. Nobody can tell you which assumption fails next, and I would rather not find out with the longest-lived data riding on one.

QKD carries a more persistent benefit. Its key secrecy rests on physics, not computational hardness, so it does not weaken when an algorithm family does. That matters most on the few corridors carrying data that has to stay confidential for decades.

QKD’s best-known objection is the trusted relay: over long distances, intermediate nodes sit in the key path. In Clarion KX, the user key remains end-to-end protected with NIST-aligned algorithms as it crosses relay nodes, while QKD secures each segment beneath it. The relays remain trusted infrastructure, but the risk at trusted-relay locations is minimized.

Field-proven, partner-supported

Large out-of-band key-delivery solutions have been in production in high-SLA telecom environments for over four years, on links ranging from a couple of hundred to 1,770 kilometers across various topologies. They work with the encryptors and optical platforms those networks already run.

JPMorgan Chase demonstrated this out-of-band architecture in a financial setting with its 100 Gbps Quantum-safe IPsec VPN Tunnels deployment.

The external-key interfaces on major vendors’ encryptors are generally available through standard or established vendor mechanisms. Treat interoperability as an architecture-review question and check it against the equipment in your estate.

The value changes as the migration catches up

The early risk-reduction benefit shrinks as applications, TLS stacks and network platforms gain native protection. That is what success looks like. Two things keep paying: the agility described above, and assurance diversity on the longest-lived data, where combining different PQC families or QKD-derived material means the key does not depend on one class of assumption.

Three questions for your next review

1. Which corridors carry data that outlives the migration path in front of them?
2. Where are you waiting on a vendor, hardware or execution dependency when the existing encryptor could already accept an external key?
3. What share of your longest-lived traffic still depends on a single class of cryptographic assumption?

The date on which the whole network becomes quantum-safe and the date on which you can begin protecting its highest-value traffic do not have to be the same. Your board may well agree.

Simon Patkovic
Field Quantum Security Officer, IonQ

Frequently asked questions

Can you protect a network corridor before the vendor ships native PQC?
Where the existing encryptor can accept an external key, yes. Key material is supplied through a supported external interface and contributes to the session keying, while the native protocol stays in place. Support varies by product family and software release, so check it against the equipment you actually run.

Does AES-256 have to be replaced to be quantum-safe?
Generally not. The quantum-vulnerable part of an encrypted link is how the keys are established, not the symmetric cipher carrying the data. That is why the intervention can sit in the key supply and leave the encryptor where it is.

What happens to a corridor if the external key feed is lost?
That is a policy decision per path. Clarion KX pre-builds keys and buffers them locally in a secure enclave, and supports backup delivery paths. If the feed is lost entirely, a path can fail open to its native key establishment, which keeps traffic flowing and the service level intact, or fail closed. Either way it should raise an alert.

Is there a performance penalty to IonQ’s out-of-band key distribution solution?
No. Key delivery is out of band, so the data path is untouched: no added latency, no change to throughput, and no change to the encryptor configuration. If the key feed is interrupted, the encryptor continues on its native key establishment, so the traffic SLA does not depend on the key service. Failing closed is the one exception, and it is a policy choice you make per path.

‍