Why QKD Is Not a Substitute for Post-Quantum Algorithm Migration

The terminology does not help. “Quantum Key Distribution” and “post-quantum cryptography” share a word, appear in the same policy documents, and get discussed in the same security briefings. Some vendor proposals present QKD as a quantum security solution without specifying what problem it actually solves or what problems it cannot solve. The result, in procurement conversations and board-level briefings, is a recurring question: can QKD substitute for PQC migration, delay it, or reduce its scope?

The answer is no, and the reason is precise: QKD and PQC solve different problems at different layers of the security stack. QKD distributes symmetric encryption keys over a dedicated quantum optical channel between two fixed endpoints. PQC algorithms replace quantum-vulnerable asymmetric cryptography across every protocol, certificate, signature, and key establishment mechanism in a modern IT estate. QKD cannot do what PQC does. That is not a limitation of current QKD implementations. It is a structural feature of what QKD is designed to do.

NSA stated this directly in its August 2021 advisory: QKD is not a practical security solution for National Security Systems, and organisations should transition to CNSA 2.0 through PQC rather than QKD. The PQC migration obligation is not reduced by QKD deployment anywhere in the estate.

The Confusion Is Understandable, and Consequential

The surface-level similarity between QKD and PQC is genuine enough that the confusion is not surprising. Both technologies address the quantum threat to cryptography. Both appear in government guidance documents. Both are discussed in the context of protecting long-lived sensitive data against future quantum adversaries.

They are not alternatives. NSA's August 2021 advisory explicitly addresses the scope limitations of QKD and the need for PQC migration independently of any QKD deployment. The document does not frame the two as competing choices. It frames QKD as a narrow technology with specific limitations and PQC as the required transition for any organisation with a broad cryptographic estate.

The consequence of conflating them is operational. An organisation that invests in QKD for one inter-site link while delaying PQC migration has secured exactly one communication channel: the key distribution step on one dedicated fibre. Every TLS certificate, every signed software update, every encrypted email, every code-signing certificate, every document signature, and every encrypted archive in that organisation remains quantum-vulnerable. The QKD deployment leaves the problem substantially intact.

What QKD Actually Does: The Topology It Requires

QKD protocols, including BB84, E91, CV-QKD, and MDI-QKD, use quantum optical properties to establish a shared symmetric key between two endpoints. The established keys are then used to re-key a classical symmetric cipher, typically AES-256-GCM, as defined in ETSI GS QKD 014 V1.1.1. The security guarantee is information-theoretic for the key distribution step: an eavesdropper cannot intercept the key without disturbing the quantum channel detectably.

That guarantee applies only to the point-to-point quantum optical link between those two specific endpoints. Not to any other part of the communication system. Not to any other endpoint pair. Not to any non-key-distribution cryptographic operation. QKD is a key transport mechanism. It produces symmetric keys. It does not produce asymmetric keys, public-private key pairs, digital signatures, or certificates. It has no mechanism for verifying the identity of a communicating party beyond the pre-shared classical authentication it already requires as a precondition for its own security proof.

The Topology Constraint

A QKD link is point-to-point between two fixed nodes connected by dedicated optical fibre. An organisation with 100 network endpoints would require up to 4,950 dedicated fibre links for full mesh QKD connectivity. This is not an economic objection to a theoretical capability. It is a structural incompatibility with enterprise security architectures that require dynamic authentication and key exchange between many parties, including mobile users, cloud services, and third-party APIs. QKD cannot address these use cases at any price point available today.

What PQC Migration Covers: The Full Scope of Quantum-Vulnerable Cryptography

To understand why QKD cannot substitute for PQC migration, it is necessary to specify what PQC migration covers. The scope is considerably broader than key exchange.

Asymmetric Key Exchange

TLS 1.3 key exchange (X25519, P-256 ECDH) is quantum-vulnerable to Shor's algorithm. ML-KEM (FIPS 203, August 2024) replaces the key exchange component in TLS, IPsec IKEv2, SSH, and other protocols. QKD can, in principle, distribute keys for symmetric cipher sessions on a specific point-to-point link in place of ECDH for that link. That is the one area where QKD and ML-KEM capabilities overlap. It is limited to that application on that topology.

Digital Signatures and Authentication

Digital signatures underpin TLS certificate authentication, code signing, document signing, email signing (S/MIME), software supply chain integrity, timestamping (RFC 3161), and identity federation. Every current production signature algorithm, including RSA-PSS, ECDSA, and EdDSA, is quantum-vulnerable to Shor's algorithm. NIST IR 8547 IPD (November 2024) lists all three as deprecated under its transition timeline.

