How Quantum Key Distribution Works: BB84 and Limits

Quantum key distribution is often sold as "unbreakable" encryption, yet most security teams asked to assess it have never been shown how it actually moves a key from one site to another. This guide explains the mechanics: what travels over the quantum channel, what has to travel over an ordinary classical channel, how the BB84 protocol turns single photons into a shared secret, why distance forces trusted nodes, and where real systems fall short of the theory. It then sets out what the national security agencies of the UK, US, France, Germany, the Netherlands and Sweden have published about QKD, so that architects, cryptography leads and risk owners can judge vendor proposals on their engineering rather than their marketing. It is a mechanics page, not a comparison: for choosing between approaches, see the QKD vs Post-Quantum Cryptography Guide.

Key takeaways

QKD only produces key material. It does not encrypt your traffic and, as the NSA and NCSC both state, it cannot authenticate who is at the other end; that has to come from classical or post-quantum cryptography, or pre-placed keys.
Two channels are always needed. A quantum channel carries single-photon (or weak optical) signals, and an authenticated classical channel carries the discussion that turns raw detections into a final key.
BB84 works by making eavesdropping visible. Measuring a photon in the wrong basis disturbs it, so an interceptor raises the error rate that the two ends check before keeping any key.
Distance means trusted nodes. Photons are lost in fibre and cannot be amplified like classical signals, so longer links are chained through relays that see the key in clear; the NSA lists these relays as a cost and insider-risk problem.
Security lives in the hardware. The physics proof assumes ideal devices; NSA notes that hardware flaws have already led to publicised attacks on commercial QKD systems, which is why evaluation schemes such as ETSI GS QKD 016 exist.

What QKD is, and what it is not

The NSA describes QKD as using the properties of quantum mechanical systems to generate and distribute cryptographic keying material, using special-purpose technology. ETSI's Industry Specification Group on QKD puts it similarly: a technique that uses quantum properties of optical signals to generate secret keys shared by two parties. The important word in both descriptions is keys.

What it produces: a stream of shared secret bits at two endpoints, which a separate encryptor then uses, typically as keys for a symmetric cipher such as AES, or occasionally as a one-time pad where key rate allows.
What it does not produce: authentication, integrity of the data you send, or protection of the endpoints. The NCSC states plainly that QKD does not provide authentication, "nor do any other quantum techniques".
What it claims: that an eavesdropper on the quantum channel leaves a detectable trace, a property classical key exchange does not offer. NSA notes that published theory supports this, while warning that vendor claims of "guaranteed" security based on physics are overstated because security depends on the implementation.
Quantum cryptography (QC): NSA uses the term for related systems that use the same physics to communicate over a dedicated link. Most commercial products are QKD key generators feeding classical encryptors.

The building blocks of a QKD link

Every deployed QKD link, whatever the vendor, is built from the same functional parts. Knowing them lets you ask the right questions about each one.

