How should security teams implement zero trust in air-gapped environments?

They should treat identity verification and per-request authorization as local controls, not cloud services. That means replacing shared access with unique identities, validating each action against policy, and keeping logs inside the isolated environment. The goal is to preserve zero trust even when internet connectivity is unavailable.

Why This Matters for Security Teams

Air-gapped environments do not eliminate identity risk. They change where trust is enforced. Once a network is isolated, teams often fall back to shared admin accounts, static credentials, and manual approvals because internet-backed identity services are unavailable. That creates the same failure modes zero trust was meant to remove: unclear attribution, excessive privilege, and weak revocation. NIST SP 800-207 Zero Trust Architecture makes the core point plainly: trust decisions must be explicit and continuous, not implied by network location or enclave membership.

For NHI-heavy and operational technology environments, the issue is sharper because service accounts, scripts, agents, and break-glass access can accumulate over time. NHIMG research on The State of Non-Human Identity Security shows how quickly visibility and control gaps appear when identity governance is fragmented. The same logic applies inside isolated networks: if the environment cannot prove who or what is acting, every internal hop becomes a trust assumption.

In practice, many security teams discover the weakest identity controls only after a maintenance window, incident response event, or vendor recovery exercise has already exposed them.

How It Works in Practice

Zero trust in an air-gapped environment means rebuilding the policy stack locally. Identity still needs to be unique, cryptographically verifiable, and mapped to a specific workload or operator. For machine-to-machine access, the preferred pattern is workload identity rather than shared secrets, which is why approaches such as Guide to SPIFFE and SPIRE are relevant even without internet connectivity. They help establish what the entity is, then let local policy decide what it may do.

Practical implementation usually includes three layers:

• Local identity issuance and attestation, so each user, script, service, or agent has a distinct identity.
• Per-request authorization at the point of action, using policy that evaluates device state, time, role, task, and environment.
• Short-lived secrets or certificates, rotated inside the enclave and revoked when the task ends.

This maps cleanly to the principles in NIST SP 800-207 Zero Trust Architecture, but the controls have to be implemented with local trust anchors, local logging, and local enforcement points. Air-gapped teams should also preserve audit trails inside the enclave so forensics and attestation do not depend on external services. NHIMG’s Ultimate Guide to NHIs — Standards is useful here because it frames identity as a control surface, not just a credential store. These controls tend to break down when legacy tools require shared operator accounts and cannot validate per-session identity or policy locally.

Common Variations and Edge Cases

Tighter zero trust controls often increase operational overhead, requiring organisations to balance stronger isolation against maintenance speed, recoverability, and supportability. That tradeoff is especially real in air-gapped plants, labs, and classified networks where patching, certificate renewal, and identity federation may be slower by design.

Best practice is evolving on how much dynamism to introduce inside a sealed environment. Some teams keep a small set of tightly controlled break-glass accounts for emergency recovery, while others prefer just-in-time elevation with offline approval workflows. There is no universal standard for this yet, but the direction is consistent: standing privilege should shrink, and privileged access should become time-bound and task-bound.

Two edge cases matter most. First, when the enclave must interoperate with vendor equipment that was never designed for zero trust, teams often need compensating controls such as jump hosts, session recording, and strict command allowlists. Second, when the environment includes autonomous agents or scheduled jobs, policy must account for non-human behaviour, not just human users. NHIMG’s guidance on DeepSeek breach is a reminder that identity and authorization failures can scale quickly once automation is allowed to move freely. In short, air-gapping removes internet exposure, not the need for rigorous identity proof, local policy enforcement, and continuous review.

Related resources from NHI Mgmt Group

• How should security teams implement PAM as part of zero trust?
• How should security teams implement zero trust IAM in cloud-native environments?
• How should security teams implement continuous authorization in zero trust environments?
• How should security teams implement zero trust for non-human identities in federal environments?