The Air Gap Is A Requirement, Not An Edge Case: Deploying Software On Disconnected Networks

Executive Summary

• A disconnected network is not an edge case in defence. It is the standard operating environment for anything classified, and software that cannot live on one is unsuitable regardless of how good the demo was.
• The software industry has spent fifteen years assuming the internet exists. Licensing check-ins, cloud management planes, online update repositories, and telemetry all become defects the moment the cable comes out.
• Air-gapped deployment done well is the discipline of making every transfer deliberate: offline repository mirrors, verified packages, rehearsed procedures, and patching on a cadence you own.
• Across a decade-long service life, the air gap makes vendor dependency compound, which is the strongest argument for open-source infrastructure inside the enclave.

Why the air gap deserves to be the subject, not a footnote

Air-gapped networks have come up as a supporting point in almost everything written for this newsletter. Proxmox activates offline, TrueNAS has no phone-home dependency, and so on, noted in passing and moved past. This piece makes the air gap the subject, because it is where a remarkable amount of modern software quietly fails, and the failure is rarely visible at the point of purchase.

A disconnected network is not an edge case in defence. It is the standard operating environment for anything classified, and increasingly for operational technology that is merely sensible. Software that cannot live on one is not partially suitable for this sector. It is unsuitable, however good the demo was.

The problem is that the software industry has spent fifteen years assuming the internet exists. Licensing checks in with the vendor. Updates arrive from a content delivery network. Management consoles live in the vendor's cloud. Telemetry flows home whether you asked for it or not. Each is a reasonable engineering choice for a connected world, and each is a defect on a disconnected network. Vendors know this, which is why "supports air-gapped deployment" appears on so many datasheets. What that phrase actually means varies enormously, and the variance is the whole point.

What breaks when the cable comes out

Licensing is the failure mode with the sharpest edge. A significant amount of enterprise software now validates its licence against a vendor server, either continuously or on a check-in interval. On a connected network you never notice. On a disconnected one, the software either cannot be activated at all, or activates and then degrades when the check-in window expires. NVIDIA's vGPU licensing is a concrete example that comes up in real work: it wants a licence server, and clients that cannot reach one eventually lose features. Offline arrangements exist, but they are something you must specifically engineer for rather than something the product naturally does. That distinction, between software that tolerates disconnection and software designed for it, runs through everything else.

The worst case is the cloud-managed product, where the management plane itself lives on vendor infrastructure. Cloud-managed networking hardware that becomes non-functional when its subscription lapses is bad enough on a connected network. Put the same product behind an air gap and it is non-functional on day one, because the controller it depends on is on the wrong side of the gap by design. No amount of configuration effort fixes an architectural dependency on somebody else's datacentre.

Updates are the subtler failure. Almost every operating system, hypervisor, and application now assumes it can fetch packages from an online repository. Disconnect it and the software still runs, which is why this problem hides during evaluation. What you have actually lost is the ability to patch, and an unpatchable system on a classified network is not one the accreditation process will smile upon. "The air gap protects us" is not a patching strategy. Air-gapped systems still run software with vulnerabilities, still accept data from outside via controlled routes, and still have users. The gap dramatically reduces exposure. It does not eliminate the obligation to maintain the system behind it.

Then there is telemetry, which deserves a blunter treatment than it usually gets. Software that phones home with usage data, crash reports, or product improvement analytics is doing something on a classified network that the security case must account for, even when it is benign. The practical question during accreditation is not whether the telemetry is harmful but whether you can prove what it contains and switch it off completely. With closed platforms you take the vendor's word. With open-source infrastructure the answer is verifiable in the one way that actually closes the question: the source is inspectable, and the network behaviour of the system can be audited against it.

Deployment is the discipline of making every transfer deliberate

Running software on a disconnected network is not mysterious. It is the discipline of making every transfer deliberate. Nothing arrives by accident, nothing updates itself, and everything that crosses the gap is chosen, verified, and recorded. Done properly, this is routine engineering practice. Done as an afterthought, it is a permanent source of friction the system's operators pay for over its whole service life.

The foundation is the offline repository. Rather than each system fetching packages from the internet, you maintain a mirror: a controlled copy of the operating system and application repositories, held inside the enclave and refreshed by controlled transfer. Debian-based platforms, which include Proxmox, make this straightforward, because the entire repository infrastructure is open and designed to be mirrored. The systems inside the gap point at the internal mirror and behave exactly as they would connected, except that the contents of that mirror change only when someone decides they should.

