QKD integration planning should begin with a cryptographic risk and connectivity problem, not with the promise of security guaranteed by physics. Quantum key distribution uses specialized quantum channels to establish keying material and can reveal disturbance under defined assumptions. The complete system still depends on authenticated classical communication, endpoints, key management, encryption devices, trusted facilities and operations. Use this guide with Edilec's QKD implementation checklist, QKD architecture FAQ and cryptographic inventory guide.
Official positions are deliberately cautious. The NSA QKD guidance does not recommend QKD for US National Security Systems unless stated limitations are overcome and favors quantum-resistant algorithms as more maintainable and cost-effective. The UK NCSC quantum networking paper recommends PQC as the primary mitigation and warns against relying solely on QKD. These positions do not forbid every commercial research or specialized deployment; they mean a team must prove why QKD is proportionate and how the full system is secured.
Define the protection problem first
Inventory data whose confidentiality or authenticity must survive a future cryptographically relevant quantum computer. Record sensitivity duration, current algorithms, protocols, endpoints, owners, geography and replacement constraints. Prioritize long-lived information exposed to harvest-now-decrypt-later risk. The output should be a migration portfolio, not a list of links where QKD could be installed. Edilec's quantum-safe transformation checklist can structure the broader program.
State the use case in measurable terms: two controlled sites need fresh symmetric keys for a high-value link, for example. Confirm whether the issue can be addressed with standardized post-quantum key establishment on existing infrastructure. NIST finalized its first three PQC standards in 2024, and its plain-language guidance encourages organizations to begin transition. QKD should be compared with that deployable baseline, not with leaving vulnerable public-key cryptography unchanged.
| Question | QKD implication | PQC implication | Evidence needed |
|---|---|---|---|
| Connectivity | Dedicated optical or qualified path | Uses existing compute and protocols | Route and endpoint survey |
| Authentication | Still requires authenticated channel | Signatures and certificates must migrate | Trust architecture |
| Distance | Loss and node model constrain design | Network distance is generally not special | Link budget and topology |
| Operations | Specialized hardware and calibration | Software, hardware and protocol upgrades | Support and skills plan |
| Assurance | Implementation-specific system proof | Algorithm and implementation assurance | Threat model and test plan |
Understand the complete QKD architecture
Map quantum transmitters and receivers, quantum channel, authenticated classical channel, key management system, encryption devices, applications, timing, management plane and monitoring. Identify every trusted node, optical component, co-location dependency and administrative boundary. QKD distributes key material; it does not by itself encrypt business traffic, validate endpoint software, authorize users or protect stored data. Those functions remain part of the security architecture.
The ETSI QKD group publishes vocabulary, interfaces, protection profiles and interoperability work, including a 2026 REST-based key-management API specification. Select the exact versions relevant to the pilot and test vendor claims against them. A standards reference narrows interface ambiguity, but conformance to one document does not establish end-to-end security or interoperability across every implementation.
Test physical and operational feasibility
Survey fiber ownership, length, attenuation, splices, connectors, wavelengths, environmental conditions, maintenance windows and route diversity. Verify whether the design uses point-to-point links, trusted nodes or another topology and what each choice does to the trust boundary. Laboratory distance claims do not establish performance on a live route. Coexistence with classical traffic, repair practices and carrier access can change loss and risk.
Define key generation, delivery, consumption, exhaustion, rollover, destruction and recovery. Determine what happens when the quantum channel is disturbed or unavailable. A secure fallback may use pre-positioned keys or an approved PQC/classical hybrid according to policy; silently falling back to a weaker mode defeats the objective. Exercise denial of service because sensitivity to channel disturbance can become an availability weakness.
Build an implementation-specific threat model
Threat-model sources, detectors, random-number generation, calibration, timing, side channels, supply chain, management interfaces, key stores, encryption devices, privileged staff and trusted sites. The NSA guidance stresses that practical security is implementation-dependent and that special hardware can introduce vulnerabilities. Require evidence for countermeasures, tamper response, firmware updates, vulnerability handling and independent assessment. Avoid absolute language such as unhackable or guaranteed secure.
Treat QKD as one component in defense in depth. Apply segmentation, strong administrative authentication, protected logging, configuration control and incident response. Verify the authentication mechanism for the classical channel and its quantum-resistant migration path. Include compromise of a trusted node, endpoint or management system in exercises; detecting eavesdropping on a quantum channel does not compensate for an attacker who steals usable keys from an endpoint.
| Pilot gate | Pass evidence | Failure response | Decision owner |
|---|---|---|---|
| Route | Measured loss and stable operation | Redesign or stop | Network owner |
| Interoperability | Keys consumed by target encryptor | Resolve interface gap | Crypto architect |
| Security | Threats tested and findings treated | Restrict or remediate | Security authority |
| Availability | Fallback and recovery exercised | Retain current protected path | Service owner |
| Economics | Lifecycle cost compared with PQC | Do not scale | Business sponsor |
Compare lifecycle cost and alternatives
Include optical survey and construction, QKD hardware, encryptors, key management, racks, power, secure sites, spares, calibration, carrier work, integration, assurance, monitoring, training and refresh. Add the cost of trusted nodes and route diversity where needed. Compare the same service objective under PQC and hybrid designs. The NIST migration FAQ summarizes the finalized FIPS standards and migration context, providing a current baseline for that comparison.
Run a bounded pilot with exit criteria
- Approve the protected data, lifetime, threat model and wider PQC migration plan.
- Select one controlled link and document every physical and administrative trust boundary.
- Integrate key delivery with the real encryptor and application operating path.
- Measure key rate, loss, errors, availability and behavior under realistic route conditions.
- Exercise disturbance, component failure, key exhaustion, fallback, recovery and incident response.
- Scale only if security evidence, service continuity and lifecycle economics beat alternatives.
Prepare the QKD decision dossier
A scale decision should be supported by a dossier that a cryptography, network and business reviewer can challenge. Include the protected information, confidentiality lifetime, threat actors, current cryptography, PQC alternative, site and route diagrams, trust boundaries, protocol and product versions, assurance reports, pilot measurements, residual risks and total cost. Separate vendor statements, standards conformance and locally observed evidence so their strength is not blurred.
Review authentication in detail. Identify the mechanism used to authenticate the classical channel at initial deployment, during routine operation and after key or certificate rollover. Explain how that mechanism resists the quantum threat and how credentials are recovered after compromise. If pre-shared keys are used, document generation, transport, dual control, storage, rotation and exhaustion. QKD does not remove this bootstrap problem.
Examine trusted locations and personnel. For every endpoint or trusted node, record physical protection, visitor and carrier access, tamper response, maintenance, replacement parts, firmware authority and logging. Test whether a technician or compromised management account can weaken operation without a timely signal. Include environmental and aging behavior in maintenance because optical performance and detector calibration can change without an adversary.
Run interoperability and continuity tests long enough to include routine carrier work and equipment maintenance. Measure usable key delivery to the encryption application, not only raw key generation. Trigger channel loss, degraded rate, asymmetric failure, node restart, management outage and exhausted buffers. Confirm that fallback is explicit, approved and visible to operators and service owners. Reconcile keys and traffic state after recovery.
Compare the dossier with the broader PQC roadmap. If the QKD pilot consumes scarce cryptographic engineering while certificates, signatures and software remain quantum-vulnerable, reprioritize. The decision may be to continue research, protect one exceptional link, wait for maturity or stop. Recording a negative decision with preserved evidence is a legitimate result and prevents repeated speculative pilots.
Define evidence retention and vulnerability response for the lifetime of the pilot. Preserve configurations, calibration records, firmware versions, link measurements, key-management events and incident decisions with restricted access. Agree how researchers and vendors disclose implementation weaknesses and how affected equipment is isolated or updated. Because QKD products combine optical, electronic and classical software components, ownership cannot stop at the cryptography team. The dossier should identify the authority for each layer and the conditions that trigger reassessment.
- Separate claims, standards and observed proof.
- Prove quantum-resistant authentication.
- Inspect every trusted site and operator path.
- Measure usable keys through failures.
- Compare resources with the PQC roadmap.
Key takeaways
- Begin QKD integration planning with data lifetime and a cryptographic inventory.
- Compare QKD with current standardized PQC, not with inaction.
- Model authenticated channels, endpoints, key management and trusted sites together.
- Test implementation attacks and denial of service under real route conditions.
- Reject absolute security claims and require lifecycle cost plus exit evidence.
Frequently asked questions
Does QKD replace post-quantum cryptography?
No. QKD applies to particular key-distribution links and needs specialized infrastructure. PQC addresses broad key-establishment and signature use on conventional platforms. An organization will usually need PQC migration even if it pilots QKD for a narrow link.
Can QKD work over any fiber distance?
No. Performance depends on protocol, equipment, attenuation, route components and topology. Repeaters in the ordinary networking sense cannot simply copy unknown quantum states. Require a measured route design and clearly identify any trusted nodes.
Does eavesdropper detection make the system unbreakable?
No. Theoretical detection properties depend on assumptions and implementation. Endpoints, detectors, management systems, authentication, key stores, encryptors, supply chain and operators can still fail or be attacked. Assurance must cover the complete system.
Conclusion
QKD integration planning is a specialized architecture decision inside a much larger quantum-safe transition. Establish the data and threat case, compare standardized PQC, survey the physical route, secure every classical and operational component, and prove failure behavior. A bounded pilot may be justified for certain controlled links; broad claims without that evidence are not a security strategy.