Offline license activation air-gapped encryption gateway

Offline license activation for an air-gapped encryption gateway means licensing a device that has no route to the internet: entitlements are delivered as signed files, checked locally and moved across the air gap by hand. Nothing ever calls home, and because license status is kept separate from the data plane, a lapse in paperwork cannot interrupt encrypted traffic between sites.

For operators of substations, water treatment plants, pipelines and manufacturing lines, this is not a side issue. The gateways that protect links between sites, cloud environments and remote engineers often sit in networks that are deliberately isolated. How the vendor enforces its license decides whether a renewal date can become an operational incident.

Why does license enforcement matter for quantum-safe links in OT?

License enforcement matters because OT links run for decades and their encryption has to be upgraded during that time, while the license mechanism must never become a single point of failure. The regulatory and cryptographic timelines below show how long these devices have to stay supported.

The CRA itself recognises the problem: its recitals note that products intended for industrial settings, such as industrial control systems, often stay in use for much longer than five years. A gateway bought today may still be running when NIST’s 2035 disallowance date arrives. During that time it will need algorithm changes, renewals and probably hardware replacement, all at sites where nobody can just click “activate online”.

Can an encryption gateway be licensed without an internet connection?

Yes. A gateway can be licensed fully offline by exchanging signed files: the device produces a request file, the vendor returns a signed license file, and the gateway checks that file locally against a public key built into its firmware. No network path to the vendor is needed at any point.

How the offline exchange typically works

The usual pattern has four steps. First, an administrator exports an activation request from the gateway’s local management interface. Second, that file goes through the site’s controlled transfer process (for example a scanned removable-media kiosk) to a networked workstation in the corporate zone. Third, the vendor portal or a support contact returns a license file bound to that device’s identifier. Fourth, the file is carried back and imported. The gateway checks the signature and stores the license.

Two design details decide whether this works well over a 15-year lifetime:

• Re-hosting without the vendor online. When a gateway’s hardware fails at 3 a.m., the replacement unit must be able to take over without waiting for the vendor’s support desk to open. Ask whether spare units can be pre-licensed, or whether a cold-spare license can be held on site.
• The signature algorithm on the license file itself. A license file signed today with a classical algorithm will be checked for years. NIST IR 8547 includes signature algorithms such as RSA and ECDSA in its deprecation schedule, so ask vendors how they will move license and update signing to post-quantum signatures such as ML-DSA (FIPS 204).

What happens to a quantum-safe tunnel when a gateway license expires offline?

That depends entirely on the vendor’s design, and it is the most important question to settle before purchase. The safe behaviour is that the tunnel keeps encrypting exactly as before, and only updates and support stop.

At an air-gapped site, expiry is more likely than elsewhere: there is no automatic renewal, reminder emails go to people who may have moved on, and clocks on isolated devices can drift. The table compares the common enforcement behaviours.

QPN, the gateway from Quantum Network, takes the last approach: without an active subscription the gateway keeps working in its current state but no longer receives support or security updates, and the connection never falls back to unencrypted traffic.

How do offline license files avoid sending telemetry from OT networks?

Offline license files avoid telemetry by design when the request file contains only a device identifier and a nonce, the response is a signed statement of entitlements, and the gateway has no code path that reports usage data anywhere. If you can inspect every byte that crosses the air gap, you can be sure nothing else leaves.

A license exchange is a data export from a protected zone, so it should be handled like any other export. In practice this means:

• A documented, readable request format. Ask the vendor for the field list. A request containing tunnel counts, peer addresses, throughput figures or configuration hashes reveals the structure of your network.
• Licensing that is not tied to usage metering. Metered licenses (per gigabyte or per active tunnel) need usage reporting by nature. For isolated networks, per-device or per-site entitlements avoid that.
• No hidden cloud dependency. Check that time sources, certificate status checks and update checks do not try to reach external hosts. Firewall logs during a test period will show any attempts.

Some vendors make this simpler by building the gateway without any reporting channel. QPN, for example, sends no telemetry, has no cloud dependency, and is designed to run in OT environments, including air-gapped networks. Whatever the vendor says, confirm it with your own traffic capture before production use.

How are post-quantum feature upgrades unlocked at air-gapped sites?

Post-quantum upgrades reach air-gapped sites as signed offline bundles: a software or algorithm update plus, where needed, an updated license file. Both are checked on the gateway before activation and rolled out link by link, so that both ends of every tunnel always share a working key agreement.

Crypto agility is the reason this matters. NIST already selected HQC in 2025 as a backup to ML-KEM. Dustin Moody, who heads NIST’s Post-Quantum Cryptography project, framed it this way: “Organizations should continue to migrate their encryption systems to the standards we finalized in 2024.” A gateway that can only change its post-quantum algorithm through an online channel effectively has no crypto agility at an isolated site.

A practical rollout sequence

1. Verify outside the OT zone. Check the bundle’s signature and hash on a staging system before it enters the site.
2. Test on a lab pair. Bring up a tunnel between two test gateways using the new algorithm set and measure latency on representative traffic.
3. Upgrade one end of each link first to a version that supports both the old and the new key agreement, then move the peer, then retire the old setting.
4. Keep the previous bundle on site for rollback, stored on the same controlled media.

NIST suggests that, because of the “harvest now, decrypt later” threat, organizations may want to move key establishment to FIPS 203 first for data that is sensitive or must stay confidential for a long time. For OT, that typically means links carrying engineering files, safety system configurations and historian exports. As Moody also put it: “We understand there’s not one strategy that fits all use cases.” Order your air-gapped upgrades by the value of the data, not by the order of sites.

What should procurement contracts require about license enforcement for critical infrastructure gateways?

Contracts should require in writing that license status never affects the data plane, that offline activation and re-hosting are supported for the whole support period, and that the vendor states exactly what data leaves the device. These terms are much easier to agree before signature than afterwards.

The regulatory context supports this level of detail. The NIS2 Directive (EU) 2022/2555, Article 21(2), lists supply chain security and policies on cryptography among the minimum risk-management measures for essential and important entities. Commission Implementing Regulation (EU) 2024/2690 adds that entities should include adequate security clauses in contracts with direct suppliers. On the manufacturer side, the Cyber Resilience Act (EU) 2024/2847 requires the end date of the support period, at least month and year, to be stated clearly at the time of purchase.

For OT, IEC 62443-2-4 sets security program requirements for service providers that integrate and maintain industrial automation and control systems, and IEC 62443-4-2 sets technical security requirements for individual components. Both are useful as reference frameworks for contract wording. CISA Secure by Design puts the responsibility on manufacturers, and CISA’s Secure by Demand guide says customers should explicitly demand security as part of procurement. Jen Easterly, then CISA Director, said consumers “must demand that manufacturers prioritize product safety above all else.”

Clauses worth including

• Data plane independence: expiry of any license or subscription must not disable, throttle or decrypt existing tunnels, and must never trigger plaintext fallback.
• Offline lifecycle: activation, renewal, re-hosting to replacement hardware and algorithm upgrades must all be possible through file exchange, with documented turnaround times.
• Telemetry disclosure: a complete, versioned list of any data the device or its license files contain or send, with a right to audit.
• Support period alignment: a stated support end date that matches the asset’s planned life, plus continued access to security updates already issued.
• Signing key transition: a commitment to move license and update signatures to post-quantum algorithms ahead of the NIST IR 8547 deadlines.
• Escrow or continuity: what happens to license validation if the vendor stops trading or discontinues the product line.