Contact us
Partner Portal
< Blog

Start at the Pipes: Why QKD‑First Is the Level-headed, Safer On‑Ramp to Quantum‑Safe

HEQA_Blog_QKD_First_V1 (1)

If one routine software update can blue‑screen airports, banks, broadcasters, and hospitals worldwide, why is our “quantum‑safe” plan to do even more software surgery all at once? There’s a quieter path: start at the fiber, not at every endpoint.

Executive Summary

The prevailing playbook says: inventory all crypto, upgrade everything to PQC, and (maybe) sprinkle QKD on a few “niche” links later. It’s well‑intentioned—but expensive, slow, fragile to integration bugs, and it doesn’t immediately harden the places attackers covet most: the big inter‑data‑center pipes.1

PQC is essential and NIST’s 2024 standards (FIPS 203–205) are a milestone. But PQC migrations are not a cheap “software‑only” flip of a switch; they stress hardware/firmware, expand handshake sizes, and have already tripped middleboxes in the wild.2

QKD adds a layer PQC can’t: physically verifiable key delivery. It runs out‑of‑band, cushions uptime risk during change, and immediately hardens data‑in‑motion on your most valuable links (DC↔DC, DC↔cloud, HQ↔DC, backbone). You can deploy it first, with a low blast‑radius, then roll PQC across the estate methodically.

The world is already piloting and deploying QKD (EU testbeds and operator trials; U.S. DOE‑backed demonstrations; national programs in Japan, Singapore, South Korea; large‑scale China networks). Security agencies remain divided—but infrastructure programs and operators are gaining operational experience now.3

Yes, I have skin in the game—my day job is building quantum‑secure networks. If I thought “PQC everywhere, all at once” got you safer faster, I’d say so. The argument here is simple: QKD‑first + PQC‑next is the pragmatic sequence that reduces operational risk, buys resilience today, and lands you in the same end‑state—hybrid PQC+QKD—with less cost and drama.

What “Consensus” Says Today—and Where It Leans Too Hard on Software

Regulators led with PQC because it scales in principle without re‑pulling fiber. In 2024 NIST finalized ML‑KEM (key establishment), ML‑DSA (lattice signatures), and SLH‑DSA (hash‑based signatures) as FIPS 203–205. The UK’s NCSC, for example, has published a public roadmap toward broad PQC deployment (press reporting cited a 2035 completion horizon for large orgs). None of that is wrong. It’s just incomplete.4

The part that’s routinely glossed over: “software‑only” isn’t really software‑only.

  • Bigger messages & keys. FIPS 203’s ML‑KEM‑768 uses an 1184‑byte public key and 1088‑byte ciphertext; ML‑DSA‑65 (Dilithium‑level) signatures are ~3.3 KB with ~1.9 KB public keys. These are orders of magnitude larger than today’s X25519/ECDSA handshakes and signatures, with real knock‑on effects for devices and middleboxes.5
  • Real‑world breakage already happened. When Chrome/Cloudflare trialed hybrid post‑quantum TLS, some legacy routers and middleboxes choked on the larger handshake records—proof that “just a software update” can cascade into network hardware/firmware reality.6
  • Inventory first, then everything else. U.S. guidance (CISA/NIST/NSA) actually starts by telling you to build a full cryptographic inventory and design for crypto‑agility—a heavy lift before the first protected session flips to PQC.7

None of this argues against PQC. It argues against PQC‑everywhere‑first as your first move.

What QKD Adds (That PQC Cannot)

  • Physics‑backed key delivery. QKD uses single photons; any eavesdropping measurably disturbs the signal, so you know if the key exchange was tampered with. It’s information‑theoretic assurance, not a bet on unbroken math.
  • Out‑of‑band and low blast‑radius. QKD systems run beside the data plane on select links, so you can harden DC↔DC, DC↔cloud PoP (including AWS DirectConnect, Azure ExpressRoute and GCP Cloud Interconnect), HQ↔DC, and backbone segments without touching every workstation, app, and firmware image on day one.
  • Resilience under change. After last summer’s CrowdStrike incident, do you really want your first “quantum‑safe” step to be a sweeping software rollout across every Windows server, router, and application? The Falcon sensor content update crashed ~8.5 million Windows devices; airlines and hospitals felt it immediately. Start where you can add protection without risking uptime.8

