A live audio video VPN stayed encrypted for eight continuous hours using quantum physics keys delivered through ETSI's QKD 014 standard. The protocol works; the hardware still runs on one vendor.
Eight continuous hours of live, two-way audio and video ran on a virtual private network whose encryption keys came from quantum physics rather than from classical math. A new preprint describing the demonstration treats the run as a real-world stress test of one of the first classical VPN stacks to consume keys from the ETSI GS QKD 014 key-delivery interface, and the stack passed.
Quantum key distribution lets two endpoints generate shared random keys from the quantum properties of light, either single photons or the noise of a laser. The point is not speed. It is that any eavesdropper who taps the quantum channel disturbs the signal in a way the endpoints can detect, so a stolen ciphertext is not matched with a stolen key. The threat the technique actually addresses is the "harvest now, decrypt later" attack, in which an adversary records encrypted traffic today and waits for a future quantum computer to break it.
In the demonstration, the protected traffic was carried by standard IPsec-style encryption using the AES-256-GCM cipher, with the QKD-derived key material delivered through ETSI's QKD 014 interface. The interface is essentially a REST-style API that lets two Key Management Entities (KMEs), one on each side of the link, negotiate which key to hand a VPN endpoint next. Identifiers for those keys travel in-band, inside the encrypted tunnel, so the encryption layer does not have to understand the physics. Each endpoint pulls a matching key from its local KME, and the connection continues.
The team ran the stack twice. First against a controlled KME simulator, then end-to-end on two Jetson Xavier NX edge-class devices, each wired to a LuxQuanta NOVA continuous-variable QKD platform. Continuous-variable QKD encodes key bits into properties of a laser field rather than into single photons, which lets it ride on standard telecom hardware and is the cheaper of the two dominant QKD approaches. Eight hours of bidirectional voice and video followed, with no manual key handling, and the prototype held.
A different prior demonstration, the 100 Gbps quantum-safe IPsec VPN tunnel shown over 46 km of deployed fiber, pushed line rate. The new work trades raw bandwidth for an open, ETSI-standardized plumbing path that a classical VPN application can actually consume, on small, low-power edge hardware. The two efforts are complements, not competitors. The 100 Gbps work shows the upper bound of what QKD-over-IPsec can carry when the link is engineered for throughput. The new preprint shows what an application team can integrate when the link is engineered for standard interop.
ETSI QKD 014 is one of several competing key-delivery tracks. Other ETSI QKD specifications, ITU-T work, and IETF drafts are all trying to define how quantum-derived keys should move between a key-management layer and the network gear that uses them. The fact that a real VPN application could call QKD 014 like any other key API, and the keys arrived, is what the demo was designed to show.
The hardware that produced the keys came from one company. The NOVA platform sits inside a small, still-fragmenting supplier market, and LuxQuanta has been raising money to scale deployment. ETSI 014 is a protocol, not a product. A standard that only one company can implement is a single point of failure, no matter how clean the interface looks in a research paper.
The work is also a preprint, explicitly framed by its authors as a feasibility demonstration rather than a deployment guide. There is no published claim of production readiness, no service-level agreement, and no cost figure. Readers should plan around an honest milestone: a real, eight-hour, audio-and-video VPN run, encrypted with quantum-derived keys, delivered through a standardized API. The harder problem is that, today, the API and the hardware are still wired to the same company.