The Case for Air-Gapped API Gateways in Defence and Government

For years, air-gapped deployment was a requirement that defence and government technology teams knew they needed but struggled to procure. Most enterprise API gateway vendors were built cloud-first. Their self-hosted options were real, but they were second-tier products — fewer features, less support, and a management plane that called home to the vendor's cloud for licence validation, telemetry, or configuration updates.

That is changing. Classified networks are becoming larger consumers of modern API management tooling. DoD, defence ministries, and national intelligence agencies are writing explicit air-gap requirements into procurement language. And vendors that cannot meet those requirements are losing contracts.

This post is the strategic brief for decision-makers: the threat model that justifies air-gapped API gateways, the policy environment that is driving mandates, and the procurement test that separates genuine air-gap capability from cloud-first products with a self-hosted brochure.

The threat model

Air-gapped deployment is a response to specific threats, not a general preference for on-premises software. Understanding the threats makes the procurement requirement defensible — and helps identify which "self-hosted" gateway products actually address them.

Supply chain compromise via vendor infrastructure. A gateway that calls home to a vendor's cloud for any function — licence validation, policy updates, telemetry, certificate revocation checks — creates a dependency on vendor infrastructure that is outside the customer's security boundary. A compromised vendor cloud, a coerced vendor, or a nation-state attack on vendor infrastructure can affect the gateway's operation.

This is not a theoretical threat. Software supply chain attacks have targeted network security products, authentication infrastructure, and update mechanisms. A gateway with a vendor cloud dependency is a potential supply chain attack surface inside your classified network.

Vendor callback exploitation. A gateway that makes outbound connections for any purpose creates an outbound channel that can be exploited. Even a narrow outbound connection — a licence check, a telemetry ping — is a potential exfiltration vector if an adversary can manipulate the connection destination or the content being sent.

In a properly air-gapped environment, the policy is simple: no outbound connections from the gateway at runtime, for any reason. This policy cannot be satisfied by a gateway that requires any form of vendor callback.

Telemetry as intelligence. Operational telemetry from a classified network — API call volumes, endpoint patterns, error rates, client identity distributions — can itself be sensitive. A gateway that sends telemetry to a vendor cloud, even if that data is encrypted in transit, sends observable patterns about classified network operations to infrastructure outside the security boundary.

Insider threat to vendor systems. A vendor whose cloud infrastructure has access to your network — even indirectly, through a gateway that polls vendor systems — represents an insider threat vector. Malicious or compromised vendor employees with access to the cloud infrastructure that your gateway depends on have a potential path into your network operations.

The policy environment

The policy pressure for air-gapped API gateways is accelerating. Several concurrent developments are driving this:

DoD and defence contractor requirements. US DoD guidance on classified AI deployment now explicitly requires that AI vendors be capable of deploying within classified environments within 30 days of a model release. While this guidance targets AI systems specifically, the pattern is clear: the US national security community is moving to require that all critical technology be deployable within classified boundaries, not just certifiable for use outside them.

NCSC and allied intelligence guidance. The UK NCSC and equivalent bodies in the Five Eyes alliance have published guidance on supply chain risk management that explicitly covers cloud service dependencies in security-critical systems. API gateways that manage access to classified systems are security-critical infrastructure. Cloud dependencies in those gateways are supply chain risks that the guidance is designed to address.

FedRAMP and sovereign cloud mandates. FedRAMP's authorisation requirements for federal cloud services, combined with emerging data sovereignty requirements across NATO members, are creating a policy environment where "we have a cloud product with a self-hosted data plane" is no longer sufficient for the most sensitive use cases.

Procurement policy updates. Several defence procurement frameworks are now including explicit requirements for full offline operation — zero outbound connectivity during normal operation — as a condition of contract for systems that process or route classified information.

Why most "self-hosted" gateways fail the test

The market uses "self-hosted" to mean many things. For air-gapped deployment, the only definition that matters is: the product operates fully — including management, policy enforcement, credential validation, audit logging, and software updates — without any outbound network connections.

Most enterprise API gateways fail this test for at least one of the following reasons:

The management plane is cloud-hosted. The data plane (which routes API traffic) runs on your infrastructure. The control plane (where you configure policies, manage credentials, and view analytics) is hosted by the vendor. Any management operation requires an outbound connection to the vendor cloud. This is the most common "self-hosted" failure mode.

Licence validation requires connectivity. The gateway checks its licence against a vendor-hosted endpoint at startup, on a schedule, or on certain operations. In an air-gapped environment, this check fails. The gateway either refuses to start or enters a degraded mode.

Telemetry is not suppressible. The gateway sends operational metrics, error reports, or usage data to a vendor-hosted analytics service. In some products, this cannot be disabled without losing core functionality.

Certificate validation requires external OCSP. TLS certificate validation includes OCSP requests to certificate authority servers. In an air-gapped environment, these requests fail, causing TLS validation failures unless OCSP stapling is correctly configured and supported.

Software updates require internet access. Container images are pulled from vendor-hosted registries at update time. In an air-gapped environment, images must be delivered through an internal registry, which requires the vendor to support signed offline delivery.

The procurement test

When evaluating an API gateway for air-gapped deployment, run this test: ask the vendor to demonstrate the full product — including the management plane, developer portal, policy configuration, credential management, and observability — running on isolated infrastructure with zero outbound internet connectivity.

Not a demo on their hosted platform. Not a walkthrough of the architecture. A live demonstration of the product operating with outbound network access blocked.

Vendors that can pass this test have built for air-gapped deployment. Vendors that cannot will offer alternatives: a VPN back to their cloud, a "limited connectivity" mode that still requires some outbound access, or a promise that air-gap support is on the roadmap.

For classified and defence environments, the roadmap is not a solution. The requirement is today.

What full air-gap capability requires

A gateway that genuinely operates in an air-gapped environment has these properties:

All components run inside the boundary. Gateway runtime, management plane, developer portal, configuration store, credential store, and audit log storage are all deployed on infrastructure the customer controls. No component makes outbound connections to vendor infrastructure at any point.

Policy is fully local. Access control policies, rate limit definitions, routing configuration, and workflow definitions are stored in a local database. The gateway does not poll a vendor cloud for policy updates.

Authentication is from your identity provider. Token validation for API consumers uses the customer's own identity provider — deployed inside the boundary. The gateway does not call a vendor-hosted identity service to validate credentials.

Telemetry goes to your SIEM. Operational metrics and structured logs are pushed to customer-controlled infrastructure — Prometheus, Splunk, Elastic. No telemetry leaves the boundary.

Software updates are offline-deliverable. Container images and configuration updates are delivered as signed artifacts to the customer's internal registry. The update process does not require outbound internet access.

This is not a degraded mode. It is the full product, running entirely within the customer's security boundary.

Zerq is built for full air-gapped deployment — every component, zero outbound runtime dependencies, offline-deliverable updates, and no vendor callbacks under any operating condition. See the government and defence use case or request a demo to run the air-gap test against your specific classified environment requirements.