Zero trust exposes the limits of VPN-first remote access

At a glance

What this is: This is an analysis of why VPN-based remote access is losing fit in hybrid environments and how Zero Trust changes the access model for users, devices and applications.

Why it matters: It matters because IAM teams now have to govern remote access through continuous verification and device trust, not rely on a broad network boundary that can be bypassed with a single credential.

Context

VPNs were built for office-centric access models where the network perimeter was assumed to be the main boundary of trust. In hybrid and cloud-heavy environments, that assumption no longer holds, and remote access controls need to be evaluated as identity decisions rather than network tunnels.

For IAM, PAM and NHI programmes, the key issue is not whether access is encrypted in transit. It is whether the access decision remains too broad after authentication, especially when users, devices and applications now connect from distributed environments with changing risk signals.

Zero Trust addresses that gap by forcing continuous verification, narrower entitlements and stronger device checks. The governance challenge is to align identity policy, certificate trust and monitoring so that remote access does not become a standing privilege lane.

Key questions

Q: How should security teams implement zero trust network access for remote workers and enterprise apps?

A: Security teams should verify the identity of every user and device before granting access, then apply granular, per-request policies instead of trusting network location. The practical goal is to replace broad perimeter access with conditional access that reflects context, resource sensitivity, and session risk. That approach reduces exposure from compromised credentials while preserving usability for distributed workforces.

Q: Why do VPNs create more risk in cloud-heavy environments?

A: Because VPNs assume that connectivity from inside the tunnel implies trust. In cloud-heavy environments, applications are distributed and identities are fragmented, so a stolen credential can open access well beyond the original remote session. That makes flat network trust a poor fit for modern identity governance.

Q: What breaks when third-party remote access is not tightly scoped?

A: When vendor access is not tied to a specific purpose and expiry, organisations lose control over who can reach sensitive systems, what they can touch, and how long the access remains valid. That creates excess privilege, weak traceability, and a larger breach surface if the vendor or one of its suppliers is compromised.

Q: What should IAM teams prioritise when Zero Trust rollout stalls?

A: They should prioritise closing control-plane gaps before adding more tools or more policy language. The first fix is usually not another product but a clearer enforcement model that connects identity, device posture, privileged access, and telemetry. Without that alignment, each new control just adds another silo to coordinate.

Technical breakdown

Why vpn-first access creates a broad trust zone

A VPN authenticates the session and then typically places the user inside a trusted network segment. That architecture was acceptable when most applications lived behind a perimeter, but it becomes problematic when cloud services, SaaS platforms and distributed data stores sit outside that boundary. The result is a large implicit trust zone where one valid credential can open access to more than the request actually needs. In identity terms, the control point moves too far upstream, before the resource-specific decision is made. This is why VPNs often reduce transport risk without solving authorisation risk.

Practical implication: treat VPN access as a transport layer, not as the main authorisation control for remote users.

How Zero Trust changes identity and device verification

Zero Trust shifts the decision from network location to the context of each request. Identity is re-evaluated continuously through MFA, adaptive signals and certificate-backed trust, while device posture determines whether the endpoint should be admitted at all. That creates a narrower access envelope because approval is no longer inherited from being on the VPN. The access path becomes time-bound, context-bound and resource-specific. For remote work, this is a governance shift as much as a technical one, because policy must decide what trust signals matter before access is granted.

Practical implication: map remote access policy to per-request identity and device checks instead of a one-time VPN login.

Why least privilege matters more in cloud-heavy remote access

When applications are spread across multiple clouds and SaaS services, a single remote access method cannot safely imply broad internal reach. Least privilege becomes essential because the attack surface is no longer the office network but the combination of identity, endpoint and application entitlements. If a credential is compromised, the blast radius depends on how much standing access the account retains after authentication. Zero Trust works only when access scope is narrowed to the task and continuously re-evaluated. Without that, remote access simply repackages old perimeter assumptions in a newer architecture.

Practical implication: reduce standing remote access scope before adding more authentication layers.

Threat narrative

Attacker objective: The attacker aims to turn one remote access credential into broader internal reach and then use that reach to compromise sensitive systems or data.

