Quantum Key Distribution Implementation: When and How to Deploy QKD Alongside PQC Migration

Security architects at finance, government, and defense organizations increasingly get asked some form of "should we be doing QKD too" once PQC migration is underway. The honest answer starts with what QKD is actually for. PQC migration changes the math inside your existing TLS, VPN, and code-signing infrastructure, so it scales the way software scales: you update libraries, reissue certificates, and roll it out across thousands of endpoints and connections. QKD does none of that. It distributes a symmetric key between two specific physical endpoints over a dedicated optical path, using the fact that measuring a quantum state disturbs it to detect eavesdropping on the key exchange itself.

That means QKD is only ever a candidate for a small, specific set of point-to-point links: a link between two data centers carrying the highest-classification traffic, a backbone segment connecting a trading floor to a clearing system, or a connection between a government facility and a secure remote site. It is not a technology you deploy to a remote workforce, a SaaS application, or a normal enterprise WAN. If your problem is protecting encrypted traffic across a general-purpose network, PQC migration is the answer, and QKD does not enter the picture at all.

The practitioner decision this guide addresses is narrower: given a specific, named point-to-point link that already carries your organization's most sensitive traffic, is the added assurance of QKD worth the cost and operational overhead of dedicated optical hardware, on top of the PQC migration you should be doing regardless.

Before evaluating hardware, confirm the following about the specific link in question. QKD deployments that skip this step tend to end up as expensive science projects rather than operational security controls.

1. The link is a genuine point-to-point path, not a mesh requirement. QKD is fundamentally two-endpoint technology. If the traffic you are trying to protect needs to reach more than two sites, you are looking at a QKD network (ring, hub-and-spoke, or meshed topology with trusted nodes at each hop), which multiplies both cost and the trust assumptions described below.
2. You control, or can acquire, dedicated dark fiber (or a qualifying free-space path) between the two endpoints. QKD signals travel over their own optical channel. Direct fiber QKD has a practical range of roughly 60 to 150 kilometers before photon loss degrades the key rate past usability, so confirm the physical distance and fiber loss budget between your actual endpoints before evaluating vendors.
3. The traffic on this link genuinely justifies a physics-based key exchange guarantee, not just a policy preference. This is usually classified government communications, the highest tier of financial transaction data, or critical infrastructure control links, the same categories ID Quantique and other vendors cite as the realistic QKD market: telecom backbones, financial services, and government and defense.
4. You have a plan for authentication of the classical channel. QKD protocols still require an authenticated classical communication channel to coordinate the quantum exchange and detect tampering; this authentication itself needs to be secured, typically with short pre-shared keys or digital signatures, so QKD does not eliminate your need for a broader key management and authentication strategy.
5. You have accepted that distances beyond the direct-fiber range require trusted nodes or satellite relay, each with its own trust model. If your two endpoints are farther apart than the fiber range supports, the key has to be relayed through intermediate trusted nodes (each of which must be physically and operationally secured, since it briefly holds the key in the clear) or through an emerging satellite QKD path such as the EAGLE-1 mission Europe is planning as part of EuroQCI. Confirm which model applies to your geography before budgeting.
6. PQC migration for this link and its surrounding environment is already planned or underway. QKD protects the key exchange on one specific optical path. Everything else, the endpoints' software stack, certificate chains, key management systems, and every other link in your network, still needs PQC algorithms. Treat QKD as an addition to that migration, never a substitute for it.

1. Map the physical path and measure fiber loss. Work with your carrier or dark fiber provider to get the actual span distance and attenuation (dB loss) between the two endpoints. This determines whether you fit within the direct point-to-point range or need trusted-node relay points, and it is the single input vendors need first to quote a viable design.
2. Select a QKD protocol and hardware platform. The dominant deployed protocols are BB84 and its decoy-state variant, which add randomly varied signal intensities to detect photon-number-splitting attacks that a naive BB84 implementation is vulnerable to on lossy real-world fiber. Vendors including ID Quantique, Toshiba, and QNu Labs sell commercial QKD systems built on these protocols; evaluate based on your required key refresh rate, supported distance, integration with your existing key management infrastructure, and compliance with standards such as ETSI GS QKD 014 for the key delivery API, since a system that cannot expose keys through a standard interface will be harder to integrate with the encryptors actually consuming them.
3. Provision the dedicated optical channel. QKD requires its own fiber strand or wavelength, separate from your data traffic, since the quantum signal cannot share a channel with conventional high-power optical data traffic without being drowned out. Confirm with your fiber provider whether you are getting dedicated dark fiber or a wavelength on a shared DWDM system, and whether the provider's infrastructure is compatible with QKD's optical requirements.
4. Install and secure the physical endpoints. QKD transmitter and receiver units, and any trusted-node relay hardware, must be installed in physically secured, access-controlled facilities. A trusted node briefly holds the key in the clear during relay, which makes physical security of that node equivalent in importance to the security of a data center holding your root keys, not an incidental network closet.
5. Establish and authenticate the classical control channel. Configure the authenticated classical channel QKD uses to coordinate basis reconciliation, error correction, and privacy amplification with the vendor's management platform (for example, ID Quantique's Clarion KX or the equivalent from your chosen vendor). Confirm this channel's authentication mechanism is itself properly keyed before going further.
6. Integrate QKD-derived keys with your encryptors. Wire the QKD system's key output, typically delivered through a REST API conforming to ETSI GS QKD 014, into the encryption devices actually protecting the link (dedicated QKD-enabled encryptors, or IPsec/MACsec devices that support pulling keys from an external QKD key management system rather than generating them internally).
7. Run parallel operation against your existing classical key exchange during cutover. Do not cut over the live link to QKD-derived keys until you have validated key delivery, refresh timing, and failover behavior against your existing classical (or PQC-based) key exchange running in parallel on a test path.
8. Document the trust boundary for every trusted node in the path. For any link that requires intermediate trusted nodes, record who operates each node, what physical and personnel security controls apply, and what your incident response plan is if a node's physical security is ever suspected to be compromised.

