Encryption for air gapped networks: does it need the cloud?

Encryption for air-gapped networks means encrypting traffic between sites, control rooms and data centres that have no permanent route to the public internet. The encryption has to work entirely on the organisation’s own equipment. It cannot depend on a vendor cloud, on telemetry or on online licence checks, and updates must be delivered in a controlled, offline way.

For operators of an OT network in energy, water, transport or manufacturing, this is a practical question more than a theoretical one. Many encryption products are now built on the assumption that they can always reach the internet. This article explains where that assumption breaks and what to check before you deploy.

Can network encryption work in an air-gapped network?

Yes. Network encryption is at heart a deal between two endpoints: they agree on keys and then encrypt packets, and neither step needs a third party on the internet. Problems only appear when a product adds outside dependencies, such as cloud management, licence validation or certificate services.

A gateway-based design shows why. One gateway sits at each end of the link. The two gateways authenticate each other, run a key exchange and encrypt everything that passes between them. Whether the link is dark fibre, a leased line or a segment inside a closed site network, the maths is the same.

The air gap is often less absolute than assumed

In practice, many “air-gapped” environments have controlled links: a connection to a second control centre, a historian link to corporate IT, or a vendor maintenance path. The President’s National Security Telecommunications Advisory Committee put it bluntly in its IT-OT convergence report: “This ‘air gap’ is rarely found when doing IT/OT risk assessments.” The same report warns that many systems can even “accidentally converge,” where the system owner does not even realize or have visibility into which devices reside where on their networks.

Those links are exactly where encryption matters most, and where an encryption product that “phones home” would itself create a new external connection.

Does network encryption need a cloud connection?

No. Network encryption does not technically need a cloud connection, but many commercial products are designed around one. The question to ask is not “does it encrypt?” but “which of its functions stop working if it can never reach the internet?”

Cloud dependency usually hides in four places:

• Orchestration: the tunnels are configured and their keys handed out by a controller hosted by the vendor.
• Licensing: the appliance checks its licence with an online service at intervals and may stop working if it cannot.
• Identity and certificates: device certificates are issued or renewed by an external service.
• Updates: software and signature updates are pulled automatically from a vendor endpoint.

In a truly closed network, each of these is either a point where the product will fail or a reason to punch a hole in the gap. Ask vendors to show how the product behaves after 30, 90 and 365 days with no outside connection at all.

What is telemetry in security appliances?

Telemetry is data that a security appliance sends back to its vendor on its own: health metrics, crash dumps, feature usage, licence status and sometimes samples of suspicious traffic or files. It usually travels over an outbound connection that the operator did not set up and cannot easily inspect.

Vendors use telemetry to find bugs, improve threat detection and manage licences. In an office network this is often an acceptable trade-off. The data can still reveal a lot, though: internal IP ranges, hostnames, interface counts, traffic volumes and uptime patterns. Together these describe how a facility is laid out and how it runs.

Why does telemetry matter for critical infrastructure?

For critical infrastructure, telemetry matters for three reasons. It is an outbound connection that breaks the isolation model. It can reveal the layout of the network. And it adds the vendor’s own infrastructure to your supply-chain attack surface.

It creates a path through the gap

An appliance that needs to reach a vendor endpoint forces operators to allow outbound traffic from inside the OT zone. Even if that traffic only goes one way, the firewall rule, DNS resolution and proxy exceptions it needs become permanent parts of the design that someone has to maintain and defend.

It widens the supply-chain attack surface

Every internet-facing device and every outbound service connection adds to the attack surface that has to be maintained, patched and monitored. An appliance that talks only to its peer gateway has fewer external dependencies than one that keeps contacting an external service.

It complicates regulatory accountability

Under the EU NIS2 Directive (Directive (EU) 2022/2555), Article 21 requires essential and important entities to manage supply-chain security. Knowing exactly what data leaves an OT environment, and to whom, is part of that, so every outbound connection an appliance makes needs to be known and documented.

