Updating encryption on an air-gapped OT network means replacing or reconfiguring the cryptographic algorithms, firmware and keys of isolated encryption gateways without any online management channel. Every update has to travel on controlled physical media, be checked when it arrives, and be applied to matched pairs, so that both ends of each protected link keep using the same algorithms.
Before post-quantum cryptography, many operators updated isolated gateways once and then left them alone for years. That habit no longer works. Algorithm standards are now changing on a published schedule, so OT teams need a way to update encryption offline that they can repeat, audit and roll back.
Why do air-gapped OT encryption gateways need algorithm updates?
The algorithms that protect site-to-site links today have published end-of-life dates, and an air gap doesn’t push those dates back. Gateways installed now will very likely need at least one change of cryptographic algorithm while they are in service.
Two reference dates set the planning horizon:
| Milestone | Detail | Source and date |
|---|---|---|
| FIPS 203 (ML-KEM) published | This standard specifies three parameter sets for ML-KEM. In order of increasing security strength and decreasing performance, these are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. | NIST CSRC, 13 August 2024 |
| Proposed transition timeline | Quantum-vulnerable algorithms at 112-bit security strength - deprecated after 2030, disallowed after 2035 | NIST IR 8547 initial public draft, 12 November 2024 |
NIST states that 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. Critical infrastructure links that carry long-lived control data fall squarely in that high-risk group. Symmetric ciphers need less attention here, because NIST does not expect to need to transition away from these standards as part of the PQC migration. In practice, the key exchange and the firmware signatures are what will need to change.
How do you roll out post-quantum algorithm updates to air-gapped encryption gateways?
Run the rollout as an offline supply chain with five stages: acquire, verify, transfer, test, deploy. Every hand-off gets logged. Don’t let any single person or device carry an update across the gap without a second check.
Stage the update on the connected side
Download the update package on a dedicated, hardened staging workstation in the corporate or DMZ zone, not on an engineer’s everyday laptop. Check the vendor signature there first, and record the package version, hash and release notes in your change ticket.
Cross the gap with controlled media
Use write-once or freshly sanitised media assigned to that one change. Scan it at a media-inspection kiosk before it comes into the OT zone. Then check the signature a second time on the isolated side, because a signature that was valid on the connected side tells you nothing about what happened to the media in transit.
Test on a bench pair, then a pilot link
NIST SP 800-82 Rev. 3 notes that software updates on OT cannot always be implemented on a timely basis. These updates need to be thoroughly tested by both the vendor and the end user of the industrial control application before being implemented. Additionally, the OT owner must plan and schedule OT outages days or weeks in advance. For encryption gateways, the bench test should cover the protected traffic itself: polling cycles, historian transfers and any time-sensitive protocols. Check the latency and jitter against what the process can tolerate, and don’t stop at confirming that the tunnel comes up.
How do you verify firmware integrity when installing updates offline?
The gateway should check the vendor’s digital signature itself before it installs anything, so that the device acts as the final gate. Hash comparisons done by people are an extra layer on top of that check. They don’t replace it.
NIST SP 800-193 gives the reference model. Its guidelines rest on three principles: protection, detection and recovery. Under protection, the guidelines in this document describe mechanisms to protect firmware code by verifying updates using digital signatures. As author Andrew Regenscheid writes in the same publication, “Firmware should only be loaded from an authorized source, typically either the manufacturer of the system or of the platform device.”
Turned into an offline procedure, that means:
- Authenticated update only. SP 800-193 sets the principle of non-bypassability: it should not be possible for an attacker to modify device firmware outside of the authenticated update mechanism or, if supported, a secure local update. Disable any engineering or debug path that skips signature checks.
- Out-of-band hash confirmation. Confirm the published hash with the vendor over a different channel from the one you used for the download.
- Tested recovery. Keep a known-good image for every hardware revision on site, and practise the rollback before you need it.
- Post-quantum signatures on the roadmap. Firmware signatures are public-key cryptography too. NIST IR 8547 lists PQC: ML-KEM, ML-DSA, SLH-DSA, LMS, XMSS, so ask suppliers when their code signing will move to one of these.
How do you change algorithms on an air-gapped network without remote management?
Without remote management, every algorithm change is a coordinated local action at both ends of each link. How you sequence it depends on whether the new firmware can still talk to the old one.
| Approach | How it works | When to use it |
|---|---|---|
| Simultaneous cutover | Technicians at both ends apply the change in one shared window, with a phone bridge between them | Only when the old and new versions cannot negotiate with each other |
| Two-step, backward compatible | Upgrade the firmware at each end separately while it still supports the old algorithm, then switch the algorithm by configuration | Preferred: it splits the risk across two smaller windows |
| Parallel link | Bring up a new protected path next to the old one, move traffic over, then retire the old path | Links that carry safety-relevant or continuous traffic |
Whichever method you choose, write down the exact rollback trigger in advance (for example, the link fails to re-establish within a set number of minutes) and who has the authority to call it. Gateways that never fall back to unencrypted traffic will fail closed if the change goes wrong, which is safe but disruptive. That makes the rollback plan a safety step, so treat it as more than paperwork.
Products differ in how algorithm changes reach isolated sites, so ask suppliers explicitly. As one example, the Quantum Gateway from Quantum Network uses hybrid key agreement with ML-KEM, sends no telemetry and has no cloud dependency. Its post-quantum algorithm can be changed if necessary, and automatic updates of the algorithms and software require an active subscription. Physical gateways are leased together with the subscription and returned at the end of the contract.
What change management does IEC 62443 require for patching OT security devices?
IEC 62443 splits the responsibility. IEC 62443-2-3 guides the asset owner’s patch process, and IEC 62443-4-1 sets requirements for how the supplier develops, qualifies and delivers security updates.
Asset owner side: IEC 62443-2-3
The relevant document is IEC TR 62443-2-3:2015 Security for industrial automation and control systems - Part 2-3: Patch management in the IACS environment. It is a technical report rather than a normative standard, but auditors use it as the reference patch lifecycle: keep an inventory of devices and versions, check relevance when a patch is published, test, deploy, and document. ISA explained the difference from IT early on: for an IACS, in contrast, it is often necessary to perform extra testing and wait for the system to not be in use, and then apply the patch by hand.
Supplier side: IEC 62443-4-1
IEC 62443-4-1 includes a security update management practice. It covers how suppliers qualify updates, document them and deliver them in a way that lets users check they are authentic. When you buy encryption gateways, ask for the supplier’s update documentation and check that it describes a process for offline delivery.
Inputs and governance
Use CISA ICS advisories as a formal trigger for evaluation. Being air-gapped doesn’t make a device immune to a published vulnerability. It only changes how the fix gets there. NIST SP 800-82 Rev. 3 makes the scope explicit: “Change management is also applicable to hardware and firmware.” It adds that the change management process requires careful assessment by OT experts (e.g., control engineers) working in conjunction with security and IT personnel. The guide is widely used: SP 800-82 has been downloaded more than 3 million times since its initial release in 2006.
How do you keep algorithm versions consistent across isolated sites?
Keep one signed version manifest as the source of truth, and check every isolated site against it in person on a fixed schedule. Without a network, drift only shows up if somebody goes and looks.
- Cryptographic inventory per link. For each link, record both endpoints, the firmware version, the key-exchange algorithms and parameter set (for example, which ML-KEM level), and the date of the last change. NIST notes that organizations must identify where vulnerable algorithms are used and plan to replace or update them.
- Signed baseline file. Publish the approved versions as a signed document that travels with each update package, so technicians can compare what is on the device with what was approved.
- Scheduled reconciliation visits. Read the versions off the device during routine maintenance and send them back to the central inventory on paper or approved media.
- Short mixed-version windows. Set a maximum time a link may run with mismatched versions during a staged rollout, and escalate when it is exceeded.
- Wave planning by link, not by site. Algorithm agreement happens per link, so plan rollout waves around link pairs and hub sites rather than geography.
Consistency also matters for incident response. If a CISA ICS advisory or a NIST update affects a specific version, an accurate per-link inventory tells you within minutes which isolated sites are exposed, without anyone having to drive out and check.
Where Quantum Network fits
Quantum Network is a quantum-safe encryption gateway that protects the connections between your own locations, without replacing the network equipment you already run.