An air-gapped deployment is an environment designed to operate without external network connectivity to public cloud services or the internet. In security practice, that means controls, telemetry, and audit evidence must function locally, because any dependency on remote services can undermine isolation requirements.
Expanded Definition
Air-gapped deployment describes a deliberately isolated operating model in which systems are separated from public networks and external services, including cloud control planes, remote update channels, and internet-facing telemetry. In practice, the term is often used more loosely than the control it is meant to describe. NIST’s Cybersecurity Framework 2.0 does not define air-gapping as a single control, but its governance and protection outcomes help explain why isolation is pursued: reduce exposure, constrain pathways for compromise, and preserve local control over critical functions.
What distinguishes an air-gapped deployment from ordinary network segmentation is the assumption that no trusted external dependency exists at runtime. That includes identity services, patch repositories, logging backends, and orchestration tools. Definitions vary across vendors and operators, especially where one-way transfer devices, controlled maintenance windows, or private interconnects are involved. For that reason, the concept should be treated as a strict operational posture, not a marketing label. The most common misapplication is calling a heavily firewalled environment air-gapped when it still depends on remote administration, shared identity infrastructure, or internet-reachable updates.
Examples and Use Cases
Implementing air-gapped deployment rigorously often introduces significant operational friction, requiring organisations to weigh stronger isolation against slower maintenance, manual evidence collection, and more complex recovery planning.
- Industrial control environments may keep supervisory systems isolated from corporate IT so production safety functions are not exposed to internet-borne threats.
- Defence or classified environments may use offline enclaves for workloads, where patching, malware scanning, and configuration changes are transferred through tightly controlled media handling processes.
- Financial or regulatory evidence repositories may be isolated to protect immutable records, while local logging and export procedures preserve chain-of-custody.
- High-assurance identity systems may store keys, certificates, or recovery materials locally, because dependence on remote identity providers can break isolation and create hidden trust paths.
- Agentic AI or model evaluation sandboxes may be deployed offline to prevent prompt leakage, uncontrolled model updates, or remote tool access. Guidance in NIST CSF 2.0 supports the governance mindset needed to keep these environments bounded and auditable.
Why It Matters for Security Teams
Air-gapped deployment matters because isolation changes every assumption about prevention, detection, and recovery. If telemetry depends on a remote SIEM, if identity assurance relies on a cloud directory, or if secrets are fetched from an external vault, the environment is no longer fully isolated in operational terms. Security teams therefore need to design for local authentication, local logging, local backup, and local change control, while also planning how evidence will be exported without collapsing the gap. This becomes especially important in identity-heavy environments, where NHI, service accounts, and certificates still need lifecycle management even when connectivity is unavailable.
Practical governance also requires a realistic view of what is and is not achievable. Air-gapping reduces some attack paths, but it does not eliminate insider risk, removable media risk, or supply-chain contamination. Teams should align the deployment model with recovery and verification procedures that remain usable offline, then validate those procedures through exercises rather than assumptions. Organisations typically encounter the real cost of air-gapped deployment only after a patch, incident, or audit requires evidence from a system that cannot call home, at which point the isolation model becomes operationally unavoidable to manage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC, PR.AC | CSF 2.0 frames governance, access control, and protection outcomes that underpin isolated deployments. |
| NIST AI RMF | AIRMF is relevant when air-gapped systems host AI workloads that must be bounded and monitored locally. | |
| NIST SP 800-63 | AAL2 | Digital identity assurance matters when local authentication must replace cloud identity dependencies. |
| NIST Zero Trust (SP 800-207) | Zero Trust helps distinguish isolation from implied trust, even inside segmented or offline networks. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant where offline deployments still depend on service identities, keys, and certificates. |
Inventory and rotate non-human credentials locally so isolation does not hide stale or overprivileged identities.
