The Practical Limitations of QKD in Enterprise Environments

Quantum key distribution has appeared in enough vendor pitches and government briefings that security teams now need a grounded technical view of what it actually delivers. The protocols are elegant, and the physics is real. The problem is the distance between the idealised protocol security proof and a working enterprise deployment.

Three major national security agencies have publicly declined to recommend QKD for production systems: the NSA (August 2021), the UK's National Cyber Security Centre (2020), and Germany's BSI (2020). Their objections are specific and technical, not precautionary. Understanding those objections is more useful than accepting or dismissing QKD on principle.

This article places QKD accurately in the current landscape. It is not a dismissal of the technology. It is an honest assessment of why NIST-standardised post-quantum cryptography, specifically ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), finalised in August 2024, constitutes the practical migration path for enterprises today, while QKD remains a niche technology for specific, well-resourced use cases.

What QKD Actually Guarantees, and What It Does Not

The Information-Theoretic Security Claim

Quantum key distribution protocols, including BB84 (Bennett and Brassard, 1984) and E91 (Ekert, 1991), use the quantum properties of photons to establish a shared secret key. Polarisation states and the no-cloning theorem make any eavesdropping attempt physically detectable: measuring a photon disturbs it, leaving a signature in the error rate. The unconditional security proof is mathematically real and it applies to the quantum channel and the key establishment step.

The scope of that proof matters. It does not extend to the classical encryption layer that uses the generated keys. In a working QKD deployment, the established keys feed into AES-256-GCM for bulk encryption. The quantum channel secures key generation. The classical layer secures the data. If the classical implementation is flawed, the quantum security guarantee does not help.

Side-channel attacks illustrate this gap. They target the physical hardware implementing the protocol, not the protocol itself. Measurement-device-independent QKD (MDI-QKD), developed by Lo, Curty, and Qi in 2012, was designed specifically to address detector vulnerabilities, confirming that real implementations diverge from idealised security models in ways that require additional protocol engineering.

Decoy State Protocols and the Residual Gap

Practical QKD systems cannot produce true single photons. They use weak coherent pulses, which occasionally emit multiple photons. Without countermeasures, photon number splitting attacks break the security of these systems. Decoy state protocols, developed by Hwang (2003) and Lo, Ma, and Chen (2005), address this by mixing signal pulses with decoy pulses of different intensities, enabling detection of the attack.

Decoy states restore security against photon number splitting but the resulting security is composably secure under specific hardware assumptions, not the full unconditional security of idealised single-photon BB84. ETSI GS QKD 011 documents the gap between theoretical and implementation security explicitly, noting that practical systems may not achieve the security levels promised by theoretical analysis.

The practical consequence: a QKD deployment's security depends on careful parameter estimation, hardware quality, and the validity of the assumptions underlying the security proof. These are engineering and operational variables, not protocol constants.

Distance Limits and the Trusted-Node Problem

Single-channel QKD over standard single-mode fibre operates reliably to approximately 100 km. Laboratory conditions have pushed this to around 150 km under controlled settings. Commercial systems from ID Quantique (Cerberis XG) and Toshiba's QKD platform operate within this range. Beyond it, photon loss makes key generation impractical at useful rates.

Extending QKD beyond this range requires trusted nodes. A trusted node decrypts the quantum key at one end of a link and re-encrypts it for the next segment. The node must be physically and operationally secure. If it is compromised, the entire key path is compromised. The NSA's August 2021 QKD FAQ states this explicitly: "QKD networks rely on trusted nodes, which introduce vulnerabilities similar to those in conventional networks."

The NSA goes further. Trusted-node architecture "fundamentally defeats the unconditional security claim." A network of trusted nodes provides no stronger security than encrypted point-to-point links protected by classical cryptography, except that key generation uses a quantum channel. The unconditional security property holds for individual links. It does not hold for the network.

Satellite-based QKD, demonstrated by the Chinese Micius satellite in 2017 (Liao et al., Nature 549), extends range using free-space optical links. The technical achievement is significant. It does not solve the trusted-node problem at ground stations, and atmospheric turbulence and daylight constraints limit operational availability. For more on government and research deployments of QKD infrastructure, see our coverage of quantum key distribution government deployments.

Bandwidth Ceilings in Commercial Deployments

Commercial QKD systems generate raw keys at rates between roughly 10 kbps and 100 kbps over typical enterprise fibre distances of around 50 km. Error reconciliation and privacy amplification reduce the usable secure key rate further. The ID Quantique Cerberis XG series and Toshiba's multiplexed QKD system both fall within this range, consistent with published academic characterisations of practical key generation rates.

A 10 Gbps network segment requires approximately 1.25 GB per second of key material for one-time-pad protection. A QKD system generating 50 kbps produces around 6 kilobytes per second. The mismatch is five orders of magnitude. One-time-pad semantics are not achievable at network throughput rates with current or near-term QKD technology.

In practice, QKD key material is used to rekey AES-256-GCM sessions rather than to implement one-time-pad encryption. This is a legitimate architecture. The important clarification for security teams and boards: in this deployment model, AES-256-GCM is providing the bulk data protection. QKD is providing a quantum-secured rekeying mechanism. The two claims are different, and conflating them in vendor presentations or board papers is a source of confusion that boards have a right to challenge.

