Zero Trust and air gapping are sometimes presented as opposite philosophies: one assumes modern connected environments, while the other removes connectivity. That framing is misleading. Zero Trust governs access to resources without granting implicit trust based on network location. An air gap changes whether a network path to a resource exists at all.
A high-value system can benefit from both. Physical isolation can make the resource unreachable outside approved periods. When a connection is created, Zero Trust principles can determine which user and device may access which resource, for what purpose and under what conditions.
Key takeaways
The short version
- Zero Trust removes implicit trust; it does not require every resource to remain continuously connected.
- An air gap controls reachability but does not authenticate a person or validate a device.
- During authorised connectivity, resource-level access policy remains necessary.
- The models combine well when a high-value asset has infrequent, tightly governed access needs.
What Zero Trust asks
NIST SP 800-207 states that no implicit trust should be granted solely because of physical or network location or asset ownership. Authentication and authorisation occur before access to an enterprise resource is established, and policy can consider user, device and contextual information.
The protected object is the resource, not the perimeter. This is valuable in hybrid environments where users and services move across traditional boundaries. Zero Trust also assumes continuous evaluation, visibility and least-privilege decisions rather than one broad network admission.
What physical isolation asks
Physical isolation asks a more basic question: should a communication path be present at this time? When the answer is no, a physical break can make the resource unreachable through that path regardless of software identity or routing state.
This property does not identify the requester, assess endpoint health or restrict activity after connection. A person with physical access or malicious removable media can still create risk. The isolation boundary therefore cannot substitute for Zero Trust controls.
A combined policy decision
Consider a maintenance workstation for a critical system. Physical policy can state that its Ethernet path is open unless an approved task exists. Identity policy can require a named engineer with multifactor authentication. Device policy can require a managed, healthy endpoint. Resource policy can permit only the maintenance application and target asset.
The connection window becomes one condition in a larger access decision. AIRGAPNET can enforce the physical state while identity, endpoint and application controls enforce who may do what after the path exists.
Protect the control plane
A request to connect a protected resource is itself a privileged action. Authenticate it strongly, restrict it to authorised roles and log both request and outcome. Consider whether the authorisation service can be influenced from the network it controls.
Separating the control channel from the protected Ethernet path can reduce circular trust. AIRGAPNET uses an independent cellular control channel for this purpose. Account lifecycle, device ownership and incident revocation still need governance like any other privileged service.
Place isolation in a Zero Trust roadmap
Begin with critical resources and their required flows. Improve identity, device inventory, segmentation, logging and policy enforcement across the environment. Then identify resources whose continuous reachability is unnecessary and where a physical state would add meaningful risk reduction.
Do not use an air gap to avoid understanding the resource. The same inventory and policy work needed for Zero Trust helps determine what should happen during a connection window and whether physical isolation is operationally viable.
Translate the combination into policy
A policy can state that a protected engineering service is physically unreachable in its normal state. A named engineer may request a connection for an approved change ticket. The access system verifies multifactor authentication, managed-device posture, permitted location and target resource before the window begins.
During the session, segmentation limits protocols and monitoring records activity. The path closes when the ticketed task ends or the maximum duration is reached. A separate administrator reviews exceptions. This example shows the division of responsibility: physical isolation governs when reachability exists, while Zero Trust governs the subject, device, resource and session.
The exact signals and enforcement points will differ by organisation. The important outcome is one coherent decision chain rather than two independent controls with conflicting ownership.
Test negative cases as carefully as successful access: an unmanaged device, an expired approval, a request for the wrong resource and a disconnected control service should all produce a known, reviewable result.
Decision checklist
Questions to resolve before implementation
- Identify the protected resource and every path that can reach it.
- Require explicit user and device authorisation before connection.
- Treat physical connection as a privileged policy decision.
- Apply least privilege to services available during the window.
- Log requested state, verified physical state and resource activity.
- Review emergency access and revocation across both control layers.
Common questions
Questions teams ask first
Does Zero Trust make air gaps obsolete?
No. Zero Trust governs access to resources in connected environments, while physical isolation can remove a path when access is not needed. Their value depends on the resource and operating model.
Is an air-gapped network automatically trusted?
It should not be. Systems, users, media and software inside an isolated environment can still be compromised. Apply strong identity, hardening, monitoring and data-handling controls within the zone.
Can the physical state be part of access policy?
Yes. An organisation can require an approved physical connection window in addition to user, device and resource authorisation. Evidence should show the actual state, not only that a connection was requested.
Official references