What crosses the gap gets verified before it is trusted:

• Signed packages, with signatures checked against keys that were themselves transferred and verified through a controlled process.
• Checksummed images, validated before deployment rather than after a problem appears.
• The complete set of packages, and for open-source software the complete corresponding source, held inside the enclave so the system is knowable in full.

This is where open-source repository tooling has a genuine structural advantage: signature verification is native to the package format, the whole chain is documented, and none of it depends on a live connection to the vendor to validate.

The deployment itself should arrive as close to finished as possible, which connects to the integration argument made previously. For air-gapped systems it sharpens further: the bench is on the connected side of the gap and the site is not. Golden images built and tested in a staging environment that mirrors the enclave, the hypervisor cluster proven on representative hardware, the update procedure rehearsed rather than described. The first time a procedure is executed should never be inside the gap, because inside the gap is where improvisation goes to die. There is no downloading the missing driver, no quick vendor support session with screen sharing. What you carried in is what you have.

Patching follows the same shape on a cycle. Updates accumulate at the mirror on the connected side, get applied to the staging environment, get soak-tested against the actual workload configuration, then cross the gap as a batch with release notes and rollback points. Snapshots and proper backups, and Proxmox Backup Server does this job well, mean a bad update inside the gap is an inconvenience rather than an incident. The cadence gets agreed with the accreditor rather than dictated by a vendor's release schedule. On a disconnected network, you own the tempo, and the software has to be the kind that lets you.

The ten-year version of the problem

Everything above describes year one. Defence systems serve for a decade or more, and the air gap makes vendor dependency compound in a way connected environments never quite see.

A connected system degrades gracefully when a vendor loses interest: updates slow, support gets worse, you migrate eventually. An air-gapped system depends on a supply line of updates, licences, and knowledge that must keep crossing the gap for the system's whole life. If the vendor discontinues the offline activation path, changes the licensing model mid-programme, or gets acquired by someone with different ideas about subscriptions, the disconnected deployment feels it first and hardest.

Exactly this class of event played out with the Broadcom acquisition of VMware, and the organisations with the least room to manoeuvre were the ones whose deployments were hardest to reach and slowest to re-accredit. The most captive customers got the least consideration, which should surprise nobody, because captivity was the point.

This is the strategic argument for open-source infrastructure inside the gap, and it is stronger there than anywhere else. Proxmox activates with an offline subscription key and is fully functional regardless of subscription state; the subscription buys the enterprise repository and support, not permission to run. TrueNAS has no capacity licensing and nothing to check in with. Beneath the specific products sits the structural guarantee: the source and the packages can be held locally, forever, and no commercial decision taken on the other side of the gap can reach across it and switch anything off. Support matters, and Novatech provides it with the clearances the sector requires. But support is a service relationship that survives on merit. It is not a hostage arrangement, and on a disconnected network the difference between those two things is the difference between an asset and a liability with a countdown attached.

The demonstration to ask for

The test to put to any vendor, Novatech included, is simple to state. Demonstrate the full lifecycle with no internet access at any step: install the product, activate it, patch it, restore it from backup, then let the support contract lapse on paper and show what the system does. Not a datasheet claim, a demonstration. Software that genuinely belongs on an air-gapped network passes without ceremony, because disconnection was a design assumption rather than an exception to be handled.

A surprising amount of the enterprise software market fails that test at one step or another, and the failures cluster exactly where the business model depends on the connection: activation, licensing, and the management plane. That is worth thinking about. The air gap does not just protect the network behind it. It is also a rather effective instrument for finding out which of your suppliers sell you software, and which of them sell you a tether.

Key Takeaways

• In defence, the air gap is the standard environment for classified work, not an edge case. Software that only tolerates disconnection rather than being designed for it is unsuitable, whatever the demo showed.
• The common failure points, licensing check-ins, cloud management planes, online-only updates, and telemetry, all cluster where a vendor's business model depends on the connection.
• Deploying well means owning every transfer: an offline repository mirror, native signature verification, rehearsed procedures, and patching soak-tested on the connected side before it crosses the gap.
• Over a decade, the air gap makes vendor dependency compound, and the most captive customers get the least consideration when a licensing model changes mid-programme.
• Open-source infrastructure that holds its source and packages locally, forever, removes the one risk the gap cannot: a commercial decision on the other side reaching across to switch something off.

To discuss Proxmox deployment, open-source infrastructure design, or migration from VMware for your defence programme, contact Ross Collins or reach out here.