VPN replacement is now an identity governance decision

At a glance

What this is: This analysis argues that staying on VPN in 2026 is a security and governance decision, not a neutral default, because VPN access paths align with current attack patterns and federal Zero Trust guidance.

Why it matters: It matters because identity teams need to move from network-centric remote access to identity-driven controls that limit blast radius, reduce lateral movement, and align human and non-human access with Zero Trust principles.

👉 Read Appgate's analysis of VPN risk and ZTNA replacement in 2026

Context

In 2026, remote access security is no longer about whether users can connect, but about whether the access path itself creates unnecessary trust. VPNs expose internet-facing portals, flatten access once connected, and keep relying on static credentials, which is exactly the kind of model attackers target when they want broad internal reach.

The governance problem is familiar to IAM and PAM teams. If a remote access control still assumes network location is a proxy for trust, it conflicts with Zero Trust Architecture and with the direction of public-sector guidance that prioritises continuous verification, identity-driven decisions, and removal of ageing edge devices.

For organisations that also manage service accounts, workloads, and AI agents, the message is broader than VPN replacement. Remote access design now has to support identity-specific policy and session scoping across human and non-human identities, not just give a device a path onto the network.

Key questions

Q: What breaks when organisations keep treating VPN access as a trusted internal path?

A: The main failure is that a VPN turns successful authentication into broad network reach, which creates a large blast radius if credentials are stolen or bypassed. Once connected, attackers can often discover, pivot, and persist more easily than they could through a narrowly scoped application access model.

Q: Why do VPNs become a worse fit as organisations adopt Zero Trust Architecture?

A: Zero Trust Architecture assumes continuous verification and least privilege, while traditional VPNs usually grant access based on network connectivity after login. That mismatch matters because the control boundary is too coarse for modern identity governance, especially when remote access must support different actor types and different risk levels.

Q: What do security teams get wrong about replacing VPNs with Zero Trust Network Access?

A: They sometimes treat ZTNA as a transport swap rather than a governance change. The real shift is from network-centric access to identity-centric policy, which means teams must define the exact application, session, and actor scope they want to allow before migration starts.

Q: Who is accountable when legacy VPN infrastructure remains in place after exposure risks are known?

A: Accountability sits with the teams that own identity governance, remote access architecture, and infrastructure risk, because the decision is no longer purely technical. When a VPN remains a primary access path, it should be reviewed through the same control lens used for privileged access and high-risk endpoints.

Technical breakdown

Why VPN access paths remain attractive to attackers

VPN gateways concentrate authentication, routing, and trust decisions into a single exposed control point. That makes them ideal for credential spraying, authentication bypass, command injection, and post-compromise persistence. Once an attacker lands on the portal or steals a valid credential, a traditional VPN often turns that access into broad internal reach rather than a narrowly scoped session. The technical issue is not only exposure, but the trust model: connected users are frequently treated as effectively inside the perimeter. That design makes exploitation and lateral movement much easier than in access models that evaluate identity, device posture, and request context per application.

Practical implication: treat VPN gateways as high-risk identity front doors and remove any assumption that network connection equals trust.

How ZTNA changes remote access authorisation

Zero Trust Network Access replaces network-level reach with application-level entitlements. Instead of giving a user a tunnel into a subnet, ZTNA authenticates the identity, checks device posture and context, and then brokers access only to specific services. The result is a smaller attack surface and less lateral movement potential because protected resources remain hidden unless policy allows the session. In practice, ZTNA is not just a transport change. It is a policy model change that aligns access with least privilege and continuous verification, which is the core difference between perimeter logic and identity-centric access control.

Practical implication: map current VPN use to application-level access requirements and replace broad subnet access with per-resource policy.

Identity-driven access control for human and non-human identities

Remote access design increasingly has to govern both people and machine identities. Human users may come through SSO and MFA, while service accounts, workloads, or AI agents may require tighter scoping, separate trust boundaries, and different lifecycle controls. VPNs are weak at that distinction because they primarily move traffic rather than govern actor type. Identity-driven access control lets teams express policy by subject, device, posture, and resource, which is essential when the environment includes APIs, automated jobs, and agents that should never inherit a human-style network session. That is where lifecycle and privilege governance become operational, not theoretical.

Practical implication: separate human remote access from NHI access paths and enforce different control sets for each actor type.

NHI Mgmt Group analysis

VPN dependence is now an identity governance problem, not only a network architecture choice. The article’s core finding is that remote access paths are being actively optimised against by attackers while policy direction moves toward continuous verification and identity-driven controls. That means VPN replacement affects IAM, PAM, and lifecycle governance, not just networking. Practitioners should treat remote access as a governed identity flow, not a tunnel.

