VPN replacement strategies for identity-aware remote access

At a glance

What this is: This is an analysis of why traditional VPNs no longer fit modern remote access, and the core finding is that broad tunnel-based access increases exposure, visibility gaps, and lateral movement risk.

Why it matters: It matters because IAM, PAM, and NHI programmes increasingly govern humans, vendors, and workloads through the same access fabric, so remote access design now shapes identity blast radius.

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, and 56% of organizations experienced at least one VPN-related cyberattack in the last year.
• 30% of breaches included third-party involvement of some sort, up 15% from the previous year.
• 92% of organizations are concerned about third parties creating potential backdoors into the network through VPNs.

👉 Read Zero Networks' analysis of VPN alternatives and secure remote access

Context

VPNs still reflect a perimeter-era assumption: once a user authenticates, the network should trust the connection enough to place the user inside the environment. That model becomes fragile when remote staff, third-party vendors, and cloud-hosted services all share the same access fabric, because broad tunnels expand blast radius instead of constraining it.

For IAM teams, the problem is not remote access itself but the way traditional VPNs collapse identity, device, and resource boundaries into one session. That makes governance harder across human users, privileged operators, and non-human identities that depend on tightly scoped access paths.

The result is a mismatch between how organisations work now and how VPNs were designed to operate. A secure remote access strategy has to preserve connectivity without turning every authenticated session into a network-wide trust event.

Key questions

Q: What breaks when organisations keep using a traditional VPN for remote access?

A: Traditional VPNs break least-privilege governance because a single authenticated session often grants broad network reach. That makes containment harder, increases lateral movement potential, and blurs the line between employee, vendor, and privileged access. The result is a bigger identity blast radius than most teams intend.

Q: Why do VPNs make third-party access harder to govern?

A: VPNs tend to collapse external users into the same trust model as employees, even though vendor access should be narrower, shorter-lived, and easier to revoke. That creates offboarding gaps and makes it harder to prove that third-party connectivity matches the business task.

Q: How can security teams measure whether remote access controls are working?

A: Look for evidence that sessions are scoped to applications, not the whole network, and that access decisions are tied to identity, device posture, and context. If users can still reach many internal resources after one successful login, the control is not reducing blast radius enough.

Q: Who is accountable when a remote access pathway gives an attacker broad internal reach?

A: Accountability usually sits across IAM, infrastructure, and application owners, but the control failure is often a governance issue rather than a single technical mistake. Teams should be able to show who approved the access model, who owns third-party access, and who is responsible for revocation.

Technical breakdown

Why VPN tunnels create identity blast radius

A remote access VPN creates an encrypted path from an endpoint into the internal network, then usually routes traffic as if the device were on-premises. That model was workable when access was centralized and user populations were smaller. In modern environments, it creates identity blast radius because the session often inherits broad network reach even when the underlying task only needs one application or subnet. Once the tunnel is established, monitoring and segmentation must compensate for a design that already granted too much reach.

Practical implication: map every VPN use case to the smallest application or resource set and remove broad network entitlements where they are not essential.

How ZTNA changes remote access authorisation

Zero Trust Network Access shifts the unit of access from network presence to application-level policy. Instead of exposing internal assets and then filtering traffic, ZTNA brokers access after checking identity, device posture, and contextual signals. That makes authorisation continuous rather than front-loaded. The important distinction is that ZTNA is not just a different tunnel. It changes the trust boundary so the resource is hidden until policy explicitly allows access, which reduces discoverability and lateral movement opportunities.

Practical implication: align remote access policy to application identity and device risk rather than defaulting to network-level reach.

Why third-party access needs a separate governance path

Vendor and consultant access is often the hardest remote access problem because third parties need connectivity without becoming permanent extensions of the internal trust model. Traditional VPN access tends to flatten that distinction, giving external users the same broad path as employees. That is risky because third-party relationships change, credentials persist, and offboarding is often weaker than internal JML processes. Secure remote access for third parties needs tighter scoping, shorter access windows, and clear identity ownership across the full lifecycle.

Practical implication: treat vendor remote access as a governed exception path with explicit expiry, review, and offboarding controls.

Threat narrative

Attacker objective: The attacker aims to turn a single remote access foothold into broad internal reach that supports lateral movement, data access, or persistence.

1. Entry occurs through exposed VPN infrastructure or compromised VPN credentials, allowing an attacker to establish a trusted remote session.
2. Escalation follows when the tunnel grants broad internal reach, letting the attacker discover additional systems and move laterally with minimal friction.
3. Impact occurs when the attacker uses that wide access to expand control, access data, or persist inside the environment beyond the original entry point.

Breaches seen in the wild

• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
• Code Formatting Tools Credential Leaks — Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

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