I’ve unpacked this line of reasoning—and the U.S. agencies’ skepticism—before; the short version is that PQC and QKD are complementary layers, but they polarize if we force an all‑or‑nothing sequence.9

What the World Is Actually Doing

1. United States

  • Standards: NIST’s FIPS 203–205 are final—PQC is the official baseline. NSA’s CNSA 2.0 sets PQ timelines for national security systems. (NSA, notably, has long been cautious to negative on QKD for NSS.)10
  • Pilots and testbeds: DOE and ORNL demonstrated QKD‑secured links on a utility’s live fiber (EPB in Chattanooga), part of a broader “quantum internet” push. Translation: policy leads with PQC; R&D keeps advancing QKD for high‑assurance backbones.

2. European Union

  • Infrastructure: The EuroQCI program is building a pan‑EU quantum communications backbone with terrestrial and satellite segments, expanding the OPENQKD testbeds run with operators like Deutsche Telekom and Telefónica.11
  • Industry engagement: Consortia like QSAFE and Nostradamus (DT, Thales, AIT, Telefónica) are designing architectures and interoperability, including testing infrastructure for QKD devices.12
  • Security agencies’ posture: EU security services (BSI/ANSSI with NL/SE peers) still label QKD “niche” today—useful in specific point‑to‑point or defense‑in‑depth scenarios—while urging immediate PQC migration. That’s the tension: policy invests in QKD infrastructure while agencies stay PQC‑first.13

3. United Kingdom

  • Live networks: BT and Toshiba have run a quantum‑secured metro network in London (with EY as a first customer) and industrial deployments between research facilities.14
  • Policy: NCSC is pushing PQC and published a public roadmap (as reported) spanning to 2035 for large organizations—again indicating PQC baseline + selective high‑assurance overlays.15

4. Japan

  • Operational experience: NICT’s Tokyo QKD Network has been running since the 2010s, with current work integrating QKD into NTT’s All‑Photonics Network (IOWN) transport tech for coexisting high‑capacity data and quantum keying. Japan’s CRYPTREC also published updated PQC guidelines in 2024.16

5. Singapore

  • Regulator‑led adoption: The National Quantum‑Safe Network (NQSN/NQSN+) is trialing QKD and quantum‑safe communications for banks and critical infrastructure. The government committed ~S$300M for a National Quantum Strategy and S$100M via MAS’s FSTI 3.0 to spur quantum (incl. QKD) in finance.17

6. South Korea

  • Nationwide backbone: SK Broadband/ID Quantique built an ~800 km QKD network linking 48 government departments; SKT is active in standards work on combining QKD with PQC for quantum‑safe comms.18

7. China

  • Scale at country level: The integrated space‑to‑ground network combines a >12,000 km Beijing–Shanghai fiber backbone with satellite links, spanning ~12,900 km of QKD coverage for users—by far the world’s largest deployment. China is the only country mandating post quantum safe measurements be operational today in several critical industries (as opposed to readiness). And in fact, it’s explicitly mandating QKD. Not PQC.19

Software Isn’t “Free”: The Hidden Costs of PQC‑First

Let’s be blunt about the friction you’ll hit if you start by upgrading everything:

  • Inventory is mandatory and slow. Every credible roadmap begins with automated crypto discovery (where do you use RSA/ECC? which libraries? what versions? who owns them?). This eats calendar and budget before the first PQC handshake is live.20
  • Hardware/firmware realities. Larger keys and handshakes stress IoT, routers, and firewalls; even well‑resourced web stacks saw middlebox failures during PQC trials. Expect firmware updates, stack upgrades, and interop testing across vendors.21
  • Algorithm agility by design. NIST explicitly warns you to stay agile because even PQC algorithms may get retired. That means more migrations later. QKD keys don’t depend on unbroken math.22

