QKD integration planning begins with a narrow question: is there a communications link whose secrecy requirement, physical topology and operating budget justify dedicated quantum key distribution equipment? QKD uses quantum states to help two endpoints establish keying material and detect certain forms of observation on the quantum channel. It does not encrypt application data by itself, authenticate every participant, secure endpoint software or replace ordinary key management. A useful plan therefore treats QKD as one component in a larger cryptographic service, not as a universal quantum-security upgrade.
That distinction matters because post-quantum cryptography is deployable on conventional computing platforms and is the primary migration path for most organizations. NIST has standardized ML-KEM for key establishment, while CISA, NSA and NIST advise organizations to inventory quantum-vulnerable cryptography and build migration roadmaps. QKD may be considered for a small number of high-value, stable links, but it should not delay cryptographic discovery or adoption of standardized post-quantum mechanisms. This checklist helps a security, network and application team decide whether to reject, pilot or operationalize a proposed QKD use case.
Start with a QKD decision gate
Write the protected business exchange in one sentence: which two sites communicate, what data or control traffic crosses the link, how long its confidentiality must survive and what consequence follows disclosure or outage. Then compare QKD with a conventional design using approved symmetric cryptography, post-quantum key establishment and hardened key management. QKD should advance only if its different trust model materially addresses a documented risk. “Quantum safe” is not an acceptance criterion; the team needs a measurable reason why physical key distribution is preferable for this link.
Topology is an early stop condition. Fiber-based QKD has distance, attenuation and equipment constraints, and extending a network may introduce trusted nodes whose compromise exposes key material. Free-space or satellite arrangements introduce different availability and alignment concerns. Establish whether the route is owned, leased or shared; whether intermediate facilities can be protected; and whether redundant paths are physically diverse. If the design requires untrusted repeaters or cannot meet service continuity needs, record that finding before investing in an application integration.
| Question | Evidence required | Decision signal |
|---|---|---|
| Is the use case exceptional? | Data lifetime, threat model and business impact | A specific long-lived confidentiality need, not a general technology goal |
| Can the route support QKD? | Fiber loss, distance, node and facility survey | A feasible primary and recovery topology |
| Is the trust model better? | Endpoint, node, operator and supplier assumptions | Fewer or more defensible critical trust dependencies |
| Can the service fail safely? | Fallback, alarm and key-exhaustion design | No silent downgrade or uncontrolled outage |
| Is PQC still planned? | Cryptographic inventory and migration roadmap | QKD complements rather than displaces enterprise migration |
Define the full QKD architecture boundary
Document both the quantum and classical channels. The quantum channel carries states used in key generation; the classical channel supports protocol coordination and must be authenticated. Map QKD devices, optical components, key-management systems, encryptors, applications, timing sources, management interfaces and monitoring. For every interface, identify protocol, identity, authorization, key format, rate, error handling and audit source. ETSI publishes QKD work on vocabulary, components, security, interoperability and key-management interfaces; use the applicable specifications as design inputs instead of relying on a vendor diagram.
Separate the security proof of a protocol from the assurance of the implementation. Detectors, sources, calibration, firmware, management ports and supply-chain handling can create exploitable behavior outside an ideal mathematical model. Require the supplier to state the protocol and assumptions, implementation countermeasures, secure-development process, update mechanism, vulnerability-disclosure path and evaluation evidence. Identify which claims have independent support and which are vendor assertions. The NSA’s public QKD guidance is deliberately cautious about implementation dependence, specialized equipment, insider risk, denial of service and authentication; those limitations belong in the risk register.
Design authentication and the key lifecycle
QKD-generated bits become useful only through a controlled lifecycle. Specify how peers are initially authenticated, how authentication material is renewed, how generated keys enter a key-management service, how applications request them and how key identifiers are reconciled across endpoints. Define generation, validation, storage, delivery, use, expiry and destruction. Avoid designs that export raw keys into loosely controlled files or operator consoles. Limit each service identity to the key streams it requires, protect management operations with phishing-resistant authentication and preserve tamper-evident records without logging secret material.
Capacity planning must consider key consumption as well as network throughput. Measure secure key rate under representative channel loss, weather or environmental conditions, then compare it with encryption mode and rekey policy. Decide what happens when the key buffer falls below a threshold: queue traffic, use an approved conventional or post-quantum fallback, or stop the protected service. A fallback is a security decision, not just an availability feature. It must be explicit to applications and operators, bounded by policy and visible in telemetry so a prolonged degraded mode cannot become normal operation.
Run a bounded QKD pilot
A pilot should reproduce one realistic route and one consuming application without carrying irreplaceable production traffic. Establish a baseline using the incumbent cryptographic service, including throughput, latency, operational effort, recovery time and change process. Install QKD equipment through the same asset, access, configuration and monitoring controls expected in production. Exercise initial trust establishment, planned maintenance, device replacement, certificate or authentication-key rotation, key-manager failover and application reconnection. Include network, security operations, facilities and application owners in the runbook because QKD failures cross all four domains.
- Record the business link, confidentiality lifetime and approved alternatives.
- Survey physical paths, attenuation, trusted locations and redundant routing.
- Threat-model quantum devices, classical control, key management and endpoints.
- Integrate one application through a documented key-delivery interface.
- Measure key rate, application behavior, alarms and operator workload.
- Exercise failure, fallback, recovery, replacement and evidence collection.
- Make an evidence-based stop, extend or production decision.
Set production acceptance evidence
Acceptance should demonstrate security and operability together. Confirm that unauthorized management access is blocked, peer authentication failures stop key agreement, low-key conditions trigger the intended policy, and every failover produces a visible state transition. Validate time synchronization, configuration recovery and inventory accuracy. Review whether monitoring can distinguish channel degradation, suspected observation, hardware fault and ordinary network failure. If all conditions collapse into one alarm, responders cannot choose a safe action. Preserve test records with device versions and topology so later changes can be assessed against the same evidence.
| Acceptance area | Test | Pass evidence |
|---|---|---|
| Key delivery | Generate, request, consume and reconcile keys | Matched identifiers, policy and consumption records without secret exposure |
| Authentication | Use an unknown or expired peer credential | Connection rejected with actionable alert and retained event |
| Capacity | Reduce channel quality and exhaust the buffer | Thresholds, application behavior and recovery match policy |
| Resilience | Fail a device, manager and physical path | Bounded interruption and tested restoration from controlled configuration |
| Operations | Patch, replace and re-enroll equipment | Named approval, integrity checks and complete asset history |
| Exit | Remove QKD and activate approved alternative | No stranded keys, dependencies or undocumented downgrade |
Operate QKD as a security service
Production ownership should cover service health, cryptographic policy, physical facilities, supplier coordination and consuming applications. Establish supported versions, configuration baselines, spare strategy, calibration controls and maintenance windows. Route vulnerability disclosures and component end-of-life notices to an accountable owner. Track secure key rate, degraded-mode duration, authentication failures, unexplained channel changes, device availability, failed delivery requests and recovery exercises. Avoid presenting raw quantum bit error measurements as a business service level; users care whether approved keys reached the intended encryption service under the agreed trust and availability conditions.
Reassess the design when routes, devices, firmware, trust locations, application protocols or regulatory obligations change. Continue the wider post-quantum program: discover public-key use in TLS, code signing, identities, software updates, documents and partner interfaces; prioritize long-lived data and difficult-to-replace systems; and test NIST-standardized algorithms through supported products. QKD does not protect signatures or every remote exchange, and a specialized link cannot compensate for vulnerable endpoints. The most credible program can explain where QKD adds value and where ordinary cryptographic agility remains essential.
Key takeaways
- Use QKD only for a defined link whose risk and topology justify specialized infrastructure.
- Treat QKD as key generation and delivery inside a broader authenticated cryptographic service.
- Evaluate practical devices, trusted nodes, control channels and denial-of-service behavior, not only protocol theory.
- Specify low-key fallback and degraded operation as explicit security policies.
- Continue enterprise post-quantum discovery and migration regardless of the QKD decision.
Frequently asked questions
Does QKD replace post-quantum cryptography?
No. QKD requires specialized links and addresses key distribution between particular endpoints. Post-quantum algorithms can protect key establishment and signatures across existing software and network ecosystems. Most organizations need a broad PQC migration even if they pilot QKD for selected links.
Can QKD protect ordinary internet traffic end to end?
Not by simply enabling a protocol option. QKD depends on compatible physical infrastructure and equipment between participating sites. A network of trusted nodes changes the trust model, while the application still needs authenticated key delivery and an encryption mechanism.
What is the best first QKD pilot?
Choose one stable, high-value point-to-point route with known fiber characteristics, a clear confidentiality requirement and an application that can consume keys through a controlled interface. Include failover and fallback tests; a laboratory demonstration of key generation alone is not an operational pilot.
Conclusion
A defensible QKD plan is willing to conclude that QKD is not the right tool. When it is justified, the result is not merely two optical boxes producing keys. It is an authenticated, monitored and recoverable service whose physical path, trusted nodes, key lifecycle, application behavior and fallback policy have all been tested. That evidence lets decision-makers compare QKD with post-quantum alternatives on security, continuity, cost and maintainability rather than on an unqualified promise of quantum safety.