NHI Mgmt Group analysis

Broad VPN access is an identity governance problem, not just a network design problem. Once a VPN session is treated as a generic trusted channel, the organisation loses the ability to express least privilege at the point where access is actually consumed. That is why the same access path becomes dangerous for employees, vendors, and privileged operators alike. The practitioner conclusion is simple: remote access governance must be defined by identity, device, and resource, not by network membership.

Standing remote access is the wrong mental model for third parties and elevated users. The article’s concern about vendors and overly permissive tunnels points to a deeper governance issue: remote access that persists longer than the task invites privilege creep and weak offboarding. This is especially relevant where human users and non-human identities share the same remote access pattern. Practitioners should treat every long-lived tunnel as an entitlement that needs explicit lifecycle control.

Identity blast radius is the right concept for VPN replacement decisions. The core question is not whether a new tool is faster than VPN, but whether it reduces the reachable surface of a valid session. A remote access design that hides assets until policy authorises them changes the security outcome materially. The practitioner implication is to measure replacement options by how much damage a single session can still do.

Continuous verification only matters if it changes access in-session. The article correctly notes that momentary checks such as a single MFA prompt do not solve post-authentication risk. When behavioural and contextual signals are ignored after login, attackers can reuse the original trust decision for the life of the session. The practitioner conclusion is to require controls that keep re-evaluating access, not just validating entry.

From our research:

• 85% of organizations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A further 47% report only partial visibility into those third-party connections, which leaves governance teams unable to verify the true access footprint in most environments.
• For lifecycle-heavy access paths, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the offboarding and rotation lens that remote access programmes often miss.

What this signals

Identity-aware remote access will increasingly be judged by how much of the environment remains hidden until policy authorises it. That means remote access, segmentation, and access review are converging into one governance problem. Teams should expect their VPN replacement roadmap to be evaluated alongside NIST Cybersecurity Framework 2.0 outcomes for access control and monitoring.

Session trust is becoming the new control boundary. If a user or vendor can pivot freely after authentication, the programme is still operating on a perimeter assumption. Security leaders should watch for access pathways that preserve productivity while shrinking the number of reachable assets per session.

With 30% of breaches including third-party involvement, remote access design is now part of third-party governance, not just infrastructure hygiene. The operational question is whether the access model can prove who connected, what they could reach, and when the access ended. That is where governance evidence, not marketing language, will decide whether a replacement is credible.

For practitioners

• Inventory VPN use by identity type Separate employee, vendor, and privileged operator use cases, then document which internal resources each group truly needs. Broad access paths should be replaced first where the task can be expressed as application-level access.
• Reduce exposed remote access surface Eliminate unnecessary open ports and internet-facing administration paths on remote access infrastructure. The goal is to make internal assets invisible unless policy explicitly authorises the session.
• Bind access to identity and device context Require remote access decisions to use user identity, device health, and contextual signals rather than tunnel presence alone. This is the practical difference between a broad VPN session and a governed access decision.
• Put third-party access on a separate lifecycle path Assign explicit owners, expiry windows, and offboarding steps for vendor connectivity. Align this with your lifecycle processes so external access is revoked when the business relationship or task ends.

Key takeaways

• Traditional VPNs create identity blast radius because they grant broad network reach after a single authentication event.
• Remote access replacement should be measured by how much it reduces exposed surface, lateral movement potential, and third-party trust.
• The right design principle is identity- and context-aware, least-privilege access that stays narrow throughout the session.

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 Access: Zero Trust Network Access is an access model that grants entry to specific applications or resources only after evaluating identity, device, and context. It changes the trust boundary from network presence to policy decision, which can reduce discoverability and lateral movement.
• Identity Blast Radius: Identity blast radius is the amount of damage a single authenticated session can cause across systems, data, and privileges. It is a practical way to measure whether access design stays narrow enough to contain misuse, compromised credentials, or over-permissioned sessions.
• Continuous Verification: Continuous verification is the practice of reassessing trust during a session instead of relying only on the initial login event. For remote access, it means identity and context signals must keep influencing authorisation after entry, not just at the front door.

What's in the full article

Zero Networks' full analysis covers the operational detail this post intentionally leaves for the source:

• A side-by-side breakdown of VPN, ZTNA, SASE, and SDP deployment tradeoffs for remote access teams.
• Specific configuration considerations for least-privilege access, MFA integration, and traffic visibility.
• The operational impact of cloud proxy bottlenecks, NAT obfuscation, and user experience degradation in legacy ZTNA.
• How Zero Networks positions just-in-time MFA and microsegmentation in a remote access architecture.

👉 The full Zero Networks article covers VPN risk patterns, ZTNA tradeoffs, and modern remote access design choices.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.