I’m not arguing to avoid PQC. I’m arguing to sequence it after you lock down your biggest pipes with a technology that doesn’t threaten uptime while you change the engine mid‑flight.

A Practical Sequence: QKD‑First, PQC‑Next

Start where adversaries get the biggest payoff (and where your blast radius is smallest):

  1. Protect the core network.
    • DC↔DC cross‑connects
    • HQ↔DC
    • DC↔cloud on‑ramps
    • Backbone links
       These are the “big pipes.” QKD sits beside the data plane, immediately hardening key exchange for all flows traversing those links, regardless of what every application or TLS stack is doing today.
  2. Measure what matters.
     Track secure key rates, link stability, detected disturbances, and mean time to recovery for the quantum channel. Use those metrics to baseline resilience improvements.
  3. Layer PQC methodically.
     With the core protected, work through the crypto inventory and upgrade stacks to ML‑KEM/ML‑DSA/SLH‑DSA. If a software change goes sideways, your high‑value data‑in‑motion remains covered.
  4. End‑state: hybrid PQC+QKD, the defense‑in‑depth pattern the telecom world is already designing for (and standardizing toward).23

This sequence mirrors how operators in London, Berlin, Madrid and others are learning—deploy QKD on production fiber, then iterate.24

Start with QKD at the pipes and work your way outwards. Overlay PQC across the whole network afterwards.

Common Objections, Answered 

  • “Our national agency says QKD is niche.”
     Indeed, European security agencies (BSI/ANSSI, with NL/SE peers) emphasize PQC‑first and label QKD as “niche” today. Two things can be true at the same time: their caution on very broad replacement and the value of QKD as a defense‑in‑depth layer on the relatively small number of critical links. That’s exactly where I propose you start.25
  • “Trusted nodes weaken security.”
     Trusted relays are an explicit engineering trade‑off, not a fatal flaw—especially on operator‑controlled metro/backbone routes where rooms, racks, and routes are hardened. QKD with secure nodes protects those big pipes today; entanglement‑based QKD is a future upgrade that drives trust towards zero —not a prerequisite for real risk reduction now.26
  • “Isn’t QKD a science project?”
     It was. It isn’t. Look at the EuroQCI program, OPENQKD reports, BT/Toshiba London metro, NICT’s Tokyo network, SK Broadband’s 800‑km deployment, and DOE‑backed demonstrations. These are not lab curios—they’re how operators learn to run and maintain quantum‑safe backbones at scale.27
  • “What about uptime and risk?”
     Unlike PQC, QKD is implemented alongside, not in, the data path. If a QKD box reboots, you don’t blue‑screen your endpoints. Contrast that with the CrowdStrike SW update that knocked out ~8.5M Windows devices and grounded flights. Choose the first step that reduces operational risk while you modernize.28

Costs & ROI (The Part Your Board Will Ask)

  • PQC‑first front‑loads inventories, firmware upgrades, interop testing, and app refactors. Necessary, yes—but little immediate risk reduction for your highest‑value flows until it’s mostly done.29

  • QKD‑first focuses limited capex/opex on very few links with very high value, produces measurable assurance (eavesdropping is detectable), and doesn’t threaten SLAs while you migrate software. In other words: highest ROI to increase cybersecurity posture, lowest change risk—and it sets you up to add PQC cleanly.

Where This Goes Next (Entanglement & Integration)

The roadmap isn’t “QKD or PQC.” It’s QKD + PQC, then entanglement‑based networks as they mature. Japan’s NICT recently demonstrated integrating QKD with high‑capacity optical transport on NTT’s Open APN, and DOE’s blueprint work is pushing toward a U.S. quantum internet—both point to a future where classical and quantum layers co‑travel. Early QKD adopters will already have the operational muscle memory to upgrade.30 nict.go.jp

