If your RFP includes the phrase "air-gap ready", you have already lost the conversation. The phrase is a checkbox vendors tick, and at least two-thirds of the products that tick it fail a five-minute network capture on a quiet Saturday morning. We have stood in operations centres for a defence enterprise, a hydro utility, and an air-gapped manufacturing plant while their network team produced packet captures that lit up like a Diwali sky every time the "air-gapped" product was opened.
Air-gap readiness is not a feature you toggle. It is a series of architectural decisions made years earlier that compound into a product whose entire control and data plane can run without ever attempting an outbound connection. If those decisions were not made early, no amount of late-stage configuration will produce them. This post is the audit playbook — and the operational reality — that buyers in regulated, sovereign or genuinely sensitive estates need to understand before they sign.
The four leaks that always show up
When a product fails an air-gap audit, the failure almost always sits in one of four categories. We list them in the order we typically find them, fastest to slowest.
Phone-home telemetry SDKs
Most enterprise software in 2026 ships with one or more third-party telemetry SDKs embedded — error reporting, anonymous usage analytics, performance traces, feature-flag fetchers. Each of those phones home on a different schedule and to a different endpoint. The vendor may have honestly meant the product to be air-gap capable, but the SDKs were added by a separate team for a separate reason and nobody checked them on the way out. A five-minute pcap finds them. They are also the leak that vendors are most likely to be casual about, because none of them carry "customer data" — they carry crash IDs, feature toggles, and millisecond traces.
License-server pings
The product needs to validate its licence. The licence-server is hosted on the vendor's cloud. The product retries on a back-off, indefinitely, until either it gets a 200 or someone turns it off. Some vendors offer an offline-licence file; in our experience, roughly half of those still call home on the first install to "activate" the file, and a quarter call home every 30 days for a refresh. Read the EULA, then read the binary.
Cloud-hosted control planes
The data plane runs on your hardware. The control plane — the policy compiler, the alert router, the agent management UI — lives in the vendor's cloud. Customers do not always realise this until they try to bring the network down for a security exercise and the entire product loses the ability to push a new detection rule. "Air-gap deployed" and "air-gap operable" are not the same thing. The buyer needs both.
External threat-intel calls and corpus updates
Every modern detection product wants fresh intelligence — IoCs, signatures, behavioural pattern libraries. By default those are pulled from the internet on a daily or hourly schedule. In an air-gapped estate, the default is wrong. The product must support corpus updates as offline bundles, signed, with full provenance, sideloaded via an internal mirror. If the product silently fails open when the corpus is stale, you have a different problem; the corpus must continue to operate with whatever it last had, and the staleness must be surfaced to the operator.
What real air-gap readiness looks like
Air-gap readiness is the sum of five architectural commitments. They show up early in the product's life — usually in the first version — and are hard to bolt on later. When you see all five, you have a product that will pass an audit; when you see fewer than four, the badge is marketing.
1. No outbound calls at any tier
Every product subsystem must have a documented, default-on configuration that makes zero outbound connections. Crash reporting writes to local disk. Feature flags are read from a local file. The licence is a file or a hardware token, not a server call. The product can be packet-captured for thirty days and the only traffic that appears is what the operator explicitly enabled.
2. Internal mirror service for corpus and updates
The vendor publishes signed corpus bundles — detection content, IoC packs, behavioural pattern libraries, software updates — that an operator can host on an internal mirror. The product fetches from the mirror on its own schedule, verifies the signatures locally, and surfaces freshness as a first-class metric in the UI. There is a documented process for moving the bundles across the air gap (typically signed media or a one-way diode), and an audit log of every bundle applied.
3. Full functionality without internet
Every feature that exists in the connected deployment also exists in the air-gapped deployment. This sounds obvious; it is the most commonly violated commitment. Some vendors quietly disable threat-intel enrichment in air-gapped mode, or remove the agent-management UI, or hide the natural-language query feature because the model is hosted off-prem. If the buyer cannot list, by feature, what is preserved versus degraded under air-gap, the answer is "nothing is preserved".
4. Models, indexes and embeddings travel with the product
If the product uses ML — and they all do — every model, vocabulary, vector index, and embedding table must ship as part of the offline bundle. None of them can be pulled at runtime from a vendor-hosted endpoint. The corpus update process refreshes them on the operator's schedule, and the product must continue to function on whatever it last applied.
5. The control plane is co-located with the data plane
The policy compiler, the alert router, the agent management UI, the case manager, the reporting engine — every administrative surface — runs on the same hardware as the data plane. There is no "out-of-band" management console hosted by the vendor. When the operator brings up the air-gapped environment cold, every piece of the product comes up with it.
The compliance lens
Air-gap readiness intersects with several active regulatory frameworks. The table below is what we walk compliance leads through when sizing the scope of an air-gap audit. None of these standards explicitly mandate air-gap, but each contains clauses that bite hard when a product phones home.
| Concern | Why air-gap helps | What auditors actually check |
|---|---|---|
| DPDP cross-border transfer | Eliminates any vendor-side processing path | Network egress logs, vendor-side data-residency proofs, contractual carve-outs |
| Sectoral CIA mandates | Removes external dependencies during incident-response | Documented operability without internet, last-corpus-applied evidence, run-books for offline updates |
| ISO 27001 supplier risk | Reduces blast-radius of vendor compromise | Supply-chain map for corpus bundles, signature verification logs, restricted update channels |
| Sectoral regulators (energy, banking) | Demonstrates operational resilience under network isolation | Drills with WAN deliberately severed, time-to-detect drift, last-known-good fallback |
A run-book for evaluating "air-gap ready" claims
If you are about to evaluate a product, here is the run-book we use. It takes a working day. It will tell you the truth in a way no slide deck will.
# Day plan — air-gap readiness evaluation
09:00 Provision a sandbox VLAN with no default route.
Permit only DNS to an internal resolver that logs all queries.
09:30 Install the product per the vendor's air-gapped install guide.
Capture all outbound at the firewall (pcap + per-flow log).
10:30 Boot, log in, click every feature in the UI for 60 minutes.
Note any feature that returns "unavailable" or a timeout.
12:00 Trigger a corpus refresh from the local mirror.
Verify signature, freshness, and audit-log entry.
13:30 Generate a synthetic incident end-to-end:
ingest → detect → enrich → respond → report.
Confirm no outbound traffic at any stage.
15:00 Force-rotate the licence file. Confirm no phone-home.
Pull the network entirely for 60 minutes. Re-test core flows.
16:00 Review pcap, DNS logs, and audit logs.
Every destination is a finding. Every "unavailable" feature
is a gap in the offline build.
17:00 Document and walk the vendor through the findings.
Their answers tell you who you are buying from."Half the products we tested had outbound traffic within ten seconds of first login. The two that did not were both built by teams who had operated air-gapped estates themselves before they shipped a product." — Network engineer, defence sector enterprise.
The operating reality
Air-gap is not a state. It is a discipline. Even with a perfectly air-gap-capable product, the operating team must own a workflow for moving signed corpus bundles across the gap on a schedule, validating signatures, applying them, and proving freshness to the auditor. They must own a drill — at least annually — where the WAN is severed deliberately and every operational flow is rehearsed. They must own a fallback plan for the corpus going stale, which is a different problem from the corpus being absent.
The good news: if you have done that work for one product, the workflow generalises. The bad news: the workflow is mandatory, even with the best product, and there is no shortcut around it.
Key takeaways
- "Air-gap ready" is a marketing badge; air-gap readiness is an architecture decision made years earlier.
- The four leaks that always show up: telemetry SDKs, licence-server pings, cloud control planes, external threat-intel fetches.
- Real air-gap readiness requires no-outbound-by-default, an internal mirror service, full feature parity offline, models and embeddings shipped with the product, and a co-located control plane.
- Run the five-minute pcap test; extend it to a thirty-day soak. Refuse to evaluate any product the vendor will not let you stand up in your own lab.
- Compliance frameworks rarely mandate air-gap, but several contain clauses that bite hard when products phone home. Map the audit checks before you buy.
- Operating an air-gapped estate is a discipline. Plan the mirror workflow, the WAN-severance drill, and the corpus-staleness fallback as first-class operational artefacts.
For the deeper architecture rationale, see our whitepaper on air-gapped and DPDP-first deployment. For a worked example, see the manufacturing plant case study where the operating team rebuilt their corpus pipeline before swapping the security platform.