By NHI Mgmt Group Editorial TeamBased on Pomerium: “The Perimeter Problem: Why Traditional Network Security Fails” (May 6, 2026)

TL;DR: Traditional perimeter security fails because cloud, mobile, remote work, and VPN tunnels dissolve the inside-outside boundary, leaving attackers and insiders able to move laterally once inside, according to Pomerium and NIST SP 800-207. Zero trust shifts control to the resource and the requesting identity, which changes how IAM, NHI, and access governance must be designed.


At a glance

What this is: This is an argument that traditional perimeter security fails because modern access patterns erase the trusted-inside model and make lateral movement easier once an attacker is inside.

Why it matters: It matters because IAM, NHI, and access governance teams have to move control decisions from the network edge to the resource, the identity, and the request context.


Context

Traditional network security assumes there is a clear boundary between trusted internal systems and untrusted external traffic. Pomerium argues that this assumption no longer matches how cloud services, mobile users, remote work, and VPN access actually operate, which makes the perimeter a weak control point for identity governance.

The identity security issue is not just network design. Once access is granted through a perimeter gateway, the remaining trust model often assumes anything inside is safe, which creates a lateral-movement problem for human users, service accounts, and other non-human entities that authenticate from outside the original boundary.


Key questions

Q: What breaks when cloud security is still built around a fixed network perimeter?

A: A fixed perimeter breaks down when workloads, data, and applications move across hybrid and multi-cloud environments. Security teams lose coverage during transit, temporary storage, and rapid scaling events, which creates blind spots for attacks and policy drift. The result is inconsistent protection, weaker visibility into communication paths, and a higher chance that cloud activity escapes traditional controls.

Q: Why do VPNs often increase internal risk instead of removing it?

A: VPNs create a secure tunnel into the enterprise, but the tunnel itself becomes a trusted entry point. Once a user or device is treated as internal, the network may expose more systems than the original request needed, which widens the potential blast radius if the session is misused.

Q: How do organisations know whether perimeter controls are actually working?

A: Look for three signals: timely patching on exposed appliances, consistent log forwarding into a central monitoring stack, and evidence that unsupported devices are isolated or retired. If those signals are missing, the environment may still be relying on boundary trust rather than continuous verification. A healthy programme can show which edge systems are visible, owned, and routinely checked.

Q: What is the difference between perimeter security and zero trust in open banking environments?

A: Perimeter security assumes trust inside a defended boundary and focuses on blocking or inspecting traffic at the edge. Zero trust assumes no implicit trust anywhere, so each request must be authenticated, authorised, and evaluated in context. In open banking, that distinction matters because access extends beyond the corporate network to external parties and shared data flows.


Technical breakdown

Why perimeter-based access control fails in cloud and remote environments

Perimeter security concentrates trust at a boundary, usually a firewall, VPN, or gateway. That works only when assets, users, and access paths remain stable and physically contained. In cloud and remote-work environments, the boundary moves constantly, so the control point becomes an approximation rather than a reliable security model. For IAM and NHI governance, this matters because the resource is no longer protected by location alone. Access decisions must follow identity, device context, and request context rather than a presumed safe zone around the network.

Practical implication: Treat the perimeter as a routing layer, not as the place where trust is established.

Why VPN tunnels preserve the wrong trust assumptions

A VPN does not remove the perimeter problem. It creates a secure tunnel back into the environment, then treats the remote user or device as if it has crossed into a trusted internal space. That model still depends on the idea that access at the entry point is enough to justify broader network confidence. The article’s core point is that this is exactly where lateral movement risk grows, because a granted tunnel can expose more internal surface than the original request justified. For access governance, the issue is scope, not just connectivity.

Practical implication: Limit what a tunnel can reach and verify access at the resource instead of inheriting trust from the tunnel.

How zero trust changes authorization from network-centric to resource-centric

Zero trust rejects the idea of a trusted inside and an untrusted outside. Instead, each resource enforces its own authorization decisions based on identity and context. NIST SP 800-207 is cited in the article for this reason: the model prevents one accessed resource from becoming a springboard to others. For practitioners, this is a governance shift as much as an architecture shift. It changes how you think about session scope, segmentation, and who or what is allowed to reach each application or service.

Practical implication: Design authorization around each resource’s actual access policy, not around network membership.


Threat narrative