ML-DSA (FIPS 204, August 2024) and SLH-DSA (FIPS 205, August 2024) are the NIST-standardised post-quantum signature algorithms. QKD has no signature capability. It cannot authenticate endpoints, sign certificates, verify software integrity, or replace any signature-dependent process. Every signature use case requires PQC migration, regardless of whether QKD is deployed anywhere in the estate. NSA's August 2021 advisory states this explicitly.

Certificate Infrastructure, Code Signing, and Data at Rest

Public key infrastructure is built entirely on asymmetric cryptography. Certificate authorities issue certificates containing RSA or ECDSA public keys, signed by the CA's RSA or ECDSA private key. The entire chain of trust in internet PKI is quantum-vulnerable. Migrating PKI requires replacing RSA and ECDSA certificates with ML-DSA or SLH-DSA equivalents throughout the hierarchy. See PQC in PKI: Migration Planning for a detailed treatment of the certificate hierarchy transition. QKD does not interact with certificate infrastructure at any level.

Code signing certificates authenticate software packages, drivers, and firmware updates using RSA or ECDSA. A quantum adversary capable of forging code signatures could distribute malicious software as apparently legitimate signed packages, targeting the supply chain rather than the network. Migration to ML-DSA or SLH-DSA for code signing is part of the PQC transition, documented in NIST FIPS 204 and 205. It is not addressed by QKD.

Data at rest encrypted using a key protected by RSA-OAEP key encapsulation remains quantum-vulnerable even if the symmetric cipher (AES-256-GCM) is not. The vulnerability is in the key encapsulation layer. Migration requires replacing RSA or ECDH key encapsulation with ML-KEM. Encrypted archives and backup stores from previous years sit in this category and cannot be protected retroactively by any QKD deployment.

The NSA Position: Stated Explicitly

NSA's August 2021 advisory states: “NSA does not support the usage of QKD or QC to protect communications in National Security Systems (NSS), and does not consider QKD a practical security solution.” The same advisory recommends that NSS owners and operators transition to quantum-resistant cryptography through CNSA 2.0 rather than QKD. CNSA 2.0 (September 2022) specifies ML-KEM-1024, ML-DSA-87, and SLH-DSA as the required algorithms for national security systems.

The NSA's reasoning is not that QKD is technically unsound in its specific domain. It is that QKD leaves authentication, signatures, certificate infrastructure, and the majority of cryptographic use cases completely unaddressed. An NSS owner who deploys QKD for one classified link and considers the quantum transition addressed has misread the scope of the problem. NCSC (UK, October 2020) and the January 2024 joint position paper from ANSSI, BSI, NLNCSA (Netherlands), and the Swedish National Communications Security Authority each reach the same conclusion independently: PQC migration is the primary obligation. The joint position paper is available at bsi.bund.de.

Where QKD Fits: The Honest Framing

QKD provides a genuinely distinct security property: information-theoretic forward secrecy for key distribution over a dedicated optical link, independent of any computational hardness assumption. For a very small set of deployments where that specific property is required and the topology, cost, and operational constraints can be met, QKD is a legitimate security tool. The companion article on this site describes those conditions precisely: see Where QKD Makes Sense and Where It Does Not.

The honest framing for most organisations is simpler. QKD is a narrow, expensive, topology-constrained complement to PQC for specific government or classified applications. It does not reduce the scope of PQC migration by a single algorithm or a single certificate. It does not delay NIST IR 8547 deprecation timelines. It does not address any of the asymmetric cryptographic operations that form the operational foundation of enterprise IT security.

Practical Priorities: A Decision Framework for the Enterprise

The sequencing for any organisation evaluating both QKD and PQC should run in this order:

• Step 1: Complete a Cryptographic Bill of Materials (CBOM). Identify every quantum-vulnerable asymmetric algorithm in use across the estate: RSA, ECDSA, ECDH, DH, EdDSA. This is the prerequisite for any migration planning. See Cryptographic Bill of Materials: The Foundation of PQC Readiness.
• Step 2: Prioritise PQC migration by use case and risk. Tackle TLS key exchange first (hybrid ML-KEM + X25519). Then address certificate and signature migration (ML-DSA or SLH-DSA). Then data-at-rest key encapsulation replacement.
• Step 3: Only after PQC migration is planned and resourced, evaluate whether any specific point-to-point links meet the QKD criteria: fixed endpoints, short distance, key distribution only, information-theoretic property required beyond what PQC provides, and budget available.

Allocating security budget to QKD before completing PQC migration leaves the majority of the cryptographic estate quantum-vulnerable while protecting one channel. The risk reduction from QKD on one link is vastly outweighed by the unmitigated risk across the remaining estate. This is the wrong sequencing. It is the sequencing that results from conflating QKD and PQC as alternatives rather than understanding them as tools addressing different problems.

QSECDEF's advisory programme supports organisations working through this prioritisation decision. Expert Membership provides structured access to migration sequencing guidance for security teams facing procurement questions or board-level scrutiny on quantum security investment.