VPN replacement strategies for identity-aware remote access

At a glance

What this is: This is an analysis of VPN replacement strategies for remote access, arguing that identity-aware models such as ZTNA better fit hybrid work, third-party access, and modern attack patterns.

Why it matters: IAM, PAM, and NHI teams need to treat remote access as an identity decision, because broad network tunnels create privilege, visibility, and offboarding problems across users, vendors, and workloads.

By the numbers:

• 91% of security leaders express concerns about VPNs leading to a security breach.
• Zero-day exploits targeting edge devices and VPNs grew almost eightfold in the last year, according to Verizon's 2025 Data Breach Investigations Report cited by Zero Networks.
• 56% of organizations experienced at least one VPN-related cyberattack in the last year, according to Verizon's 2025 Data Breach Investigations Report cited by Zero Networks.
• 30% of breaches included third-party involvement of some sort last year, up 15% from the previous year.

Context

Remote access VPNs were built for a different operating model: a user authenticates, a tunnel opens, and the network treats that user as if they are already inside. That design creates a broad trust boundary, which is increasingly misaligned with hybrid work, third-party access, and attacker tradecraft that targets credentials and exposed edge services.

The identity governance problem is not remote access itself. The problem is that VPNs often convert identity assurance into network reach, then leave practitioners to manage lateral movement, device uncertainty, and offboarding risk after the tunnel is already established.

For NHI and IAM programmes, the practical question is whether access should be granted to a network or to a specific resource, and whether that decision can be continuously re-evaluated instead of being assumed at session start.

Key questions

Q: What breaks when a VPN is used as the main remote access control in hybrid environments?

A: The main failure is that a VPN authenticates the user and then grants broad network reach, which makes lateral movement much easier than application-scoped access would. In hybrid environments, that means the control protects the entry point but not the post-login attack surface. Security teams should judge remote access by how little it exposes after login, not by whether the tunnel works.

Q: Why do legacy VPNs increase the risk of lateral movement after a successful login?

A: Legacy VPNs often place an authenticated user inside a trusted network zone, where internal segmentation is weaker than the access decision at the edge. Once inside, an attacker can probe multiple systems without repeated authorization checks. That turns a single credential compromise into a much larger security event, especially where third-party or contractor access is involved.

Q: How do teams know whether ZTNA is actually reducing remote access risk?

A: Look for three signals: internal resources are not internet-exposed, access is limited to named applications, and authorization still reflects identity and context during the session. If those conditions are absent, the design is behaving more like a VPN than a ZTNA model.

Q: What is the difference between VPN access and application-level remote access?

A: VPN access grants a network tunnel, while application-level remote access grants entry to a specific service after policy checks. The first expands the trusted zone; the second keeps trust narrow and easier to govern.

Technical breakdown

Why broad VPN tunnels expand identity risk

A remote access VPN typically authenticates a user and then extends that user into the internal network, rather than limiting access to a specific application or resource. That means the control boundary is network-level, not identity-level, and any weakness in credential hygiene, MFA configuration, or device trust can translate into broad reach. Once inside, the user often inherits the same connectivity model as an on-prem endpoint, which is why VPN compromise so often becomes a lateral movement problem rather than a simple login event.

Practical implication: replace network-wide tunnels with access decisions that bind identity to specific resources and session context.

How ZTNA changes access control and visibility

Zero Trust Network Access shifts the decision point from the network to the application. Instead of exposing internal services and then filtering traffic, ZTNA makes resources invisible until identity, device posture, and policy conditions are satisfied. That reduces internet-facing exposure and gives practitioners a cleaner enforcement point for least privilege. The architectural difference matters because it moves monitoring and authorisation closer to the request, not the network perimeter, which is where modern identity governance works best.

Practical implication: evaluate whether the access layer can enforce application-level policy without publishing internal resources.

Where legacy ZTNA implementations create new trade-offs