Attacker objective: The objective is to turn a single approved access path into broader internal reach and then use that reach to compromise additional resources.

  1. Entry occurs through perimeter mechanisms such as VPNs or other network tunnels that grant a remote subject a place inside the trusted zone.
  2. Privilege then expands because the internal network assumes the authenticated subject is trustworthy once it passes the boundary.
  3. Lateral movement follows when that internal trust model exposes additional systems to compromise or misuse.
  4. Impact is reached when an attacker or insider uses inherited trust to breach internal resources beyond the original access request.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

The perimeter problem is really a trust-placement problem: network boundary controls assume that trust can be assigned once, at entry, and then reused inside the environment. That assumption breaks when cloud services, remote work, and mobile access make the boundary fluid. The practical conclusion is that access governance must stop treating network location as a proxy for trust.

VPNs do not solve zero trust gaps, they preserve them: a tunnel into the enterprise is still a mechanism for importing trust into the internal zone. Once a subject is inside, the security model often has no clean way to prevent lateral reach from expanding beyond the original need. Practitioners should read this as a governance warning about inherited trust, not as a tooling limitation.

Zero trust shifts the control plane from perimeter defense to resource authorization: the resource, not the network edge, becomes the unit of policy enforcement. That is the right model for human access, NHI access, and any delegated access path that should not automatically inherit broad internal confidence. Identity teams should design around request context and scoped authorization, not around who can cross the gate.

Resource-centric access is now the baseline control assumption for identity security: if a subject is authenticated, that still does not justify broad internal access. The article reinforces a model in which each request must be evaluated in context, because internal placement no longer proves legitimacy. Practitioners should align IAM, NHI, and remote-access governance to that assumption.

Perimeter security is becoming a legacy control pattern, not a governance strategy: as environments distribute across cloud and remote endpoints, the old inside-outside distinction loses explanatory power. That creates a naming opportunity for the field: identity-bound perimeter collapse, where the boundary stops being a defensible trust anchor. Security leaders should treat that collapse as a programme-design issue, not a network-only issue.

What this signals

Identity-bound perimeter collapse: the useful way to read this article is as a control-design warning. Once cloud access, remote work, and VPNs dissolve a fixed boundary, IAM teams have to stop treating network placement as a proxy for trust and move policy enforcement to the resource.

The programme implication is practical: access review, remote access, and non-human access governance all need to assume that internal location no longer proves legitimacy. That is the operational shift zero trust forces across both human and machine access paths.


For practitioners

  • Shift authorization to the resource Require applications and services to enforce their own access decisions using identity and request context, rather than inheriting trust from network location.
  • Reduce tunnel-wide trust Constrain VPN and remote-access paths so a connected subject cannot automatically reach broader internal systems than the session actually requires.
  • Map internal trust assumptions Inventory where your programme still assumes that anything inside the network is safe, then identify the applications, service accounts, and workflows that depend on that assumption.
  • Apply zero trust to non-human access Treat service accounts, applications, and other non-human entities as subjects whose access must be evaluated by resource and context, not by network origin.

Key takeaways

  • Traditional perimeter security fails when the network boundary no longer matches how users and services actually connect.
  • The article’s main risk is lateral movement after entry, because internal trust assumptions expand access beyond the original request.
  • Zero trust changes the operating model by enforcing authorization at the resource, which is the right control posture for modern IAM and NHI governance.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST Zero Trust (SP 800-207)Zero Trust ArchitectureThe article directly argues for resource-centric zero trust over perimeter trust.
Recommendation — Apply zero trust principles so each resource authorizes access independently of network location.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe piece is about where authorization should occur and how trust is assigned.
Recommendation — Review entitlements so access depends on identity and context, not perimeter membership.
MITRE ATT&CKTA0008 — Lateral MovementThe article explicitly warns that internal trust enables lateral movement after entry.
Recommendation — Map perimeter failures to lateral movement and reduce internal reach after initial access.

Key terms

  • Network Perimeter: The presumed boundary between an organisation’s internal network and the outside world. In legacy environments it was relatively clear, but in cloud and hybrid estates it becomes blurred by tunnels, remote endpoints, and distributed services. Once that boundary is unclear, it stops being a reliable trust control.
  • Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
  • Lateral Movement: A post-compromise technique where an attacker uses a compromised NHI to move through a network, accessing additional systems and escalating impact without triggering detection.
  • Remote Access Gateway: A remote access gateway is an externally reachable control point that brokers user or system access into internal resources. In IAM terms, it becomes a critical identity surface because it mediates authentication, policy enforcement, and the visibility of protected applications.

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 programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org