It is a Tuesday afternoon and a software vendor's support engineer is on the phone with your IT lead. There is a small fix for the system in the back office, he says — nothing urgent, just a patch that would clear up a reporting glitch. Could someone open a path into the network so he can push it through, just this once?
Your IT lead has read the same security reports everyone has. Most of the bigger break-ins of the last two years did not start with a stolen password. They started with exactly this: a vendor's remote-access tunnel, opened for a routine fix, left reachable a little longer than planned, found by someone who was not the vendor. So he says no. Then he is stuck, because the system genuinely does need updating sometimes, and there has to be a way for that to happen that is not "email me a file and I will run it at midnight and hope."
Why we build it this way
We think the air gap fails in exactly one way: the exception. No company we have spoken to set out to leave a door open. Every one of them opened it for a reason that sounded, at the time, entirely sensible — a vendor needed to push a fix, a consultant needed to look something up, a monitoring tool needed to phone home so somebody could see a dashboard. Each exception was small on the day it was made. None of them were ever closed afterwards.
The obvious answer to "how do updates reach a system with no internet connection" is to leave a channel open for them — a VPN, a support tunnel, a remote session the vendor can use when needed. We think that answer is wrong, because a channel that is open for updates is open, full stop. A firewall rule does not know that it is only meant to carry a signed patch on the third Tuesday of the month. It carries whatever arrives on it.
A channel that is open for updates is open, full stop.
So the rule runs one way, and it does not bend for anyone's convenience, including ours. Nothing crosses in except a signed update, delivered on a schedule the customer sets, applied by the customer's own administrator — not us, remotely, and not the vendor, just this once. The system holding your mail, your contracts and your CRM does not grow a second door because the first one was inconvenient on a Tuesday.
How it works, roughly
A signed update arrives as a package, not a session. It carries:
- the fix or the new model, signed so your admin can confirm where it came from and what version it replaces
- a plain description of what changes, written for someone deciding whether to apply it, not for an engineer
- nothing else — no live connection, no remote hands on the keyboard, no way for anyone outside the building to see what is running on the box in between
Your own administrator decides when it is applied, on your schedule rather than a vendor's calendar. He can read what is in it, hold it, or apply it; if something about it looks wrong, he can decline it and ask us in writing, with no clock running on him. If an update turns out to be a mistake once it is in, it comes back off the same way it went on, and the system returns to the version before it. Nobody on our side, and nobody at the vendor whose fix this stands in for, is ever given a session on your machine. That is not a convenience we are giving up. It is the whole point.
A year on this way, what you have is a system that has taken a year of fixes and never once opened a door to get them — and a log showing every update, when your own admin applied it, and what it changed. The decision to let anything in stays where it always was: with someone in your building, not ours.
See how the air gap is built →