Marin Ivezic
In October 2008, researchers demonstrated a six-node quantum key distribution network in Vienna, assembling hardware from several European research groups into one working system. Every interface between those boxes had been negotiated in advance by the people who built them. That is how the field worked for a decade. Eleven years later the International Telecommunication Union (ITU) published Recommendation Y.3800, the first international standard that treats a quantum key distribution network as an architecture rather than an experiment.
Quantum key distribution (QKD) generates a shared secret key between two locations by encoding bits in the quantum states of single photons. Measuring those states disturbs them, so an eavesdropper on the link raises the observed error rate and gets noticed. What QKD produces is key material, not encrypted traffic. Those keys still feed ordinary symmetric encryption, usually the Advanced Encryption Standard (AES), running on ordinary equipment. For an architect that distinction defines the whole integration problem: QKD is a key supply system, and it has to be plumbed into everything that consumes keys.
What Y.3800 Standardizes
An ITU-T Recommendation is ITU’s term for a standard, and Y.3800 carries the title “Overview on networks supporting quantum key distribution”. It came out of Study Group 13, the group responsible for future networks, with contributions from national laboratories and vendors including Japan’s NICT, NEC and Toshiba. The standard abbreviates its subject as QKDN, a quantum key distribution network.
The Recommendation says almost nothing about physics. It assumes the quantum link already works, and it does not specify photon sources, detectors, or the key exchange protocol itself. What it specifies is everything above the link: which components a network needs, how they stack, what each layer must do, and where the boundary sits between the quantum network and the network that uses it.
Y.3800 divides a QKDN into four layers.
Quantum layer. The QKD modules and the fiber or free-space links between them, producing raw key material on each direct connection.
Key management layer. Key managers at each node store keys, relay them across the network, and supply them to applications on request. This is the layer where a pair of links becomes a network.
QKDN control layer. Routing, path selection and resource control. It decides which chain of links carries a key between two nodes with no direct connection.
QKDN management layer. Fault, configuration and performance monitoring across the network, in the same way an operator manages any other transport infrastructure.
Alongside these sits the user network, with its own service and management layers, and a defined interface across which applications ask for keys. That interface is the one to watch during procurement. It decides whether a virtual private network (VPN) gateway or an optical encryptor can draw keys from any supplier’s node, or only from the supplier that sold it.
Key Relay and the Node You Have to Trust
Take three sites. A and B share a QKD link. B and C share one. A and C have no fiber between them, and building one isn’t an option.
The answer in Y.3800’s model is key relay. A and B already hold a key produced by their own link, call it K-AB, and B and C hold K-BC. A generates the key it wants to share with C, encrypts it under K-AB, and sends the result to B over the ordinary classical network. B decrypts it, re-encrypts the same key under K-BC, and forwards it to C. A and C now hold a common key without ever having exchanged a photon.
That relay has a cost. Inside B, the key exists in plaintext for as long as the re-encryption takes. B is what the standard calls a trusted node, and the word is a requirement rather than a description. Whoever controls B controls the key. The security of an A-to-C key is bounded by the physical security, access control and supply chain integrity of every relay node on the path – which means a QKDN extends your trust boundary to every site it passes through, including sites you do not own. Y.3800 names the problem and leaves the controls to other documents.
The Rest of the Family
Y.3800 is deliberately an overview, and the detail arrived in the Recommendations that followed it. Y.3801 sets functional requirements for a QKDN. Y.3802 gives the functional architecture. Y.3803 covers key management and Y.3804 covers control and management, with later items in the series addressing software-defined networking control and quality of service. In parallel, ITU-T Study Group 17, the security group, published a security framework for these networks in X.1710, followed by Recommendations on key management security and on combining QKD keys with keys from other sources. PostQuantum.com covers the original publication in more depth.
One family is missing from that list, and integrators use it more than any of the others. ITU describes the model; ETSI specifies the interfaces. The Industry Specification Group on QKD at ETSI, the European standards body, publishes the application interface in GS QKD 004 and a REST-based key delivery interface in GS QKD 014. When a vendor says its node is standards-compliant, ask which family they mean, because the two are not interchangeable.
What the Standard Leaves Open
Trusted nodes stay trusted. Removing them requires quantum repeaters, devices that extend entanglement over long distances so that no intermediate site ever holds a readable key. They remain a laboratory technology, and no architecture document changes that.
Authentication is classical. A QKD link resists eavesdropping only if the classical channel running beside it is authenticated. That authentication uses pre-shared symmetric keys or conventional digital signatures, so a QKD deployment inherits a familiar key management problem on day one.
QKD is not a replacement for post-quantum cryptography. Post-quantum cryptography (PQC) means classical algorithms designed to resist attack by a quantum computer, standardized by the US National Institute of Standards and Technology (NIST) as ML-KEM for key establishment and ML-DSA for signatures. PQC is software and it reaches every endpoint you have. QKD is hardware, fiber and site security, and it reaches the links you build for it. The US National Security Agency and the UK National Cyber Security Centre both advise against QKD for national security systems and point to PQC instead, citing cost and the trusted node requirement. Programs in the European Union and China are funding QKD infrastructure regardless. An architect should be able to state both positions accurately before recommending either. For the PQC migration side of that work, pqcframework.org sets out the methodology.
Using Y.3800 in Practice
The Recommendation earns most of its value as shared vocabulary. Three uses hold up in real projects.
- Vendor mapping. Place every product a supplier offers onto the four layers. Most vendors sell into one or two of them, and the gaps in a proposal become visible in a single page.
- Trust boundary documentation. List every trusted node on every key path, name its owner and its physical controls, and attach that list to the risk assessment rather than to the network diagram.
- Interface specification. If applications have to consume keys from more than one supplier, cite the ETSI key delivery interface in the requirement. Citing Y.3800 alone specifies a model, not a connector.
Multi-node QKD is no longer hypothetical. The Tokyo QKD Network and the Beijing-Shanghai backbone both operate over trusted relays, and European national programs are building out metropolitan links. The architecture questions these deployments raise are the ones Y.3800 was written to organize.
Learning the Architecture
Quantum networking falls between two established skill sets. Optical transport engineers know the fiber, the loss budget and the operational model, but not the quantum layer. Cryptography specialists know key management, but not the physical plant. The architects who are useful on these projects can read Y.3800, an ETSI interface specification and a vendor proposal in the same afternoon, and can say plainly which parts of a claim are standardized and which are marketing.
That’s the gap our quantum networking curriculum is built to close. It works through the QKDN layer model, key relay and trusted node analysis, the ETSI interfaces, and the QKD and PQC decision as procurement teams actually encounter it. You can see the full program at quantumacademy.com/.