Most conversations about quantum key distribution stay on the physics. For an operator planning a deployment, the more pressing question is duller and more useful: how does a key get from the QKD layer into the encryptor that needs it? That is the job of ETSI GS QKD 014.
What the standard defines
ETSI GS QKD 014 specifies a REST interface over which an application requests key material from a key management system. It defines three operations: ask what a key store can offer, request keys, and request the matching keys by identifier at the other end of the link. Everything is expressed in ordinary HTTPS with mutual TLS, which means the equipment consuming the keys needs no quantum-specific software.
Why an identifier, not a channel
The two encryptors never exchange the key itself. One side asks for a key and receives both the key and an identifier; it sends only the identifier over the classical network. The far side asks its own key store for the key with that identifier. The key never crosses the network in any form, which is the entire point.
What it leaves open
The standard says nothing about how keys are produced, how a multi-node network routes them, or how a key store behaves when it runs dry. Those are implementation decisions, and they are where deployments differ most. A key store that blocks under load and one that falls back to a slower key source will both pass a conformance test and behave very differently on a Friday afternoon.
What to ask a vendor
Three questions separate a working integration from a demonstration. Which version of the specification is implemented, and is the interface exposed per link or per domain? What happens to a key request when the key store is empty, and is that behaviour configurable? And can the key store be driven by a controller that manages more than one link, or does every pair of nodes need its own integration?
If the answers are concrete, the integration is usually a day of work. If they are not, budget for a project.
