What Zero Trust Actually Means *Inside an Air-Gapped Network*

A common question from customer security teams: "Aren't Zero Trust and air-gapped networks contradictory?"

On the surface, yes. Zero Trust's slogan — "never trust, always verify" — i.e., don't trust the network perimeter. Air-gapped networks are perimeters. Looks like a conflict.

This post unpacks the misunderstanding. The two are complementary, and applying zero trust inside the perimeter matters more, not less.

The misunderstanding — Zero Trust = no perimeter

Zero Trust doesn't say there should be no perimeter. It says don't treat the perimeter as the sole basis for trust.

What Zero Trust *rejects*:
  "They're inside the network, so we trust them"

What Zero Trust *recommends*:
  "Verify user, device, and context for every request"

Air-gapped = don't trust outside. Zero-trust-air-gapped = don't trust inside either.

Why zero trust matters more inside an air-gapped network

Counter-intuitively, the more isolated the network, the more zero trust matters.

Reasons:

• The assumption that external attackers are blocked at the perimeter is fine. But insider threat / supply-chain compromise / stolen credentials don't care about the perimeter
• The stronger your external barrier, the more lateral movement inside puts the entire network at risk
• Internal user populations are small, so anonymity is high — incident attribution is harder

The stronger the perimeter, the more important internal verification. Zero trust's real use case is inside an air-gapped network.

Four areas of air-gapped zero trust

Area 1 — Identity-first (not IP-based)

Drop the pattern of granting permissions by internal IP. Explicit user / service-account authentication.

Air-gapped specifics — no external IdP (Auth0, Okta). The internal IdP is load-bearing. Keycloak / FreeIPA / homegrown.

Area 2 — Workload identity (service-to-service)

Service calls authenticated by service identity. mTLS or SPIFFE/SPIRE.

Air-gapped specifics — cert issuance / rotation / revocation is an offline procedure. Self-run PKI plus automated rotation.

Area 3 — Per-request authorization

Authorization on every request. Not just RBAC — context (time, location, device posture) too.

→ Permission model on a graph

Area 4 — Audit every action

Zero trust assumes users behave as if everything is logged. Audit trails must be complete.

Air-gapped specifics — no external SIEM. Run an internal SIEM (ELK / Splunk on-prem / homegrown).

What you get with air-gapped + zero trust

With all four:

• External — blocked by air gap itself
• Internal anonymity — broken by identity-first
• Service-to-service trust — broken by workload identity
• Excessive permissions — broken by per-request auth
• Causality after incidents — answerable via complete audit

That's zero-trust air-gapped. External protection plus internal zero trust = layered protection.

How this differs from generic zero-trust guides

Generic guide (cloud-default)    | Air-gapped variant
─────────────────────────────────┼─────────────────────────────────
BeyondCorp (Google) examples     | Self-run internal IdP
SaaS IdP (Auth0, Okta)           | Self-run IdP (Keycloak / FreeIPA)
SPIFFE/SPIRE w/ SaaS control plane | Self-run SPIRE control plane
SaaS SIEM                        | Internal SIEM

Same principles; every component self-hosted. Operational cost runs 1.5–2× a cloud zero trust setup. And by definition of an air-gapped environment, there's no other choice.

Does an air-gapped network still need zero trust?

An air-gapped network needs zero trust more, not less. The first assumption a security leader running one should re-examine is "we're air-gapped, so zero trust is irrelevant". An air-gapped network applying none of the four areas above (identity-first / workload identity / per-request authorization / complete audit) is a perimeter-only defense — one internal incident puts the whole network at risk.