How to encrypt traffic between sites over the internet

To encrypt traffic between sites over the internet, you put a cryptographic tunnel between two of your own locations. Every packet that crosses the public internet then reaches outsiders unreadable, and any tampering shows up when the packet is checked. For OT and critical infrastructure operators, that tunnel now also has to hold up against future quantum computers, not just against today’s eavesdroppers.

The urgency comes from how long industrial data stays sensitive. Network diagrams, setpoints, maintenance schedules and grid or water topology often stay valuable for a decade or more. In their joint factsheet, CISA, NSA and NIST warn that cyber threat actors could be targeting data today that would still require protection in the future (or in other words, has a long secrecy lifetime), using a catch now, break later or harvest now, decrypt later operation. The factsheet was created to inform organizations, especially those that support critical infrastructure, about the impacts of quantum capabilities.

How do you encrypt traffic between two locations over the internet?

Place an encrypting gateway at each end of the link, route the traffic between your sites through those gateways, and use a key exchange that combines classical and post-quantum cryptography. The architecture is simple. Getting the cryptography and the placement right is where the work is.

Choose the layer you encrypt at

Site-to-site encryption is usually done at the network layer (Layer 3). At that layer the gateway encrypts whole IP packets, so every protocol riding on top travels inside the tunnel: SCADA polling, historian replication, engineering sessions, file transfers. You don’t have to change each application. This matters in OT, because many industrial protocols, such as Modbus/TCP, were never designed with encryption and can’t easily be retrofitted.

Understand where the quantum risk actually sits

An encrypted tunnel uses two kinds of cryptography. Symmetric algorithms encrypt the payload. Public-key algorithms agree on the keys. The quantum threat targets the second kind. According to NIST, quantum-vulnerable algorithms at 112 bits of security strength will be deprecated after 2030 and disallowed after 2035, and the draft lists RSA, (EC) Diffie-Hellman, MQV, ECDSA, EdDSA as vulnerable. NIST also states that NIST-approved symmetric primitives providing at least 128 bits of classical security continue to be approved. In practice, the key exchange is the part of your site-to-site links that has to change.

Use ML-KEM in a hybrid key exchange

NIST’s answer for key establishment is ML-KEM. FIPS 203 specifies a cryptographic scheme called Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), which is derived from the CRYSTALS-KYBER submission. Most operators deploy it in hybrid mode, combining a classical key exchange and ML-KEM into one session key. NIST describes hybrid as intended to be secure as long as at least one of the component algorithms is secure.

A workable rollout sequence

1. List every link between your sites: control room to substations or pumping stations, plant to data centre, site to cloud, and engineer to site.
2. For each link, note what data crosses it and how long that data has to stay confidential.
3. Choose where each gateway goes relative to your existing firewall (see below).
4. Start with the links carrying the longest-lived data, and confirm how they behave when the line fails before you move on.

Is traffic between sites over the public internet secure?

Not by default. Traffic on the public internet passes through networks you don’t control, so it’s only as secure as the encryption you add yourself. Even encrypted traffic can be recorded today and attacked later if its key exchange is quantum-vulnerable.

There are two separate exposures. The first is plaintext: industrial traffic sent across shared or carrier networks without any tunnel. The second is subtler. A link that uses classical key exchange only is secure against today’s adversaries, but its recorded traffic could be decrypted once a cryptographically relevant quantum computer exists. Nobody can give a firm date for that. These are the reference points standards bodies and researchers use:

What is the difference between encrypting the connection and encrypting the devices?

Encrypting the connection protects data while it moves between your sites. Securing the devices protects the endpoints themselves: what they store, run and accept. The two cover different risks, and one does not replace the other.

This difference is why link encryption fits OT so well. Many controllers can’t run modern cryptography, and changing them means re-validation and downtime. A gateway in front of the site protects everything that leaves it, without touching the controllers. The flip side matters just as much: the tunnel will faithfully carry whatever a compromised workstation sends. Hardening, segmentation and monitoring inside the site are still needed.

Do I need to replace my firewall to encrypt traffic between sites?

No. A dedicated encryption gateway can sit alongside your existing firewall and routers, and you integrate it by adding or adapting routes. What decides the placement is whether the firewall still needs to inspect the traffic on that path.

Placement is the main design decision. If the firewall has to keep inspecting traffic between sites, the gateway goes in front of it, on the internet-facing side. The firewall then sees decrypted traffic and enforces its rules as before. If a path needs no inspection, for example a dedicated replication link, the gateway can sit behind the firewall.

Quantum Network’s QPN gateway follows this model. It runs as hardware or software at each end of a connection, encrypts at Layer 3 with a hybrid key agreement that includes ML-KEM, and needs no software on the equipment behind it. Be just as clear about what such a gateway doesn’t do. QPN does no web filtering, no email malware scanning and no anti-virus. It is not a defence against denial of service, and it protects data in transit, not the devices behind it. Your central firewall keeps all of those jobs.

How do you protect the link between a control room and remote sites?

Put a gateway at the control room and one at each remote site. Make sure the link stays encrypted when the line fails and recovers. Give remote engineers their own encrypted access path instead of opening ports into the OT network.

Design for failure, not just for normal operation

Remote sites often sit on cellular, radio backhaul or consumer-grade broadband that drops regularly. Test what your encryption does when that happens. The connection should never fall back to unencrypted traffic, and it should recover without anyone travelling to the site to restart it. Ask any solution directly whether a failed handshake can ever lead to plaintext forwarding.

Keep the key exchange fresh

Frequent re-keying limits how much traffic any single session key protects. For long-lived control links that may stay up for months, check how often the classical and post-quantum handshakes renew. Also check whether the post-quantum algorithm can be swapped if cryptanalysis changes. NIST notes that it is developing additional standards to serve as backups or alternatives, so crypto agility is a practical requirement, not a nice extra.

Account for air gaps and telemetry

Some links between sites don’t touch the internet at all. Encrypting private and air-gapped links still makes sense, because “private” lines run through carrier equipment and shared cabinets. In these environments, check that the gateway works without a cloud connection and sends no telemetry out of the network.

Handle remote engineers separately

Vendor and engineer access is often the weakest link between a control room and its remote sites. A software client on the engineer’s laptop that connects outward, so the site needs no incoming firewall ports, keeps the network free of open inbound ports. For cloud-hosted historians or analytics, a virtual gateway in your own cloud tenancy or data centre extends the same protection from the edge to the cloud.

Which standards and policies shape quantum-safe site-to-site encryption?

The technical baseline is NIST’s FIPS 203 for ML-KEM. The timelines come from NIST IR 8547 in the United States and the EU coordinated roadmap in Europe. Both point critical infrastructure toward migrating early.

In the United States, NIST IR 8547 builds on National Security Memorandum 10, which states that the United States must prioritize the timely and equitable transition of cryptographic systems to quantum-resistant cryptography. NIST’s own guidance is direct: organizations must identify where vulnerable algorithms are used and plan to replace or update them.

In Europe, Commission Recommendation (EU) 2024/1101 calls for deployment across the Union of Post-Quantum Cryptography technologies into existing public administration systems and critical infrastructures via hybrid schemes. The EU Member States, supported by the Commission, adopted the Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography in June 2025, and all Member States should start transitioning to PQC by the end of 2026.

Agencies have been clear about the timing. At the release of the joint factsheet, CISA Director Jen Easterly said: “It is imperative for all organizations, especially critical infrastructure, to begin preparing now for migration to post-quantum cryptography.” For the connections between your sites, preparing means three things: an inventory of every link, a decision on where each gateway goes relative to your firewalls, and a hybrid key exchange built on ML-KEM.