How are security updates delivered to closed networks?

Security updates reach closed networks as signed offline packages. Staff download them on a connected system, check them, carry them across the gap under controlled conditions and install them from an internal update server during planned maintenance. Automatic online updates are replaced by a documented manual process.

A typical sequence looks like this:

1. Acquire: download the update on a dedicated staging workstation outside the OT zone.
2. Verify: check the vendor’s cryptographic signature and published hash, then scan the package.
3. Transfer: move it across by controlled removable media or a one-way transfer mechanism, and log who moved what and when.
4. Stage: place it on an internal update server, usually in the OT DMZ, which the appliances can reach without going to the internet.
5. Test and roll out: apply it first to a test pair of gateways, then to production during an agreed maintenance window, following patch guidance such as IEC TR 62443-2-3 and NIST SP 800-82.

Crypto agility needs the same path

Post-quantum cryptography is still changing, so gateways must be able to swap algorithms as well as fix bugs. An algorithm update is just another software update, and in a closed network it goes through the same verified, offline route. When you evaluate a product, check that algorithm changes do not require a live connection to the vendor.

Why does quantum-safe encryption matter for OT links now?

OT data and control links often stay in service for decades. Traffic recorded today could be decrypted once quantum computers can break current public-key algorithms. That makes key exchange on long-lived site links a priority now, not a problem to park for later.

The standards are ready. FIPS 203 was published on August 13, 2024, and it standardises ML-KEM, a mechanism used by two parties to establish a shared secret key over a public channel. NIST’s own transition draft notes that in order to mitigate the risk of “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.

Statistic: Under the transition timeline in NIST IR 8547, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier. (NIST, 2024)

Statistic: UK guidance summarised by CERT-EU says organisations should begin high-priority transitions by 2031, and full migration should be completed by 2035, though some technologies may take longer. (CERT-EU Cyber Brief 25-04, March 2025)

Statistic: To help critical infrastructure partners prepare for the adoption of post-quantum cryptography, CISA analyzed how each of the 55 NCFs is vulnerable to quantum computing (CISA Insight, 2022).

US agencies have singled out critical infrastructure directly. Then-CISA Director Jen Easterly said: “It is imperative for all organizations, especially critical infrastructure, to begin preparing now for migration to post-quantum cryptography.” The joint CISA, NSA and NIST factsheet adds that migration to PQC should be viewed as an IT/OT modernization effort.

What a closed-network design looks like in practice

Here is one concrete example of the properties described above. Quantum Network’s QPN gateway sends no telemetry, has no cloud dependency and supports air-gapped networks as well as site links over the public internet. It uses hybrid key agreement: a classical exchange and ML-KEM (FIPS 203) are combined into one session key, and both handshakes renew every two minutes. Payload traffic is encrypted with ChaCha20-Poly1305, and the connection never falls back to unencrypted traffic after a line failure. Automatic updates of algorithms and software need an active subscription. Without one, the gateway keeps working in its current state but gets no further support or security updates. That is exactly the kind of lifecycle behaviour to document for any closed-network appliance.

What should you check before deploying encryption in a closed OT network?

Check how the product behaves with no outside connectivity, what it tries to send out, how updates reach it, and how it fits alongside your existing firewalls. Test these in a lab that copies your real isolation, not in the vendor’s demo environment.

• Offline endurance: does it keep encrypting, re-keying and recovering from link failures for months without any external contact?
• Outbound traffic: does a lab capture confirm zero unexpected destinations?
• Licence behaviour: what exactly happens when a subscription or licence expires?
• Update path: can signed packages be installed from an internal update server or offline media?
• Placement: can it sit in front of a firewall that must keep inspecting traffic, or behind it where inspection is not needed, without redesigning the network?
• Algorithm roadmap: how will ML-KEM parameters or successor algorithms be changed over the device’s lifetime? This matches CISA’s advice to begin preparing now by creating quantum-readiness roadmaps, conducting inventories, applying risk assessments and analysis, and engaging vendors.