The perimeter problem: why network security fails under zero trust

At a glance

What this is: This is an analysis of why perimeter-based network security breaks down and why zero trust access control is the practical replacement.

Why it matters: It matters because IAM teams now have to govern access by identity, context, and resource rather than by network location alone across human users, service accounts, and AI-driven systems.

By the numbers:

• The Identity Theft Resource Center tracked a record amount of data breaches in 2021 and 2022 was only 60 events short of that record.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Pomerium's analysis of the perimeter problem and zero trust access

Context

The perimeter problem is the failure of a security model that assumes the network edge can define trust. In practice, cloud services, mobile devices, remote work, and delegated access have made the perimeter too porous and too dynamic to serve as a reliable control boundary for IAM.

For identity teams, the core issue is not just network design. Perimeter security concentrates trust at entry points such as VPNs and firewalls, while zero trust pushes authorisation to the resource level and evaluates each request in context. That shift changes how organisations govern human access, non-human identities, and any system that behaves like a subject at runtime.

Key questions

Q: How should security teams replace perimeter-based access with zero trust controls?

A: Start by moving authorisation from the network edge to the application or resource layer. Require identity, device, and request context on each access decision, and remove reliance on “inside the network” as a trust signal. The goal is not to block connectivity, but to stop broad internal trust from following every successful login or tunnel.

Q: Why do VPNs create risk even when they use strong encryption?

A: VPN encryption protects the transport path, but it does not prove that the connected subject should be trusted broadly inside the environment. Once connected, the tunnel can become a conduit for lateral movement if the account, device, or workload is compromised. Strong transport security is useful, but it is not the same as least-privilege authorisation.

Q: What breaks when organisations keep treating the internal network as trusted?

A: Perimeter logic fails when compromise is already inside the boundary, because it cannot distinguish legitimate internal traffic from malicious internal movement. That creates a blind spot for insiders, stolen credentials, and compromised devices. The failure is structural: the model assumes trust can be inferred from location, and that assumption no longer holds.

Q: What is the difference between zero trust and perimeter security for access control?

A: Perimeter security authorises by boundary, while zero trust authorises by identity and context at the resource itself. In a perimeter model, the network gate is the main decision point. In a zero trust model, each application or service makes the decision, which sharply reduces the value of being “inside” the network.

Technical breakdown

Why perimeter boundaries fail in cloud and remote access models

A perimeter model depends on a stable boundary between internal and external traffic. Cloud-hosted services, remote work, and hybrid infrastructure erase that stability, so the “inside” becomes a moving target. Once the boundary shifts, static firewall logic and network-location trust stop describing actual risk. The result is not just weaker defence, but misplaced defence, because policy is enforced at the edge while the real decision should happen at the resource. NIST SP 800-207 frames this directly: access should be evaluated where the resource lives, not where the request originated.

Practical implication: treat network location as a signal, not an authorisation decision.

How VPN tunnels preserve the perimeter assumption

VPNs solve connectivity, not trust. They create an encrypted path into the environment, but they still inherit the old assumption that once a subject is inside, it can be treated as broadly trusted. That assumption is dangerous because the tunnel becomes a privileged conduit for lateral movement if the user, device, or workload is compromised. Layer 4 connectivity also leaves limited visibility into Layer 7 behaviour, which makes inspection and response harder. The security model still revolves around a gate, even if that gate is now harder to see.

Practical implication: do not confuse secure transport with verified access.

Resource-level authorisation as the zero trust control plane

Zero trust replaces perimeter trust with per-resource policy. Each application or service becomes its own enforcement point, usually through a reverse proxy or similar access gateway that checks identity, device, and request context before granting access. This model is especially relevant when legacy applications cannot enforce modern controls themselves. The architectural point is simple: if one resource is compromised, it should not become a springboard to the rest of the environment. That is the control logic NIST recommends, and it is the opposite of perimeter-based broad trust.

Practical implication: move enforcement closer to the application and away from the network edge.

Threat narrative

Attacker objective: The objective is to convert one trusted entry point into broader internal access that enables lateral movement and deeper compromise.

1. Entry occurs through a trusted remote access path such as a VPN, which gives the attacker or insider a foothold inside the assumed boundary.
2. Escalation happens when that foothold is treated as trusted internal presence, allowing lateral movement across systems that were protected only by perimeter controls.
3. Impact appears as broader internal compromise because the original network boundary no longer limits what the actor can reach or reuse.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The perimeter model fails because it was designed for a world in which trust could be inferred from location. That premise breaks once users, workloads, and services are distributed across cloud, remote, and third-party environments. The control failure is not just technical, it is conceptual: security teams are still making decisions as if network proximity implied legitimacy. Practitioners need to treat the perimeter as an access path, not a trust boundary.