1. Entry occurs when an attacker obtains a valid VPN credential or abuses a weak remote access path to enter the environment.
2. Credential abuse follows because the VPN login can provide broad network reach rather than access limited to one application or one task.
3. Escalation happens when that broad reach exposes critical systems, cloud workloads or sensitive data that were not meant to be reachable from the initial session.
4. Impact is achieved when the attacker moves from a remote access foothold into systems that should have required narrower, continuous identity checks.

Breaches seen in the wild

• CitrixBleed 2 2025: CitrixBleed 2 leaked NetScaler session tokens from memory, letting attackers hijack VPN sessions and skip MFA at 100+ organisations.
• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

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

VPN fatigue is not just a user-experience complaint. It is a sign that remote access design is still treating network entry as the main security decision, even when applications, data and users are now distributed across clouds and devices. That model creates a trust gap between authentication and actual authorisation. Practitioners should read the fatigue signal as a governance failure, not a performance issue.

Certificate-backed remote access changes the control point, but not the governance burden. Digital certificates and adaptive MFA can strengthen identity assurance, yet they still depend on policy that decides when a device is trusted, what resource can be reached, and how much access is retained after the session starts. The access model is only as strong as the entitlement boundary around it. IAM teams need to govern the boundary, not just the login.

Least privilege becomes the defining remote access control once the perimeter dissolves. In hybrid environments, the weakest link is no longer the tunnel itself but the amount of access a successfully authenticated session inherits. That means remote access governance must be built around task scope, not user presence on a trusted network. Practitioners should measure success by how little a compromised session can do.

Identity trust in Zero Trust is increasingly a device and certificate problem, not a network problem. If endpoint posture is not part of the decision, remote access simply recreates broad trust with newer language. The field should treat device assurance, certificate lifecycle and privilege scope as one governance chain. That is where practical resilience now lives.

Zero Trust is becoming the organising model for remote access because VPN-era assumptions no longer match operational reality. That does not make VPNs obsolete in every use case, but it does mean they should stop being the primary trust boundary for cloud-first work. The strategic question for IAM leaders is how quickly access policy can move from perimeter trust to continuously evaluated identity trust.

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

VPN-first access is being replaced by identity-first access. The practical shift is that access policy now has to evaluate the user, the device and the application in one decision path instead of assuming the network boundary can carry trust. For remote work programmes, that means zero trust becomes an access architecture question, not a branding exercise.

Continuous verification will matter more than initial login strength. A strong MFA prompt at session start does not solve the problem if the session later inherits broad network reach. IAM teams should expect more pressure to connect certificate trust, device posture and privilege scope in the same control plane.

Perimeter thinking leaves a residual access gap. Once users work across clouds and mobile endpoints, the old assumption that internal equals trusted stops being useful. The programme implication is to move from session admission to ongoing entitlement control, especially where privileged or sensitive applications are involved.

For practitioners

• Reclassify VPN as a transport control Use the VPN only for encrypted connectivity and move the real trust decision to application-level identity and device policy.
• Bind remote access to device trust Require endpoint posture checks and certificate-backed trust before any sensitive application is reachable from a remote session.
• Shrink standing access after login Review the entitlements that follow a successful remote session and cut any broad network reach that is not tied to a named business task.
• Separate privileged access from everyday remote access Route admin and high-risk actions through a privileged access process instead of letting them ride on the same remote connectivity path as standard users.

Key takeaways

• VPN-based remote access still encrypts traffic, but it leaves too much trust attached to a successful login in hybrid and cloud-heavy environments.
• The real risk is the size of the access window after authentication, not just the strength of the tunnel itself.
• Zero Trust changes the governance model by tying access to identity, device posture and least privilege at the point of request.

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.
• Virtual Private Network: A virtual private network creates an encrypted tunnel between a device and a network, or between two networks, over an untrusted transport. It protects data in transit, but it does not by itself provide the full policy, routing, or segmentation controls that larger access programmes often need.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Device Trust: Device trust is the confidence that a requesting endpoint is known, managed, and in a compliant state. It matters because identity alone does not prove safety. In zero trust programmes, device trust becomes one of the inputs used to decide whether access should be granted or sustained.

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.