While the Quantum Internet is not yet here, the foundational quantum networks that will form its backbone are being developed and deployed today. At this stage, why would a quantum network require orchestration? As quantum networks grow, three big themes have emerged:
- Real-world demonstrations of quantum networking are already live or imminent.
- Building vendor agnostic quantum networks is absolutely essential for the Quantum Internet.
- A quantum network orchestrator makes large-scale, multi-vendor quantum networks usable, reliable, and practical for every day use.
A few years ago, quantum networking sounded like a research topic. Today, it’s a deployment topic.
Some of the most interesting demonstrations in recent news include:
EPB Quantum Network – Chattanooga, Tennessee
EPB, a utility company in Chattanooga, launched what’s often cited as the first commercial quantum network in the United States in 2023. It’s not a toy network or a one-off experiment; it’s operated as real infrastructure for testing quantum hardware, with the Aliro Orchestrator providing the orchestration layer.
The EPB Quantum Network has to behave like any other critical infrastructure. It has to be reliable, monitorable, maintainable. Orchestration is critical to these capabilities.
BrightNet – Entanglement-based Quantum Network at Aliro HQ
At Aliro’s headquarters in Brighton, Massachusetts, the BrightNet quantum network acts as both a testbed and a reference deployment. It is capable of running BBM92 quantum key distribution for Quantum Secure Communications (QSC). BrightNet is essentially a working quantum-secure VPN network.
Just like traditional networks, quantum networks need software to abstract the complexities of managing quantum hardware and ensure reliable, scalable operation of the quantum network:
- An operating system that manages device behavior and can perform adaptive operations
- A control plane to connect the quantum hardware and coordinate entanglement routing, monitor network health, apply traffic policies, and coordinate key generation.
Aliro Orchestrator and AliroOS are the software that ties everything together.
BrightNet demonstrates an end-to-end stack from physical quantum devices all the way up to QSC, and its performance has been benchmarked through simulation, theoretical models, and in real-world demonstrations. More about how BrightNet was built can be found in this white paper.
Boeing’s Quantum Entanglement Satellite
Boeing is making a big bet on quantum with its Q4S mission. Slated for launch in 2026, Q4S is a quantum satellite that will demonstrate free-space links from a moving satellite doing entanglement swapping in outer space.
Why does this matter? Because future global quantum networks will have fiber optic connections as well as satellite-based links, opening the door to truly global Quantum Secure Communications. Orchestration will provide the automation and control required for a successful mission.
SCY-QNet: Connecting Long Island and Beyond
Another major initiative is a regional quantum network spanning Long Island. The project involves a wide coalition: SUNY campuses, Brookhaven, Columbia, Yale, Ohio State, Chicago Quantum Exchange, NIST, NASA, IBM, Cisco, JP Morgan Chase, and multiple quantum hardware companies like Toptica, Single Quantum, Aliro, and Qunnect. SCY-QNet explicitly aims to be a “virtual quantum laboratory” that many users can access remotely. It’s designed as shared, configurable infrastructure.
SCY-QNet is an excellent example of working across heterogeneous devices and vendors, and it’s exactly the kind of collaborative deployment that is building the foundations of the Quantum Internet.
These projects show different topologies, environments, and goals, but they all share one message: quantum networks are being built now, with real vendors, real hardware, real constraints, and real users. And they all require a quantum network orchestrator to manage and run the network.
Why Orchestration Is Important to Quantum Networks Built Today
As illustrated with the examples above, once a quantum network moves beyond a lab bench with a couple of optical devices and becomes a quantum network with dozens or hundreds of components, the complexity of calibrating the hardware, coordinating operations, and managing the network usage becomes overwhelming for operators without a software management tool. This is precisely why orchestration becomes a vital component of the quantum network.
A good quantum network orchestrator solves three fundamental problems:
- How does the thing talk to the other thing?
- Why is the thing not working?
- How do I express “what I want” without micromanaging every device?
Let’s look at how a Quantum Network Orchestrator solves these problems.
1. Device and Protocol AbstractionIn the wild, quantum hardware doesn’t come with uniform, friendly interfaces. You’ll see:
-
- Different physical connections (USB, Ethernet, serial, proprietary connectors)
- Different protocols (DB9 serial, RS-232, VXI-11, proprietary APIs, NetConf, RESTConf, VISA, and more)
Without an orchestrator, operating a quantum network often means walking around with a laptop, plugging into one device after another, and remembering or reverse-engineering each device’s custom CLI or API. A vendor-agnostic orchestrator hides all of that behind a single interface:
-
- Implements drivers for the various management protocols
- Knows how to talk to each device type
- Presents devices as logical resources (e.g., “entangled photon source” or “QKD appliance”) rather than “that one box in rack 7 with the weird serial port”
From the user’s perspective it’s not important whether the device speaks NetConf or something exotic. The orchestration layer allows the user not to worry about these details and just tell the orchestrator what it is that needs to be done.
2. Resource Abstraction and Dynamic Routing
On an expanding quantum network, operators shouldn’t have to manually pick “photon source #13 in Equipment Room A.” It’s much simpler for a user to say, “I need an entangled photon source at 1440 nm with these characteristics,” and let the orchestrator discover which devices match the requirements, check which ones are online and not already in use, verify that they are optically routable to the other devices requested, then reserve and configure the chosen hardware for the application.
Quantum routing itself is so different from classical routing: there is no inspecting and forwarding quantum states because measuring them collapses the superposition that needs to be preserved for use in the application. So instead of packet-based routing, optical cross-connects are used: moving mirrors or switches that provide fixed but dynamically configurable light paths.
A quantum network orchestrator computes feasible optical paths, programs the cross-connects, and either sets everything up or tells the user clearly why the requested topology isn’t possible. All without anyone needing to know the fiber map by heart!
3. Monitoring, Errors, and Alarms
The orchestrator continuously collects telemetry. Things like:
-
- Qubit error rates
- Key buffer levels for QKD
- Device health and status
- Link performance
This telemetry can be displayed in a dashboard, or an orchestrator can be configured to raise an alarm when metrics cross defined thresholds. A quantum network orchestrator will also clearly surface operational errors such as “Device X in Rack Y is reporting this specific fault.” It integrates logs at multiple levels (orchestrator, device controller, device driver) so operators can choose how much detail they need in the logs.
The result is that instead of spending days hunting for the one misbehaving device, operators see exactly where the problem is and what’s wrong at a glance.
Turning Requests into ActionOne of the orchestrator’s most important roles is bridging the gap between service-level intent and low-level hardware control. For example, in a BBM92 secure communications scenario, the physical layer has entangled photon sources, beam splitters, and timing. At the application layer, a BBM92 appliance might integrate the physical hardware and use a quantum network operating system like AlirOS® to handle the protocol details internally. At the orchestration layer, a request for a service turns into action:
-> “Create a QKD link between Alice and Bob.”
-> “Monitor the qubit error rate.”
-> “Alert me if the key generation rate drops below X.”
The orchestrator translates that high-level request into concrete actions: select devices, configure them, set up optical routes, start the service, turn telemetry into dashboards and alarms. The orchestrator lets different users work at the layer of abstraction appropriate to their role, from physicists to network operators to application teams.
The Bottom Line
Quantum networks are no longer a distant vision. They’re being deployed in cities, across campuses, in labs, and via satellites. However, if we’re not careful, we’ll build a fragmented ecosystem of incompatible islands. To avoid that fate and apply hard-earned lessons from the early days of the classical Internet, we need vendor-agnostic quantum networking that lets organizations mix hardware, evolve their infrastructure, and avoid vendor lock-in.
In classical networking, orchestration turned messy, complex infrastructure into something operators could actually manage at scale. In quantum networking, the stakes are just as high. Quantum network orchestration will help to create and scale quantum networks that are usable, reliable, and practical for every day use.
For more details about how quantum network orchestration works, and why it's a vital part of building any functional quantum network, see our webinar Building Vendor-Agnostic Quantum Networks