Cost and Deployment Economics

Enterprise QKD node hardware costs approximately $100,000 per node as of 2024 to 2025. A point-to-point link requires two nodes plus dedicated fibre or wavelength-division-multiplexed dark fibre capacity. A metropolitan-area QKD network with five nodes costs over $500,000 in hardware before installation, integration, and maintenance. The UK NCSC's 2020 whitepaper on QKD and the BSI's Technical Guideline TR-02102-4 both cite cost as a primary barrier to mainstream enterprise deployment.

NIST-standardised PQC algorithms operate in software libraries. ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) for hash-based signatures are available through liboqs, BoringSSL with Open Quantum Safe patches, and Bouncy Castle PQC edition. Integration into existing TLS 1.3 stacks is a software update. For organisations deploying new hardware, the marginal cost of PQC is effectively zero. The primary migration cost is legacy HSM replacement.

The cost asymmetry between QKD at roughly $100,000 per node and PQC at a near-zero software upgrade cost is the primary practical reason enterprise security teams and the national agencies advising them have not moved to QKD as their mainstream migration path. For a fuller analysis of how Shor's algorithm breaks RSA and ECC, see how Shor's algorithm breaks RSA and ECC. Cost alone does not settle the question, but it sets the bar for justifying QKD high.

Standards Immaturity and the Interoperability Gap

ETSI's Industry Specification Group for QKD has produced a series of specifications, GS QKD 002 through 015, covering use cases, vocabulary, protocol layers, and interfaces. These are ETSI Group Specifications, not formal European Standards or international standards under ISO/IEC. There is no IETF RFC defining QKD key exchange within TLS, IPsec, or SSH. There is no IEEE production standard for QKD network deployment.

The absence of production-track standards from IETF, IEEE, or ISO means QKD cannot be integrated into standard enterprise infrastructure stacks without proprietary middleware. There is no standardised path to deploying QKD-generated keys into a TLS 1.3 handshake or an IKEv2 exchange. Each vendor integration is bespoke.

This matters for enterprise procurement. Compliance frameworks and audit standards reference IETF, NIST, and ISO standards. A QKD deployment that relies on proprietary integration cannot be validated against these frameworks in the same way a PQC-TLS deployment can. For security architects considering long-term supportability, this is a material constraint.

Government Agency Positions and What They Imply

The NSA's August 2021 QKD FAQ states: "NSA does not support the usage of QKD or QC to protect communications in National Security Systems (NSS)." The NSA's specific objections: QKD requires new physical infrastructure, carries high cost, is not secure against all attack vectors on implementation, lacks scalability, and cannot authenticate the quantum channel against a man-in-the-middle attack without a pre-shared classical authentication key.

The NCSC's 2020 whitepaper takes the same position. The NCSC does not endorse QKD for any government or military applications and identifies an important structural objection: QKD does not address the problem it claims to solve, because it still requires authentication using classical cryptography. The quantum channel is only as trustworthy as the classical authentication that bootstraps it.

The BSI's position, expressed in its Technical Guideline TR-02102-4 and the January 2024 joint position paper with ANSSI, BSI, NLNCSA (Netherlands), and the Swedish National Communications Security Authority, is consistent. For an independent analysis of why RSA and ECC are vulnerable to quantum attack, see RSA and ECC quantum vulnerability explained. BSI recommends hybrid classical-PQC as the migration path. The three agencies are not saying QKD is permanently useless. They are saying it is not ready for the environments they protect, and that NIST-standardised PQC is the correct near-term path for those environments.

For enterprises interpreting these positions: the agencies are not risk-averse outliers. They are the organisations with the most to lose and the deepest technical resources to evaluate the question. Their convergent position on NIST PQC as the primary migration track is significant signal for enterprise security planning. For a detailed look at ML-KEM deployment architecture, see key encapsulation mechanisms for security architects.

Placing QKD Accurately

QKD has legitimate use cases. Point-to-point links in controlled environments, short-haul metropolitan deployments between data centres with physical security and dedicated fibre, and research networks all represent contexts where QKD's cost and infrastructure requirements are acceptable and where the trusted-node problem does not arise. These are not enterprise-scale deployments in the general sense.

For security architects evaluating QKD in response to a vendor pitch or a board question: the honest framing is that QKD provides quantum-secured key generation for the specific link segment it covers, subject to trusted-node constraints beyond that segment, at a hardware and infrastructure cost roughly three to four orders of magnitude higher than the equivalent PQC software migration, without production-track interoperability standards for enterprise infrastructure stacks.

The mainstream migration path is NIST PQC. FIPS 203, 204, and 205 are finalised, implemented in major cryptographic libraries, and compatible with existing TLS, IPsec, and SSH infrastructure. For a comprehensive introduction to the protocols and their deployment context, see QKD explained. For organisations starting their migration programme, the NIST standards provide the technical foundation and the regulatory compliance basis that QKD cannot currently match.

Start Your Assessment

If your organisation has encountered QKD in a procurement process or needs to evaluate quantum security migration options, Quantum Security Defence provides technical advisory services grounded in the NIST PQC framework and aligned to current regulatory requirements under NIS 2, DORA, and NCSC guidance. Contact us to discuss your cryptographic migration roadmap.