How to set up a secure edge to cloud connection

A secure edge to cloud connection is an encrypted network path between a remote edge location (a substation, pumping station, factory floor or wind farm) and the private cloud or data centre where its data is processed. In practice, an encryption gateway at each end creates a tunnel, so every packet crossing untrusted networks is confidential and authenticated.

For organisations that run operational technology (OT) and critical infrastructure, the design of that tunnel now has to account for quantum computing. This article covers how edge to cloud encryption works, where the gateways go, and when a virtual gateway in your own data centre is the right choice.

What is edge to cloud encryption?

Edge to cloud encryption protects data between the edge computing layer, where it is produced, and the central environment where it is stored or analysed. It usually works at the network layer, so all traffic between the two ends is covered, whatever application generated it.

Edge computing moves processing close to sensors, PLCs and local historians. Still, some of that data always travels upstream: aggregated telemetry, alarm streams, maintenance data, firmware packages and model updates going the other way. That path often crosses the public internet, a carrier’s MPLS network or a shared mobile network. None of these is under your control.

Encrypting at Layer 3 (the IP layer) means everything above it travels inside the tunnel: Modbus/TCP, DNP3, IEC 60870-5-104, OPC UA, SSH, file transfers. This matters in OT, where many devices cannot be patched or given a modern TLS stack. The gateway does the cryptography for them, and nothing has to be installed on the equipment behind it.

Why the key exchange is the weak point

The symmetric ciphers that encrypt the payload are not the main quantum concern. The risk sits in the public-key exchange that agrees the session key. Recorded traffic protected by a classical key exchange could be decrypted later, once a large enough quantum computer exists. For this reason NIST notes that, to reduce “harvest now, decrypt later” attacks on network communications, application-specific guidance may require or recommend migration to quantum-resistant key establishment schemes before the classical schemes are generally disallowed.

Why does edge data need quantum-safe protection now?

OT data and OT equipment both last a long time, and much of the edge hardware being installed today will still run when quantum-capable adversaries may exist. Traffic recorded now can be kept and attacked later.

According to the Global Risk Institute’s 2024 survey, the probability of cryptographically relevant quantum computers has risen to 34% by 2034, double the 17% the 2022 assessment gave for the same date. In Europe, all Member States should start transitioning to PQC by the end of 2026, and high-risk use cases should move to PQC as soon as possible, no later than the end of 2030. The EU also points out that many devices currently in production could have lifetimes spanning 10 years or more, extending into the period when quantum computers are expected to be available.

The Dutch AIVD and NCSC put the priority plainly in their migration guide: “Based on current insights, the ‘store now, decrypt later’ scenario is the most urgent threat for organisations.” For OT operators, the implication is that grid topology, process recipes and asset data crossing a WAN today need protecting against decryption years from now.

How do you securely connect edge sites to a private cloud?

Put an encryption gateway at each end of every edge-to-cloud path, route the relevant subnets through it, and use a key exchange that combines classical and post-quantum cryptography. The existing firewalls and routers stay where they are.

1. Map the flows before choosing hardware

List which edge subnets talk to which private cloud or data centre subnets, over which carrier, and in which direction. Many OT environments turn out to have a handful of well-defined flows (historian replication, SCADA polling, remote engineering). Those flows become the tunnels. This inventory also doubles as the cryptographic asset inventory that migration guidance from NIST and NCSC-NL asks organisations to build.

2. Decide where the gateway sits relative to the firewall

If your central firewall has to keep inspecting OT traffic, the gateway goes in front of it. Traffic is then decrypted before it reaches the firewall, so inspection still works. On paths where inspection is not needed, the gateway can sit behind the firewall. In both cases integration is a matter of adding or adapting a few routes, not redesigning the network.

3. Choose the key agreement: hybrid, with ML-KEM

ML-KEM is the post-quantum algorithm NIST standardised for key establishment. The standard is based on the CRYSTALS-Kyber algorithm, which has been renamed ML-KEM, short for Module-Lattice-Based Key-Encapsulation Mechanism. A hybrid design combines a classical exchange and an ML-KEM exchange into one session key, so the connection stays secure as long as either one holds. The EU roadmap work likewise recommends hybrid and crypto-agile approaches.

NIST’s Dustin Moody, who leads the PQC standardisation project, urged early action when the standards were published: “We encourage system administrators to start integrating them into their systems immediately, because full integration will take time.”

4. Plan for crypto agility

Algorithms can change. NIST has already selected HQC as a backup, while HQC is not intended to take the place of ML-KEM, which will remain the recommended choice for general encryption. Make sure your gateway can swap its post-quantum algorithm through an update, without replacing hardware at dozens of remote sites.

Can an encryption gateway run as a virtual machine in my own data centre?

Yes. At the central end of an edge to cloud design, the gateway is commonly deployed as a virtual machine on your own hypervisor, in your own data centre or private cloud, while the edge sites use physical appliances.

A central virtual gateway fits naturally, because the data centre end terminates many edge tunnels and already has virtualisation, redundancy and monitoring in place. It keeps the tunnel endpoint on infrastructure you operate, which matters for organisations that do not want key material or traffic passing through a third party’s service.

As an example of this model, Quantum Network’s QPN gateway supports edge to cloud deployment with a virtual gateway running in the organisation’s own data centre or cloud on a supported Linux platform. The gateway sends no telemetry and has no cloud dependency. The same product family also works in air-gapped networks.

What is the difference between a physical and a virtual encryption gateway?

A physical gateway is a dedicated appliance, suited to edge sites with no local compute platform. A virtual gateway is software on a hypervisor, suited to data centres that need higher aggregate throughput and already run virtualised infrastructure.

The cryptography is the same in both forms. What differs is capacity and operations. A single central virtual gateway can serve many edge appliances, which is why mixed designs (physical at the edge, virtual at the core) are common. Latency overhead for this kind of gateway is typically around 1 ms, depending on load and distance. That is small next to the polling intervals of most SCADA systems.

How do you protect data from edge locations on the way to the data centre?

Encrypt the whole path at the network layer, renew keys often, never allow the connection to fall back to plaintext, and be clear about what the tunnel does and does not cover.

Properties worth insisting on

• Per-packet authentication. Every packet should be integrity-checked, so injected or altered commands are dropped. QPN, for example, encrypts payloads with ChaCha20-Poly1305 and checks every packet with Poly1305 authentication tags.
• Short key lifetimes. Frequent rekeying limits how much traffic any single key protects. In QPN both the classical and the post-quantum handshakes renew every two minutes.
• No plaintext fallback. After a line failure the tunnel should retry by itself and never send traffic unencrypted, which is essential for unmanned sites.
• No agents on OT devices. Protection should not depend on installing software on PLCs, RTUs or HMIs.

Know the boundaries

A tunnel protects data in transit, not the endpoints. An encryption gateway does not filter web traffic, scan email or replace antivirus, and it is no defence against denial-of-service. Segmentation, firewall inspection and endpoint hardening remain separate controls. Plan them alongside the tunnel, not instead of it.

Extending the model to remote users

Engineers and vendors who connect to edge sites are a third path next to site-to-site and edge-to-cloud links. A software client on Windows or macOS that uses the same hybrid key agreement brings remote sessions up to the same standard. Clients that need no incoming firewall ports keep the attack surface on the laptop side small.

Rollout effort is usually modest once the flows are mapped. For a team that knows its own IP plan, installing a gateway takes about half an hour per device. Most of the real work goes into the flow inventory and the routing changes around each gateway.