Under a protocol’s security model, observation or disturbance of the quantum channel can affect measured statistics, allowing the endpoints to decide whether usable key material can be established. The assurance depends on the physical implementation and stated assumptions.
QKD requires an authenticated classical channel; the quantum exchange does not establish endpoint identity by itself. The resulting keys are supplied to conventional cryptographic applications, which encrypt or authenticate the actual data. Deployments typically require specialized optical links and key-management integration, while larger networks may introduce trusted relay nodes or other additional assumptions.
Key points
Authentication and keysEstablish initial authentication, protect credentials, bind the quantum and classical sessions, and define how generated key material is stored, consumed, rotated, destroyed, and recovered.
Links and integrationEvaluate distance, loss, throughput, topology, trusted nodes, device interoperability, application interfaces, and how conventional encryption continues when the quantum service is unavailable.
Security validationTest implementations against their claimed model, monitor error and abort behavior, protect endpoints and management systems, and plan for component flaws, side channels, denial of service, and protocol updates.
Important limitationQKD distributes key material; it does not encrypt application data, authenticate its classical channel, or secure endpoints by itself. Specialized hardware, deployment cost, link constraints, trusted intermediaries, and implementation weaknesses may outweigh its benefits for many use cases.