How I’d Brief a CISO in 15 Minutes

  1. Define crown‑jewel flows (DC↔DC, DC↔cloud, HQ↔DC).
  2. Deploy QKD on those links; integrate with existing key management/encryption for the data path.
  3. Run a cryptographic inventory and plan PQC upgrades with crypto‑agility in mind.31
  4. Sequence PQC rollouts app/domain by app/domain; monitor for regressions.
  5. Converge to hybrid (QKD‑protected key delivery + PQC in the protocols).
  6. Track KPIs (keying rates, disturbance events, handshake success rates, SLA impacts).

That’s it. Calm. Boring. Defensible.

Closing Thought

We all carry biases—mine included. But facts are stubborn things: PQC is necessary, and QKD is deployable now on the exact links that move your highest‑value data. You don’t have to choose; you have to sequence. Start at the pipes.

Author: Nir Bar Lev, CEO, HEQA Security

  1. https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography? ↩︎
  2. https://csrc.nist.gov/pubs/fips/203/ipd
    ↩︎
  3. https://digital-strategy.ec.europa.eu/en/policies/european-quantum-communication-infrastructure-euroqci?
    ↩︎
  4. https://csrc.nist.gov/pubs/fips/203/ipd ↩︎
  5. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf ↩︎
  6. https://quantum.lanl.gov/cryptography.shtml? ↩︎
  7. https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography? ↩︎
  8. https://www.reuters.com/technology/microsoft-says-about-85-million-its-devices-affected-by-crowdstrike-related-2024-07-20/? ↩︎
  9. https://heqa-sec.com/blog/the-peculiar-stance-of-nist-and-the-nsa-on-quantum-cryptography-and-why-theyre-wrong/ ↩︎
  10. https://csrc.nist.gov/pubs/fips/203/ipd ↩︎
  11. https://digital-strategy.ec.europa.eu/en/policies/european-quantum-communication-infrastructure-euroqci? ↩︎
  12. https://www.telekom.com/en/media/media-information/archive/deutsche-telekom-partners-quantum-communication-infrastructure-642332? ↩︎
  13. https://cyber.gouv.fr/sites/default/files/2020/05/anssi-technical_position_papers-qkd.pdf? ↩︎
  14. https://www.toshiba.eu/solutions/quantum/wp-content/uploads/resources/London-Quantum-Secured-Metro-Network.pdf? ↩︎
  15. https://www.theguardian.com/technology/2025/mar/20/uk-cybersecurity-agency-quantum-hackers? ↩︎
  16. https://www.itu.int/en/ITU-T/Workshops-and-Seminars/2023/0724/Documents/Kenyoshi.pdf? ↩︎
  17. https://nqsn.sg/? ↩︎
  18. https://www.idquantique.com/quantum-safe-security/nation-wide-quantum-safe-key-distribution-network-in-south-korea/? ↩︎
  19. https://merics.org/en/report/chinas-long-view-quantum-tech-has-us-and-eu-playing-catch ↩︎
  20. https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography? ↩︎
  21. https://quantum.lanl.gov/cryptography.shtml? ↩︎
  22. https://csrc.nist.gov/pubs/ir/8547/ipd? ↩︎
  23. https://www.cmorg.org.uk/sites/default/files/2025-06/CMORG%20-%20Guidance%20for%20Post-Quantum%20Cryptography%20-%20April%202025%20-%20TLP%20CLEAR%20%281%29.pdf? ↩︎
  24. https://www.toshiba.eu/solutions/quantum/wp-content/uploads/resources/London-Quantum-Secured-Metro-Network.pdf? ↩︎
  25. https://cyber.gouv.fr/sites/default/files/2020/05/anssi-technical_position_papers-qkd.pdf? ↩︎
  26. https://www.nict.go.jp/en/press/2025/09/16-1.html? ↩︎
  27. https://digital-strategy.ec.europa.eu/en/policies/european-quantum-communication-infrastructure-euroqci? ↩︎
  28. https://www.reuters.com/technology/microsoft-says-about-85-million-its-devices-affected-by-crowdstrike-related-2024-07-20/? ↩︎
  29. https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography? ↩︎
  30. https://www.nict.go.jp/en/press/2025/09/16-1.html? ↩︎
  31. https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography? ↩︎