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.
NHIMG editorial — based on content published by Pomerium: The perimeter problem: why traditional network security fails
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map all perimeter-dependent access paths Inventory VPNs, firewall exceptions, and other entry points that still assume trust after connection.
- 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.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- NIST-aligned reasoning for why resource-level access control replaces perimeter trust in modern environments
- The role of reverse proxies and access gateways in front of legacy applications that cannot enforce their own controls
- A gradual rollout model for moving from perimeter defence to zero trust access decisions
- Why VPNs and Layer 4 tunnels create visibility and lateral-movement problems that architecture teams have to address
👉 Read Pomerium's analysis of the perimeter problem and zero trust access →
Perimeter security and zero trust: what IAM teams need to know?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: The perimeter problem: why network security fails under zero trust