Standing network trust is the wrong abstraction for modern access governance. VPNs still flatten access after authentication, which means the control boundary is too coarse for environments that mix human users, workloads, and AI-enabled services. The practical implication is that least privilege must be expressed at the application and session level, not through a blanket network grant that survives too long and reaches too far.

Identity blast radius is the better metric than connectivity success. In a VPN model, success is measured by whether the user connected. In a Zero Trust model, the relevant question is how far that identity can move if credentials are compromised. That reframes the governance discussion from uptime and convenience to containment and enforceable scope.

Remote access modernisation will increasingly be judged against Zero Trust and edge-device hygiene expectations. The policy environment is tightening around inventory, unsupported appliances, and continuous verification, which makes legacy VPN use harder to justify in regulated or critical environments. Practitioners should expect more scrutiny of whether access design still depends on perimeter trust.

The next stage of remote access governance is actor-specific policy. Human users, service accounts, and autonomous systems should not share the same assumptions about session duration, trust, or entitlement scope. The direction of travel is clear: identity governance must distinguish actor type first, then apply the appropriate access model and control boundary.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• Forward pivot: For teams modernising remote access, the deeper question is how Top 10 NHI Issues change when identity is no longer tied to a VPN tunnel.

What this signals

Identity teams should expect remote access modernisation to be judged on containment, not convenience. The security conversation is moving away from whether a connection is available and toward whether the connection can be bounded tightly enough to survive credential compromise. That is where ZTNA, lifecycle separation, and application-level policy become programme issues rather than architecture preferences.

Network trust is collapsing into actor-specific governance. Human users, service accounts, and autonomous systems now require different access paths, different review cadence, and different assumptions about session lifetime. The practical pressure is to prove that a single compromised session cannot behave like an internal user simply because it reached a portal.

Identity blast radius: the useful metric for remote access is no longer login success, but how far a compromised identity can travel after authentication. Teams that can measure and shrink that radius will have a clearer path from VPN dependency to enforceable Zero Trust.

For practitioners

• Inventory VPN-dependent access paths Map which applications, services, and user groups still rely on VPN and identify where broad network reach exceeds actual business need. Prioritise resources that expose sensitive data or administrative functions.
• Re-scope remote access to application entitlements Replace subnet-level access with per-application policy wherever possible so the access decision follows the identity and the resource, not the network tunnel. This reduces lateral movement when credentials are reused or stolen.
• Separate human and non-human access paths Keep service accounts, workloads, and AI-enabled services off human-style remote access patterns. Use distinct lifecycle, authentication, and entitlement controls so non-human identities do not inherit overbroad interactive access.
• Track edge-device exposure as an identity risk Include VPN gateways, remote access concentrators, and other edge appliances in identity governance reviews because their compromise often turns authentication into internal foothold. Patch windows and access scope should be treated as linked risk factors.
• Measure blast radius, not just connection success Review how far a compromised account could move after VPN authentication and use that to prioritise Zero Trust controls. The key question is no longer whether access works, but how much damage a single session can create.

Key takeaways

• VPN dependence in 2026 is a governance choice because it preserves broad trust after authentication.
• The evidence points to an attack surface that is both heavily targeted and increasingly exposed through edge and VPN devices.
• Practitioners should shift remote access design toward identity-centric policy, smaller blast radius, and actor-specific controls.

Key terms

• Zero Trust Network Access: Zero Trust Network Access is a remote access model that grants users access to specific applications instead of placing them on the network. It verifies identity, device posture, and context before connection and keeps access narrow enough to reduce lateral movement and overexposure.
• Identity blast radius: Identity blast radius is the amount of damage a compromised identity can cause after authentication. In remote access design, it measures how far an attacker can move, what they can reach, and how much trust the architecture gives them before another control intervenes.
• Continuous verification: Continuous verification is the practice of re-checking trust throughout a session instead of only at login. For identity programmes, it means access decisions can change when device posture, user risk, or resource sensitivity changes, which is essential in Zero Trust and high-risk remote access environments.

What's in the full article

Appgate's full article covers the operational detail this post intentionally leaves for the source:

• Specific guidance on replacing VPN-centric remote access with ZTNA patterns in real environments
• The source's discussion of recent VPN-related attack trends and vulnerability pressure on edge devices
• Appgate's explanation of how its ZTNA architecture maps to identity-driven access and session scoping
• Implementation context for organisations moving from tunnel-based access to application-level entitlements

👉 The full Appgate article covers the VPN breach patterns, Zero Trust guidance, and ZTNA operating model in more detail.

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.