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 else belongs in the requirements

The live demo proves the architecture. A few further requirements belong in the procurement language itself, because they are where otherwise capable products get disqualified late:

FedRAMP scope. For federal civilian agencies, FedRAMP authorisation is often a procurement requirement. Check which deployment model the authorisation actually covers. Some vendors hold it only for their SaaS offering, which says nothing about an on-premises deployment.
FIPS 140-2 cryptography. Systems handling sensitive data often require FIPS 140-2 validated modules. Ask the vendor to confirm that the gateway's TLS stack and key management use FIPS-validated implementations.
DISA STIG hardening. Defence and intelligence environments often require deployed software to comply with DISA Security Technical Implementation Guides. That affects the gateway's default configuration, the operating system it runs on, and the hardening steps required at deployment.
Offline delivery and update. Ask explicitly: can you deploy and update this software in a network with zero outbound internet connectivity?

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 — Active Directory, LDAP, PIV/CAC systems, or agency OIDC infrastructure — deployed inside the boundary. External consumers such as partners, contractors, and other agencies authenticate with mutual TLS using government-issued PKI. The gateway does not call a vendor-hosted identity service to validate credentials.

Telemetry and audit go to your SIEM. Operational metrics and structured logs are pushed to customer-controlled infrastructure — Prometheus, Splunk, Elastic. Audit requirements under FedRAMP, FISMA, and DISA STIGs typically call for structured, tamper-evident access logs retained for a defined period, so audit output needs to be in a format your SIEM consumes (structured JSON, CEF, or configurable) and must not depend on a vendor cloud for storage or retrieval. No telemetry leaves the boundary.

The developer portal works inside the boundary too. Partners, contractors, and internal consumers still need to discover APIs, obtain credentials, and test endpoints. That means no external CDN for portal assets, consumer sign-in against your internal IdP or the gateway's own credential system, notification email routed through your internal SMTP relay, and try-it calls routed through the gateway rather than an external test backend.

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 holds whether the gateway runs as Docker Compose (often the better fit for smaller deployments and minimal-footprint classified enclaves) or on Kubernetes (for horizontal scaling, high availability, and rolling updates), provided images are loaded from the internal registry rather than pulled from a public one at deploy time.

This is not a degraded mode. It is the full product, running entirely within the customer's security boundary. It also simplifies the sovereignty conversation: when nothing leaves the boundary, the answer to "where does your data go?" is "nowhere," which removes a large category of compliance questions before they are asked.

Multi-agency API sharing inside the boundary

A growing government pattern is one agency exposing a service that others consume through a defined API contract: national identity verification, benefits eligibility, shared infrastructure registries. Air-gapped or not, that pattern adds governance requirements the gateway has to meet:

Agency-level consumer identity. When Agency B calls Agency A's API, the audit record should capture the organisation, programme, and authorised system, not just a technical client ID. That identity is typically established through certificates from a government PKI (in the US, Federal PKI or DoD PKI).
Per-agency rate limits and access tiers. A registry consumed by 50 state agencies needs per-consumer limits, so one state's bulk batch job cannot crowd out real-time queries from the rest.
Versioned APIs with managed deprecation. Consuming systems often have long upgrade cycles, so the gateway must run multiple versions side by side and communicate deprecation timelines through the developer portal.
Cross-domain topologies. Where APIs span classification levels, data diodes and cross-domain solutions control the path between domains. The gateway sits on one side of that boundary; it does not replace the CDS, but it must be deployable alongside one.

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.