Zero Trust at mission scale changes how NGG access is enforced

At a glance

What this is: This is an analysis of how NGG is using Zero Trust Network Access to deliver identity-centric, least-privilege access across highly distributed and classified defence environments.

Why it matters: It matters because IAM teams must design controls that work across connected, degraded, and partner-access scenarios without expanding trust or introducing mission bottlenecks.

By the numbers:

• NGG is designed to support over one million users across 187 Air Force bases globally.

👉 Read Appgate's analysis of Zero Trust at mission scale with NGG

Context

Zero Trust at defence scale is not a policy statement, it is an access model that has to survive operational reality. In NGG, the challenge is to support more than one million users across 187 Air Force bases while still keeping access narrow, policy-driven, and usable across enterprise, tactical, and classified environments.

That makes this a governance question as much as a network design question. If enforcement moves away from the mission boundary, identity controls become harder to apply consistently, partner access becomes harder to segment, and operational continuity becomes more fragile in degraded conditions.

Key questions

Q: How should defence teams apply Zero Trust without creating mission bottlenecks?

A: Defence teams should keep policy enforcement close to the resource, scope access by identity and mission need, and test the design under degraded conditions. Zero Trust fails when it improves security on paper but introduces routing, latency, or dependency issues that disrupt operations.

Q: Why is identity-centric least privilege hard in distributed military environments?

A: It is hard because access must stay consistent across connected bases, remote locations, tactical settings, and classification boundaries. The challenge is not defining least privilege once, but keeping it valid when mission context, connectivity, and partner access patterns change continuously.

Q: What breaks when partner access is treated like normal internal access?

A: When partner access is treated like normal internal access, the organisation expands trust unnecessarily and loses control over the blast radius of a compromised partner identity. Partner access should be narrowly scoped, separately reviewed, and limited to the systems needed for the mission.

Q: Who should own Zero Trust access decisions in mission environments?

A: Ownership should sit with the team accountable for the mission resource, identity policy, and access lifecycle, not with a generic perimeter control function. That keeps access decisions aligned with operational need, classification, and partner requirements.

Technical breakdown

Identity-centric access control in distributed defence networks

Identity-centric access control means the policy decision is tied to who the user is, what they are allowed to reach, and the context in which access is requested. In NGG-style deployments, that replaces broad network reach with application-specific authorization. The technical value is not just tighter access, but fewer implicit trust paths across sites, missions, and classifications. This matters in defence because access decisions must remain consistent whether a user is on a well-connected base or operating in a low-bandwidth, contested environment.

Practical implication: map every high-value application to explicit identity and policy conditions rather than relying on network presence as a trust signal.

Direct-routed encrypted connections and mission-bound enforcement

Direct-routed, encrypted connections keep traffic from being backhauled through a central choke point, which preserves performance and reduces exposure. The enforcement point stays close to the resource instead of being abstracted into a remote perimeter layer. That architecture is important when security and mission availability must coexist. If the enforcement layer is too far from the mission, latency, dependency fragility, and routing complexity can become part of the security problem rather than the solution.

Practical implication: validate where policy enforcement occurs and test whether access still works when bandwidth, routing, or central dependencies are degraded.

Mission partner access without network-level exposure

Mission partner access is safer when partners are granted scoped access to specific resources instead of broad placement on an internal network. That is the operational difference between controlled resource access and implicit network membership. For joint and coalition operations, the design goal is to support interoperability without widening the blast radius of a compromised partner credential or device. Zero Trust only holds if partner access is continuously bounded to the approved mission need.

Practical implication: treat partner access as a separately governed identity class with narrowly defined application and data entitlements.

NHI Mgmt Group analysis

Mission-scale Zero Trust exposes a governance problem, not just a connectivity problem. When access has to work across enterprise, tactical, disconnected, and classified environments, the programme can no longer depend on a single perimeter or a single trust zone. The operational question becomes whether identity policy can remain consistent when the mission context changes faster than the network does. Practitioners should treat this as an architecture boundary issue, not a deployment detail.

