VPNs solve privacy, but not the identity trust problem

At a glance

What this is: This article explains that VPNs improve transport privacy, but the underlying identity trust problem in remote access remains unresolved.

Why it matters: It matters because IAM and security teams must treat VPNs as one control in a broader access model, not as proof that a user or device is trustworthy.

Context

A virtual private network creates an encrypted tunnel between a device and a network, which protects traffic in transit. That mechanism reduces exposure on public Wi-Fi and hides the device IP address from the destination service, but it does not prove the user, the device posture, or the legitimacy of the session.

For IAM and security programmes, the problem is that VPN use is often mistaken for identity assurance. The article’s core point is that remote access still needs explicit governance over authentication, device trust, and session-level access decisions rather than relying on network location or encrypted transport alone.

Key questions

Q: How should security teams govern VPN use in a zero trust architecture?

A: Security teams should treat VPNs as transport controls, not as proof of trust. Access should still depend on identity strength, device posture, and policy-based authorisation. In practice, that means the tunnel can remain, but the decision to reach an application must be made separately from the fact that a network connection exists.

Q: Why do VPNs not solve the identity trust problem for remote access?

A: VPNs protect traffic in transit, but they do not verify whether the user, device, or session should be trusted. A secure tunnel can still carry a compromised endpoint or an overprivileged account. Identity trust requires stronger governance than hiding IP addresses or encrypting the path between endpoints.

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: What is the difference between VPN privacy and access assurance?

A: VPN privacy protects data in transit and obscures the source network, while access assurance determines whether a user or device should be allowed to reach a resource at all. They solve different problems, and one cannot replace the other in a modern identity programme.

Technical breakdown

How VPN tunnelling changes traffic visibility

A VPN routes traffic through a remote server so the destination sees the server IP, not the device IP. The traffic is also encrypted between the client and the VPN endpoint, which protects confidentiality against local network snooping. That solves a transport problem, not an identity problem. The tunnel does not verify whether the endpoint is healthy, whether the user should still have access, or whether the session is being used in a trusted context. In practice, the VPN becomes a privacy layer around traffic, while identity assurance must come from separate authentication, authorisation, and device trust controls.

Practical implication: treat VPN encryption as transport protection, not as evidence that access is safe.

Why VPNs do not create complete anonymity

The article notes that VPNs hide some network identifiers, but they do not remove other sources of traceability such as browser history, cookies, or service-side telemetry. That means a VPN can reduce one category of exposure while leaving enough session and endpoint evidence for tracking and compromise assessment. For identity governance, this matters because privacy controls and trust controls are different objectives. A tool that obscures the source network does not eliminate the need to know who is authenticating, from what device, and under which policy conditions. Remote access design has to assume that visibility remains at multiple layers.

Practical implication: design remote access policies around session trust, not just network concealment.

Protocol strength does not equal identity assurance

The article compares protocols such as L2TP, PPTP, and OpenVPN in terms of encryption strength and security posture. Those differences matter for transit protection, but they do not close the larger governance gap around who is allowed in and how access is continuously validated. A stronger tunnel can still carry an untrusted user session, a compromised endpoint, or an overbroad access entitlement. The governance mistake is to equate better tunnelling with better access assurance. Identity security requires separating channel security from authentication strength, device trust, and authorisation scope.

Practical implication: assess VPN protocols for transport security, then govern access separately with identity and device controls.

Threat narrative

Attacker objective: The objective is to exploit the gap between protected transport and unverified identity so that access appears legitimate even when trust is not established.

1. Entry occurs through a remote access path where traffic is shifted into an encrypted tunnel, which reduces exposure but does not eliminate the trust decision at login.
2. Escalation follows when organisations treat the VPN connection itself as a trust signal, allowing access decisions to rest on network reachability instead of device or identity assurance.
3. Impact is broader than privacy loss, because compromised or unmanaged remote sessions can still reach internal resources while appearing to come from an approved access channel.

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.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

VPN transport security and identity trust are not the same control. Encrypted tunnelling reduces interception risk, but it does not answer the governance question of whether the session should be trusted at all. In identity programmes, that means the control objective shifts from hiding traffic to validating the user, the device, and the session state before access is granted.

Network location is a weak proxy for authorisation. VPNs were designed to solve secure connectivity, not to prove entitlement. When teams let tunnel presence stand in for access assurance, they preserve a legacy perimeter assumption inside a remote-work architecture. The practitioner implication is that remote access should be governed as an identity decision, not as a networking convenience.

Remote access controls need device trust, not just user trust. The article makes clear that browsing privacy and access security are different outcomes, and that endpoint exposure remains even inside a VPN session. That is why identity governance has to account for device posture, authentication strength, and entitlement scope together rather than treating the VPN as a sufficient gate.

Identity trust debt accumulates when privacy tools are mistaken for access controls. A VPN can lower exposure on public networks while leaving cookies, browser telemetry, and compromised endpoints in play. That creates a false sense of closure around remote access risk. Practitioners should treat this as a governance gap in access design, not a tooling gap in transport encryption.

Zero Trust thinking is the correct counterweight to VPN-only assumptions. VPNs remain useful, but they should sit inside a model that continuously verifies identity and device conditions. The article reinforces a broader shift in the market: remote access programmes are moving from tunnel-centric design toward trust-centric authorisation, which is where durable identity governance belongs.

What this signals

Identity trust debt: Remote access programmes often keep the tunnel while failing to modernise the decision logic behind it. That leaves organisations with encrypted connectivity but legacy assumptions about who and what can be trusted once the connection is established.

VPNs should now be evaluated as one layer in a broader access architecture rather than as a remote-work policy in themselves. The practical question is whether the programme can still separate connectivity from entitlement when the endpoint, the user, and the session all need independent trust signals.

For practitioners

• Separate tunnel security from access trust Keep VPN encryption and IP masking in the transport layer, but require identity and device assurance before granting internal access.
• Treat device posture as a gate Use endpoint health, managed-device status, and session context as explicit conditions for remote access, not as after-the-fact signals.
• Review whether VPN presence is acting as an authorisation proxy Check whether internal applications, jump paths, or legacy policies still grant access simply because the connection arrives through the tunnel.
• Rebuild remote access around continuous verification Move toward access decisions that are re-evaluated during the session, especially for sensitive applications and administrative functions.

Key takeaways

• VPNs reduce exposure in transit, but they do not solve the access governance problem that determines whether a remote session should be trusted.
• The article shows that privacy, anonymity, and identity assurance are different outcomes, and confusing them creates weak remote access design.
• The control gap is not the tunnel itself, but the assumption that encrypted connectivity can stand in for authentication, device trust, and authorisation.

Key terms

• OpenVPN Tunnel: An OpenVPN tunnel is an encrypted network path that carries traffic between a client and a server over a virtual interface. In this setup, it provides persistent connectivity, routing, and centralized control for multiple testers. It is commonly used when SSH is too limited for structured internal assessment work.
• Remote Access Trust Boundary: The remote access trust boundary is the set of devices, networks and session conditions that must be considered before identity is trusted. In practice, it expands the control problem beyond the login screen and forces teams to verify the user, the device and the context of each session.
• 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.
• 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.

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.