TL;DR: VPNs still create a broad trust zone after authentication, while zero trust continuously verifies users, devices, and policy conditions, according to Beyond Identity’s analysis. For IAM and NHI practitioners, the real shift is from network reachability to task-scoped access that limits blast radius and forces stronger identity checks.
At a glance
What this is: This article compares VPN and zero trust access models and concludes that perimeter-based trust leaves too much standing access after authentication.
Why it matters: It matters because IAM teams need access models that limit blast radius, account for device state, and support task-scoped control across human, NHI, and remote access patterns.
Context
Zero trust vs VPN is fundamentally a question of where trust lives in the access path. VPNs create an encrypted tunnel and then tend to inherit broad network-style access after authentication, which makes perimeter trust the governing assumption rather than task need.
That assumption breaks down in modern IAM programmes because users, devices, cloud applications, and third-party connections no longer sit cleanly inside a single corporate boundary. For NHI and human identity teams alike, access has to be evaluated at the moment of use, not assumed from network entry.
Beyond Identity frames the issue as a transition from blanket reachability to conditional, task-scoped access. The practical consequence is that identity policy, device posture, and resource sensitivity become the control plane, not the VPN tunnel itself.
Key questions
Q: What breaks when organisations rely on VPNs for modern remote access?
A: VPNs tend to extend network trust more broadly than modern risk models allow. In distributed environments, that can expose too much of the internal network once a user connects, especially when personal devices and cloud applications are involved. Browser-mediated access narrows the trust boundary to the session rather than the network.
Q: Why does browser-based zero trust reduce risk compared with broad VPN access for remote users?
A: Browser-based zero trust reduces risk because it narrows access to specific applications and sessions instead of exposing the wider network. The browser can isolate activity from local threats like malware, ransomware, and phishing, while policy controls limit what users can view, copy, upload, or download. That combination shrinks the attack surface and improves containment when credentials or endpoints are compromised.
Q: How do security teams know whether zero-trust remote access is actually working in practice?
A: Security teams should look for evidence that users only reach approved resources, sessions are brokered through controlled gateways, and access decisions are enforced consistently across cloud and on-prem systems. Strong signals include reduced reliance on VPNs, clearer session logs, and fewer over-privileged connections. If users can reach unrelated systems easily, the zero-trust model is not being applied effectively.
Q: What is the difference between Zero Trust and VPN for privileged access?
A: Zero Trust narrows privileged access to the specific request, while a VPN usually grants a broader network path after login. For privileged operations, the difference is whether access is continuously checked and time-bound or simply inherited for the life of the session.
Technical breakdown
Why VPN access creates a standing trust zone
A VPN is an encrypted transport mechanism, not an access governance model. Once connected, the user often inherits broad network reach that resembles office presence, which means the tunnel protects the session but does not meaningfully constrain what can be reached inside it. That design made sense when applications were mostly on-premises and network location correlated with trust. In cloud-first environments, however, network entry no longer proves need-to-access, device health, or task scope. Practical implication: treat VPN connectivity as transport only, not as the basis for authorisation.
Practical implication: Separate transport security from authorisation and avoid using VPN connection state as a proxy for access approval.
How zero trust changes identity verification and policy enforcement
Zero trust replaces perimeter assumption with continuous evaluation. Users and devices are not granted blanket access; they receive only the resources needed for a specific task, and policy can respond to device posture, software state, and other conditions. This is where identity becomes the control point. Authentication is necessary but not sufficient, because a valid login does not guarantee a trusted session throughout its lifetime. Practical implication: enforce access decisions at the resource and session level, not only at initial authentication.
Practical implication: Apply conditional access and ongoing verification so identity posture, not network location, governs each resource request.
Why task-scoped access is the real governance shift
The article’s most important operational point is not that VPNs are old and zero trust is new. It is that access should map to task scope rather than network membership. That changes how teams think about least privilege, third-party connectivity, and remote work because the unit of control becomes the job to be done. In NHI programmes, that same logic applies to service accounts and tokens that should never carry broader access than the workflow requires. Practical implication: design access around the smallest valid working set, then remove everything else from the default path.
Practical implication: Use task-scoped entitlements and minimise default access paths for both human and non-human identities.
NHI Mgmt Group analysis
Perimeter trust is the wrong security assumption for modern access. VPNs still model access as if entry into the network is the meaningful security boundary, but cloud services, third-party integrations, and remote work have broken that premise. The article shows that once access is granted at the tunnel, the control environment becomes too coarse to reflect actual task need. Practitioners should treat this as a boundary failure in governance, not just a transport problem.
Task-scoped access is now the decisive control variable. Zero trust matters because it shifts the question from "can this user get on the network" to "what can this identity use right now". That distinction is especially important for identity teams managing both human and non-human access, because the blast radius of excess privilege is determined at the resource layer, not the connection layer. The programme implication is to re-centre access design on workload and task boundaries.
Zero-trust identity is a governance model, not a network feature. The article makes clear that device checks, policy enforcement, and conditional access only work when identity policy is authoritative. If the VPN is still treated as the primary trust gateway, identity controls become secondary and reactive. The implication is that IAM architecture must own access decisions end to end rather than inherit them from perimeter tooling.
Zero trust validates least privilege by making access temporary and contextual. A user or device should not receive broad standing access simply because authentication succeeded once. That is especially relevant for NHI governance, where credentials often persist beyond the task that created them. The practitioner conclusion is that the access model itself must be rebuilt around conditions, not convenience.
Modern IAM programmes should measure scope, not just login success. The article’s strongest operational signal is that authentication alone no longer tells you whether access is appropriately constrained. Teams need to know whether users and devices can reach only the resources needed for the moment, whether stale accounts remain reachable through broad network access, and whether third-party connections are governed by the same policy logic. Practitioners should use that lens to validate their zero-trust transition.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
- Read next: Zero Trust Identity Guide
What this signals
Zero-trust transition exposes hidden entitlement debt. The biggest risk is not whether a VPN is encrypted, but how much unneeded reach it still confers after login. IAM teams should expect the first zero-trust findings to come from overbroad access paths, especially where remote access, third parties, and privileged users have been allowed to inherit network trust.
Task-scoped access is the operational definition of zero trust. If users or devices can still move laterally after authentication, the programme is still perimeter-led in practice. The next step for practitioners is to align policy enforcement, device checks, and access reviews around what each identity needs to do now, not what network they are on.
For practitioners
- Audit perimeter assumptions in remote access Map where VPN connectivity still grants broader reach than the task requires, especially for applications, file shares, and third-party connections. Remove any access path that exists only because the tunnel exists.
- Move access decisions to the resource layer Require policy checks at the application or service level so authentication to the network does not automatically imply entitlement to data or systems.
- Review privileged and stale accounts first Identify unused, old, or highly privileged accounts that still benefit from broad VPN reach and narrow or remove those entitlements before expanding zero-trust controls.
- Apply task-scoped access to non-human identities Treat service accounts, API tokens, and other NHIs as session-bound access paths that should not inherit blanket network reach from the human operators around them.
- Use device posture as part of authorisation Block or reduce access when devices lack required patches, security software, or baseline posture so connectivity is not the only gatekeeper.
Key takeaways
- VPNs remain risky because they convert authentication into broad post-login reach, which is too much trust for modern cloud and remote access patterns.
- The practical evidence in this article is that zero trust changes the unit of control from the network boundary to the task and resource boundary.
- IAM teams should use the transition to identify stale accounts, narrow third-party reach, and make device posture part of access decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The article is explicitly about replacing perimeter trust with zero trust access decisions. |
| Recommendation — Apply zero-trust principles to move authorisation from the network edge to the resource and session layer. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece focuses on limiting access scope after authentication. |
| Recommendation — Review entitlements so authenticated users receive only the permissions required for the task. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Task-scoped access and reduced blast radius map directly to least-privilege governance. |
| Recommendation — Enforce least privilege so network access never becomes a substitute for need-to-access. | ||
| MITRE ATT&CK | TA0008 — Lateral Movement | Broad VPN reach increases the opportunity for lateral movement after initial access. |
| Recommendation — Reduce internal reachability to make post-compromise lateral movement harder. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article's task-scoped access argument extends to machine and service identities with excessive reach. |
| Recommendation — Audit NHIs for unnecessary network reach and cut any privilege that exceeds the job to be done. | ||
Key terms
- 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.
- DNS Tunneling: DNS tunneling is the use of DNS queries and responses to carry hidden data for command-and-control or exfiltration. Because DNS is commonly trusted and lightly inspected, attackers can hide malicious communication inside traffic that looks routine at first glance.
- Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
- Device Posture: The current security condition of a device or runtime at the moment access is requested or renewed. Posture can include patch state, protection status, integrity, and whether the endpoint is managed. In identity governance, posture is part of the trust decision, not a separate endpoint problem.
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.
Published by the NHIMG editorial team on May 29, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org