Zero trust is not a product category, it is an identity decision model. The real shift is from “who is inside the network” to “what is requesting this resource, under what context, and with what current permissions.” That is why zero trust aligns so closely with IAM, NHI governance, and policy enforcement at the application layer. The discipline changes from defending a border to governing each subject’s entitlement at the point of use.

Standing trust inside VPN-connected environments is a hidden privilege problem. Once a tunnel exists, organisations often over-extend internal trust because the network path feels authenticated even when the subject’s actual intent and posture are not. This is why access granted at the transport layer can outlive the security assumptions that justified it. The practical conclusion is that access architecture must stop assuming transport security equals authorisation control.

Network perimeter logic does not scale cleanly across human and non-human identities. Humans may authenticate into sessions, but service accounts, APIs, and autonomous systems do not behave like stable users at the edge. They access resources programmatically and often continuously, which makes broad network trust especially hazardous. A modern programme has to distinguish transport connectivity from identity governance, or it will keep granting ambient access where it should be enforcing precise resource-level policy.

Perimeter collapse is also a governance signal, not just an architecture issue. When organisations cannot define where trust begins and ends, they are usually compensating with exceptions, tunnels, and loosely managed privileged paths. That is a sign that access governance has drifted from policy to infrastructure convenience. Practitioners should read this as a mandate to re-centre identity, context, and resource policy in the access model.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• To see how this visibility gap shows up operationally, review JetBrains GitHub plugin token exposure for a concrete credential exposure pattern.

What this signals

Perimeter collapse becomes visible first in access governance, not just network design. When teams cannot distinguish connectivity from authorisation, they start compensating with exceptions that are hard to audit and even harder to retire. The governance task now is to normalise resource-level policy across both human and non-human access paths before tunnel-based trust becomes the default.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That visibility gap matters because perimeter-style thinking often hides machine access inside the same trusted zone as user access. As workloads, APIs, and automation keep expanding, the safer model is to govern every subject by context and entitlement rather than by network location.

If your programme still uses VPNs as an implicit trust filter, the next step is to separate transport from authorisation in policy, architecture, and reporting. That will also make it easier to align access decisions with NIST SP 800-207 Zero Trust Architecture, where resource-centric enforcement is the core design principle.

For practitioners

• Map all perimeter-dependent access paths Inventory VPNs, firewall exceptions, and other entry points that still assume trust after connection. Classify which applications depend on network location instead of resource-level policy.
• Move enforcement to the resource layer Place an access gateway or reverse proxy in front of applications that cannot enforce modern controls themselves, and require identity and context checks on every request.
• Separate transport security from authorisation Treat encrypted tunnels as connectivity controls only. Require distinct policy for application access, privileged access, and internal lateral movement paths.
• Re-evaluate service account exposure inside trusted networks Review machine-to-machine access that currently inherits broad internal trust from the network. Apply the same scrutiny you would use for high-risk human access.

Key takeaways

• The perimeter model fails because cloud and remote access make network location an unreliable basis for trust.
• VPNs improve connectivity but still preserve the old assumption that an internal connection implies broad trust.
• Zero trust shifts control to the resource level, which is the right model for both human and non-human access governance.

Key terms

• Perimeter Security: A security model that assumes the network edge is the main place to decide who can be trusted. It works by allowing or blocking traffic based on location and entry controls. In modern environments, that assumption weakens quickly because cloud, mobile, and remote access make the boundary unstable.
• Zero Trust Architecture: An access model that does not trust a request just because it comes from inside the network. Every request is evaluated using identity, context, and policy at the point of access. For modern IAM programmes, that means resource-level enforcement replaces broad internal trust.
• 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.
• Resource-Level Authorisation: A control pattern where each application or service decides whether a subject should be allowed to act. The decision is based on identity, context, and policy rather than on network location. This is the practical mechanism that makes zero trust enforceable in real environments.

Deepen your knowledge

Perimeter security, zero trust access control, and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your access model still depends on tunnels or trusted internal zones, the course is a practical place to reset the architecture.

This post draws on content published by Pomerium: The perimeter problem: why traditional network security fails. Read the original.