Confirm the quantum bit error rate (QBER) is within the vendor's specified operating range on your actual fiber, not a lab benchmark. QBER is the primary signal QKD uses to detect eavesdropping, and real-world fiber loss, connector quality, and environmental noise all affect it. Have the vendor or your own team measure QBER on the installed link before relying on it operationally, and confirm the system correctly aborts key generation when QBER exceeds the security threshold.

Validate key refresh rate against your actual encryption throughput requirements. QKD key generation rates are lower than data throughput rates on the link, so confirm the achieved key rate on your installed hardware is sufficient to refresh session keys (for example, AES-256 keys) at the frequency your security policy requires, not just the vendor's best-case published rate.

Test the authenticated classical channel independently. Confirm the classical channel used for basis reconciliation and error correction is itself authenticated correctly, and that a tampering attempt on the classical channel is detected and blocks key delivery, since a compromised classical channel undermines the security guarantee QKD is meant to provide.

Verify trusted-node behavior under simulated failure. For any deployment using relay nodes, test what happens to key delivery and to the security posture of the link if a trusted node goes offline, loses power, or is physically tampered with (where tamper-evidence is supported by the hardware). Confirm your operational team has a documented response, not just a hardware alert.

Confirm PQC coverage of everything QKD does not touch. Validate that the endpoints, management plane, and every other link touching this traffic are on the PQC migration track described in our PQC migration guide. QKD securing one optical hop does not validate the security of anything else in the path.

Treating QKD as sufficient on its own. The most common conceptual failure is deploying QKD on one link and considering that segment fully quantum-safe. QKD secures key distribution on that specific optical path; it does nothing for the endpoints' software stack, the authentication of the classical channel, or any other link the traffic touches. Every one of those still needs PQC algorithms.

Underestimating distance and discovering trusted nodes were required after budgeting. Teams that plan a QKD deployment based on straight-line distance between two facilities, without accounting for actual fiber routing and loss, frequently discover mid-project that their real fiber path exceeds the practical direct range and now requires one or more trusted nodes, each adding cost and a new physical security obligation that was not in the original budget or risk assessment.

Compromised or poorly secured trusted nodes. A trusted node holds the key in the clear during relay. If its physical security is weaker than the endpoints it connects, it becomes the weakest link in a system that was deployed specifically because the organization needed the strongest possible link. This is a real architectural cost of any QKD network topology beyond a single direct point-to-point hop, not a hypothetical edge case.

Classical channel authentication treated as an afterthought. Because QKD's headline property is quantum-detected eavesdropping on the photon channel, teams sometimes underinvest in securing the ordinary classical channel QKD still depends on for coordination. A weakly authenticated classical channel undermines the entire deployment regardless of how well the quantum channel performs.

Deploying QKD where PQC alone would have been sufficient and cheaper. For the large majority of links, including most enterprise WAN and VPN traffic, software PQC migration achieves the required security level without dedicated fiber, specialized hardware, or the physical security obligations trusted nodes introduce. QKD projects that get approved based on the technology's novelty rather than a genuine gap in what PQC covers tend to consume budget that would have covered PQC migration across a much larger portion of the environment.

QKD's core guarantee, information-theoretic security of the key exchange based on the physics of quantum measurement, is real and does not depend on computational hardness assumptions the way both classical and post-quantum cryptography do. That is the property that makes it attractive for the highest-sensitivity links: even a future quantum computer with capability beyond anything publicly demonstrated cannot retroactively break a properly executed QKD key exchange the way it could break RSA or ECDH captured today for later decryption.

That guarantee comes with real constraints that PQC does not have. QKD requires dedicated physical infrastructure (fiber or free-space optical paths) that cannot be virtualized, patched, or rolled out over existing networks the way software can. It is inherently point-to-point, so anything beyond a single link multiplies cost and introduces trusted-node trust assumptions. It depends on an authenticated classical channel whose own security is a separate problem to solve. And it protects only the key exchange, not the confidentiality or integrity of anything else in the system, including the very endpoints generating and consuming the keys.

For almost every organization, the correct sequencing is PQC migration first and everywhere, with QKD considered afterward, and only for the specific links where the traffic sensitivity, available fiber, and budget genuinely justify dedicated quantum hardware. Our CNSA 2.0 compliance guide covers the algorithm-level requirements that apply regardless of whether QKD is ever deployed.