Not all identity-aware remote access is equal. Some legacy ZTNA designs route traffic through cloud proxies or single-IP translation layers that introduce latency, hide source IP context, and create new blind spots for troubleshooting and policy enforcement. In practice, that can lead to shadow IT workarounds or pressure to relax controls. The lesson is that identity-aware access should not trade one operational bottleneck for another, because poor user experience often becomes a governance failure in disguise.

Practical implication: test remote access designs for latency, source visibility, and policy clarity before replacing a VPN at scale.

Breaches seen in the wild

• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
• CitrixBleed 2 2025: CitrixBleed 2 leaked NetScaler session tokens from memory, letting attackers hijack VPN sessions and skip MFA at 100+ organisations.

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-to-network trust is the governance problem, not just the transport mechanism: Traditional remote access converts identity proof into broad network reach, which means the access decision is made too early and too coarsely. That model works poorly when third parties, hybrid endpoints, and attacker-sourced credentials all share the same tunnel. The implication is that remote access governance now has to operate at the resource and session layer, not at the perimeter.

Identity-aware remote access is the more durable control model for hybrid estates: ZTNA is not valuable because it is newer; it is valuable because it lets practitioners bind access to identity, device, and context without exposing the internal network. That aligns better with least privilege, continuous verification, and compartmentalised access. For security architecture, the relevant shift is from connectivity-first design to authorisation-first design.

VPN replacement is a third-party governance decision as much as a network decision: The article’s third-party risk discussion is the clearest sign that remote access belongs in lifecycle governance. Vendor access should be scoped to named resources, time-bounded, and revocable without inheriting the entire internal network. That changes how IAM, PAM, and NHI teams think about offboarding, review, and access boundaries.

Network invisibility is the named concept practitioners should track: If internal assets remain directly exposed to the internet, the organisation has not actually reduced its attack surface. Hiding resources until policy is satisfied changes the exposure model in a way that ordinary VPN tunnels do not. Practitioners should treat visibility of the internal network as a control outcome, not a convenience feature.

What this signals

Network invisibility is the real remote access objective: If internal systems remain directly reachable from the internet, the organisation has not reduced exposure, it has only moved the trust boundary. Practitioners should evaluate whether remote access design hides resources until policy is satisfied, because that is what prevents opportunistic probing from becoming a foothold.

Third-party access should be treated as a governed identity path, not a convenience tunnel. Vendor and consultant access needs explicit scope, revocation, and offboarding so that remote connectivity does not become a standing privilege with no practical containment boundary.

For practitioners

• Define application-scoped access boundaries Map the remote access use cases that only need named applications or services, then remove any assumption that the full internal network must be reachable for those users or vendors.
• Require identity and device context at session start Make access decisions depend on user identity, device posture, and contextual policy so that a remote session is not treated as trusted once the tunnel opens.
• Eliminate open internet exposure for internal assets Prefer designs that keep internal systems invisible until policy is satisfied, rather than publishing ports and relying on post-connect filtering.
• Review third-party access as a lifecycle control Treat vendor connectivity as governed access with explicit scope, revocation, and offboarding steps, not as a standing VPN entitlement.

Key takeaways

• VPNs are increasingly misaligned with hybrid work because they grant broad network reach after a single authentication event.
• The security problem is not remote access itself, but the way traditional tunnels turn identity into perimeter trust.
• Identity-aware remote access changes the control point to the resource and the session, which gives IAM teams a more durable least-privilege model.

Key terms

• Remote Access VPN: A remote access VPN is an encrypted tunnel that places an authenticated user or device inside a private network as if it were local. In practice, it often turns one successful login into broad internal reach, which makes least privilege and containment harder to enforce.
• Zero Trust Network: A Zero Trust Network is a network security approach that does not trust users, devices, or traffic by default. Every connection is continuously verified using identity, device posture, context, and policy before access is granted. It assumes breach, limits lateral movement, and treats network access as conditional rather than implicit.
• Continuous Verification: A Zero Trust practice that re-evaluates trust during the session instead of relying on a single successful login. The control is stronger when context signals are available in real time and when the identity programme can act on those signals without creating excessive exceptions.
• Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.