Component	What it does	Security question to ask
Transmitter (often called Alice)	Generates random bits and basis choices, and prepares weak optical pulses or single photons encoding them	Where does its randomness come from, and is it tested? Is the light source leaking extra information (multi-photon pulses, side emissions)?
Quantum channel	Dedicated optical fibre (or dark fibre wavelength) or a free-space optical path, including satellite links	Is the fibre dedicated end to end? Who controls every splice and patch point?
Receiver (Bob)	Chooses measurement bases at random and detects photons with single-photon detectors	Has the detector design been evaluated against known detector attacks? Is there a monitor for bright-light injection?
Classical channel	Ordinary network link used for basis reconciliation, error estimation, error correction and privacy amplification	How is it authenticated: pre-shared symmetric keys, classical signatures, or post-quantum signatures?
Key management layer	Stores distilled key and hands it to encryptors through an API	Which interface is used (for example ETSI's REST-based key delivery and key management specifications)? How are keys protected at rest in the KMS?
Encryptor	Uses the delivered key to encrypt traffic, usually with a symmetric cipher on a layer 1, 2 or 3 link	What happens when QKD key runs out or the link drops: fail closed, fall back to classical keying, or reuse keys?

NSA's description of the equipment is blunt: because security depends on the physical layer, users must lease dedicated fibre or physically manage free-space transmitters, QKD cannot run in software or as a network service, and its hardware makes upgrades and security patching harder. That is the operational reality behind each row of the table.

How BB84 turns photons into a shared key

BB84, published by Charles Bennett and Gilles Brassard in 1984, is the original QKD protocol and still the basis of most prepare-and-measure products (the family covered by the ETSI GS QKD 016 protection profile). The logic is simple even if the hardware is not.

Preparation: the transmitter picks a random bit and a random basis for each pulse. In the textbook polarisation version there are two bases: rectilinear (horizontal or vertical) and diagonal (plus or minus 45 degrees). Each basis encodes 0 and 1 in two orthogonal states, giving four states in total. Commercial fibre systems often use phase or time-bin encoding instead of polarisation, but the logic is the same.
Measurement: the receiver measures each arriving pulse in a basis it chooses at random. If its basis matches the sender's, it reads the bit correctly. If it does not, the result is random.
Sifting: over the classical channel the two sides announce which basis they used for each detected pulse (never the bit values) and discard the cases that did not match. On average about half the detections survive. The surviving bits are the raw or sifted key.
Error estimation: they publicly compare a random sample of the sifted key and calculate the quantum bit error rate (QBER). An interceptor who measures pulses must guess the basis and, when wrong, re-sends a disturbed state, which raises the error rate. If the QBER is above the protocol's threshold the run is aborted.
Error correction: the remaining bits still contain errors from noise. The two ends run a reconciliation protocol over the classical channel to make their strings identical, which leaks some information about the key.
Privacy amplification: to remove whatever an eavesdropper could have learned from both the quantum channel and the reconciliation, they compress the key with a hash function into a shorter final key. The more errors observed, the more is cut away.
Authentication of every classical message: sifting, error estimation and reconciliation are only safe if the classical messages cannot be tampered with. Without this, an attacker can sit in the middle and run two separate QKD sessions. This is the step NSA and NCSC say QKD cannot do for itself.

The security argument rests on two pieces of physics: measuring an unknown quantum state in the wrong basis disturbs it, and an unknown quantum state cannot be copied perfectly (the no-cloning theorem). Together they mean an interceptor cannot take a copy and leave the original untouched.

Other protocol families

Decoy-state BB84: real systems use attenuated laser pulses that sometimes contain more than one photon. Decoy-state variants send pulses of different intensities so the receiver can estimate how much an attacker could have learned by splitting off extra photons.
Entanglement-based protocols: a source distributes entangled photon pairs to both ends, and correlations between their measurements form the key. These matter for satellite experiments and for future quantum networks that the NCSC describes as distributing entangled states.
Continuous-variable QKD: encodes information in properties of light measured with coherent detection, closer to standard telecom components but with its own security proofs and limits.
Measurement-device-independent and device-independent approaches: research designs that reduce how much the security proof has to trust the detectors or devices, in response to the hardware attacks described below.

Distance, key rate and trusted nodes

A classical optical link uses amplifiers to push signals over long distances. A QKD link cannot, because amplifying a single photon would mean copying it, which the same physics that makes QKD secure forbids. Photons lost in fibre are simply gone, and loss grows with distance, so the secret key rate falls steeply as the link gets longer while detector noise stays constant. At some distance the noise dominates and no key can be produced at all. Vendors quote different maximum ranges and rates depending on fibre quality, protocol and detectors, so ask for measured figures on your own fibre, not datasheet maxima.

To go further, networks chain links together through intermediate sites.

Way to extend range	How it works	Security consequence
Trusted node (trusted relay)	Each hop runs its own QKD link; the relay holds both keys and passes the end-to-end key along, protected by the hop keys	The relay sees the key in clear. NSA states trusted relays add cost for secure facilities and insider-threat risk, ruling out many use cases. Every relay becomes a site you must physically secure and vet staff for.
Satellite link	A satellite acts as a transmitter, entangled-pair source or trusted node to ground stations	If the satellite is a trusted node, its operator holds keys. Links depend on weather, line of sight and pass windows.
Quantum repeater	Uses entanglement swapping and quantum memories to extend entanglement without measuring the key	Would remove the trusted relay, but the NCSC lists quantum memories and repeaters as components still needed for future quantum networks: they are not a deployable enterprise product.

The practical result is that QKD is point-to-point. A metro link between two data centres can be direct; a national or international network is a chain of trusted buildings. When reviewing a design, draw every node where key exists in clear and treat each as part of your trusted computing base.

Where real systems fall short of the theory

NSA puts the core issue clearly: the actual security of a QKD system comes from hardware and engineering, not from the theoretical unconditional security of physics, and the error tolerance cryptography needs is many orders of magnitude tighter than normal engineering. It notes hardware flaws have already caused publicised attacks on commercial systems. The NCSC adds that building QKD implementations secure against well-resourced, long-term adversaries is "an ongoing challenge", and that combining quantum and classical components with specialised hardware increases complexity and risk.

Source imperfections: multi-photon pulses, correlations between pulses or side channels in the transmitter can leak bits that the proof assumed were secret.
Detector attacks: single-photon detectors can be manipulated with external light so that they behave predictably, letting an attacker control which bits are recorded without raising the error rate. Ask vendors which published attack classes their detectors have been tested against.
Trojan-horse probing: light sent back into a device can reflect off internal components and reveal settings. Optical isolators and monitoring detectors are the usual countermeasure.
Classical software and key management: the reconciliation software, KMS and encryptors are ordinary computers with ordinary vulnerabilities, and the hardware nature of QKD makes patching slower, as NSA notes.
Denial of service: because QKD aborts when it sees disturbance, NSA highlights that the same sensitivity makes denial of service a significant risk. Anyone with access to the fibre can stop key generation. Your design must say what the encryptor does when that happens.
Randomness: basis and bit choices must be unpredictable. A weak random number generator undoes the protocol. See the Random Number Generation and Entropy in Security Guide.

ETSI's ISG QKD works on interfaces, implementation security requirements and optical characterisation of components. Its GS QKD 016 (V2.1.1, January 2024) is a Common Criteria protection profile for a pair of prepare-and-measure QKD modules, which gives evaluators a formal target; ask whether a product has been certified against it, and by which scheme.

What national security agencies say

Several national authorities have published formal positions. They are summarised here because anyone assessing QKD will be asked about them; they are paraphrased from the official pages, which should be read in full.

Authority	Publication	Position (paraphrased)
UK NCSC	Quantum networking technologies	Will not support QKD for government or military applications. Other sectors should not rely on QKD alone to generate and distribute keys, and its use should not count as evidence of data-in-transit security under the Cyber Assessment Framework. Anyone using it should add quantum-resistant authentication and manage the extra complexity risk.
US NSA	Quantum Key Distribution (QKD) and Quantum Cryptography (QC)	Does not recommend QKD or QC for National Security Systems unless its limitations are overcome, and does not expect to certify or approve such products until then. Points to post-quantum cryptography and to CNSSP-15 for updated guidance.
ANSSI (France), BSI (Germany), NLNCSA (Netherlands), Swedish NCSA, Swedish Armed Forces	Joint position paper on QKD, 26 January 2024	QKD needs specialised communication infrastructure, has functional limitations, fits only niche use cases and is not yet sufficiently mature from a security perspective. Organisations should prioritise migration to post-quantum cryptography.

The common thread is not that the physics is wrong. It is that a working QKD deployment still needs classical authentication, trusted sites, specialised hardware and careful evaluation, and that those dependencies limit where it makes sense. For the migration path the agencies recommend, see the Post-Quantum Cryptography Migration Guide.

How to assess a QKD proposal

If a business unit, telecoms partner or research collaboration proposes QKD, run it through a structured assessment rather than accepting or rejecting it on reputation.

Write down the requirement first. Which links, which data, what confidentiality lifetime, and what availability target. QKD is only relevant to fixed point-to-point links where you control the fibre or optical path.
Map the trust boundary. Draw every transmitter, receiver, trusted node, KMS and encryptor. Mark every place the key exists in clear and who has physical and administrative access.
Identify the authentication mechanism. Confirm how the classical channel is authenticated, how initial authentication keys are provisioned and rotated, and that this mechanism is itself quantum-resistant, as the NCSC advises.
Ask for evaluation evidence. Certification against ETSI GS QKD 016 or a national scheme, independent test reports on known attack classes, and the vendor's patching process for both firmware and classical software.
Define failure behaviour. Agree what happens when key generation stops: alert, fail closed, or fall back to a classical or post-quantum key exchange. Test it before go-live.
Pilot on one link. Measure real key rate, QBER and abort frequency over weeks, including during fibre maintenance, before any expansion.
Keep a rollback. Retain the existing encryptor keying method so the link can run without QKD if the pilot or a later incident requires it.

Small organisations will rarely meet the preconditions: dedicated fibre, physically secured relay sites and staff to operate optical equipment. Large telecoms operators, national research networks and organisations taking part in programmes such as the EU's EuroQCI are the realistic adopters, and even they combine QKD with classical and post-quantum mechanisms.

Where identity fits

Because QKD cannot authenticate the endpoints, every QKD link depends on machine identities: the authentication keys or certificates on each QKD device, KMS and encryptor, and the API credentials encryptors use to fetch keys. These are non-human identities with long lives and high impact. Inventory them, give each an owner, store them in hardware where possible, and plan their rotation and post-quantum migration. See the Post-Quantum Migration for NHIs Guide and the Cryptographic Key Management Guide.

Detection and measurement

A QKD link produces operational signals that belong in your monitoring, not just the vendor console.

QBER trend: a sudden rise can mean interception, fibre damage or equipment fault; a sustained drift can mean degradation.
Abort and restart events: each aborted session, with cause, sent to the SIEM.
Secret key rate and key buffer level: alert before the buffer empties.
Fallback events: any time an encryptor reused a key or switched to non-QKD keying.
Physical alarms: fibre tamper sensors and access logs at every trusted node.
KMS access logs: which encryptor or application requested which key, when.

Metric	What it shows	Target
Link availability with QKD-derived keys	Whether the link meets its service target without fallback	Agreed in the requirement, measured monthly
Mean QBER and number of threshold breaches	Channel health and possible interference	Stable baseline, every breach investigated
Number of fallback or key-reuse events	How often the design falls back to other keying	Zero unplanned; every event explained
Trusted nodes with current physical and personnel assurance	Whether relay sites are still trustworthy	100 percent
Authentication keys with owner and rotation date	Control of the classical authentication layer	100 percent

Common failure patterns

Treating QKD as encryption. Buying a QKD box and assuming traffic is now protected, without checking the encryptor, cipher and key handling that actually protect data.
Unauthenticated or weakly authenticated classical channel. Using the QKD link with authentication that is not quantum-resistant, or not authenticated at all, which removes the security property the deployment was meant to provide.
Forgetting the trusted nodes. Security reviews that cover the endpoints but not the relay buildings where keys are in clear, and the staff and contractors who access them.
Silent fallback. Encryptors that quietly reuse keys or drop to unprotected keying when QKD stalls, with no alert.
Trusting the datasheet. Accepting physics-based security claims without implementation evaluation, which NSA explicitly warns against.
Patching paralysis. Hardware-bound software that cannot be updated quickly, leaving known flaws in place.

Framework mapping

Framework	Reference	Relevance to QKD
NIST CSF 2.0	PR.DS-02	Protecting data in transit, the outcome a QKD link supports
NIST CSF 2.0	ID.AM-08	Lifecycle management of specialised QKD hardware and its firmware
NIST SP 800-53 Rev 5	SC-12, SC-12(1)	Key establishment and management, including key availability when generation stops
NIST SP 800-53 Rev 5	SC-8, SC-13	Transmission confidentiality and the cryptography actually protecting the traffic
NIST SP 800-53 Rev 5	SR-11	Component authenticity for specialised optical hardware
ISO/IEC 27001:2022 Annex A	A.8.24 Use of cryptography	Policy for cryptographic mechanisms and key management, including QKD-delivered keys
UK NCSC Cyber Assessment Framework	Data in transit	NCSC states QKD use should not count as evidence of data-in-transit security

Practitioner checklist

Confirm the requirement is a fixed point-to-point link where you control the optical path.
Draw every node where key exists in clear and assign physical and personnel assurance to each.
Document how the classical channel is authenticated and confirm it is quantum-resistant.
Request evaluation evidence, such as certification against ETSI GS QKD 016, and independent attack testing.
Define and test fail-closed or fallback behaviour before go-live.
Feed QBER, aborts, key buffer levels and fallback events into the SIEM.
Inventory the device, KMS and encryptor credentials as non-human identities with owners and rotation dates.
Record the NCSC, NSA and joint European positions in the risk assessment and the rationale for proceeding.

How quantum key distribution works: channels, BB84, trusted nodes and real limits