Zero Trust enforcement only works when the control point stays inside the mission boundary. If enforcement is pushed too far away from the resource, security starts competing with availability, and the programme inherits latency, routing, and dependency risk. That is why distributed defence environments need localised policy enforcement with tightly scoped authorisation. The practitioner conclusion is that architecture placement becomes an access-governance decision.

Mission partner interoperability is a trust-scope problem disguised as collaboration. Partners do not need broader network presence to collaborate, they need governed access to defined resources. That distinction matters because joint operations often fail when partner access is treated as a convenience layer instead of a separately bounded identity relationship. The practical takeaway is to govern partner access as a distinct entitlement class with its own lifecycle and review discipline.

Identity-centric least privilege is the correct model for defence, but only if classification and mission need remain explicit. Access decisions based on identity, permissions, and policy reduce unnecessary exposure, yet the model breaks down if those inputs are broad, stale, or poorly segmented across classifications. The implication is not merely to tighten controls, but to preserve clarity about which identities may reach which mission resources under which operational conditions.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• That scale of exposure is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs remains the right next step for teams formalising access review, rotation, and offboarding controls.

What this signals

Mission-scale Zero Trust will increasingly be judged by whether it survives degraded conditions, not by whether it satisfies policy language. Defence and critical-sector teams should expect more scrutiny on where enforcement lives, how partner access is segmented, and whether access remains deterministic when network quality drops. The practical test is continuity under stress, not compliance under ideal conditions.

Identity programmes that still rely on broad network trust will struggle to support classified, tactical, and joint operations at the same time. The access model has to become more explicit about resource-level authorization, partner scoping, and operational context. Teams that want to avoid architectural drift should align their control design to NIST Cybersecurity Framework 2.0 and keep least-privilege enforcement visible at the application boundary.

For practitioners

• Map mission applications to explicit identity policy Document which identities can reach each mission-critical application, then remove broad network assumptions from the access model. The goal is to ensure policy, not presence on a network segment, determines reachability.
• Test access under degraded and disconnected conditions Validate whether direct-routed encrypted connections still support mission continuity when latency increases, routing changes, or central services are unavailable. Include tactical and remote operating scenarios in the test plan.
• Separate partner access from internal user access Create distinct entitlement and review paths for mission partners, with access limited to approved systems and data sets. Do not let collaboration requirements expand default network trust.
• Place enforcement close to the resource Review where policy decisions are made and where traffic is terminated, then reduce dependencies that force access checks through distant choke points. That helps limit bottlenecks and preserves segmentation in defence environments.

Key takeaways

• NGG illustrates that Zero Trust at defence scale is an access-governance problem as much as a network architecture problem.
• Identity-centric least privilege only works when enforcement stays close to the mission and survives degraded operating conditions.
• Mission partner access must be separately scoped and reviewed, or collaboration will quietly widen the trust boundary.

Key terms

• Zero Trust Network Access: Zero Trust Network Access is an access model that grants users or devices only the specific application or resource access they are authorised to receive. It replaces broad network reach with policy-based, identity-driven decisions that can be enforced consistently across distributed environments.
• Mission boundary: The mission boundary is the operational point where security enforcement stays close to the system, application, or resource being protected. In defence environments, keeping the control point near the mission reduces latency, avoids unnecessary backhauling, and preserves continuity when conditions are degraded.
• Identity-centric access control: Identity-centric access control makes the user or device identity the primary input to authorisation, rather than network location alone. It is especially useful in environments with multiple classifications, partner users, and changing connectivity because access can stay narrow without depending on perimeter trust.
• Partner entitlement: A partner entitlement is a scoped permission granted to an external mission partner for a defined resource, system, or data set. It should be separated from internal access paths so that collaboration does not expand default trust or create broad lateral movement opportunities.

What's in the full article

Appgate's full article covers the operational detail this post intentionally leaves for the source:

• How NGG is positioned to support enterprise, tactical, and classified users across a global defence footprint
• The certification and assurance context behind Appgate's NIAP validation for government use
• The mission-partner access model and how it is intended to support interoperability without extending network exposure
• The DoD Zero Trust mandate context and the role NGG is claimed to play in that path

👉 Appgate's full post covers the mission boundary, partner access model, and certified defence context in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.