VPNs solve privacy, but not the identity trust problem

At a glance

What this is: This is a primer on what VPNs do, how common tunnelling protocols work, and where their privacy and security limits begin.

Why it matters: It matters because VPNs often sit inside access programmes that also govern human IAM, privileged access, and remote connectivity, so teams need to understand what they do not solve.

👉 Read DigiCert's guide to VPNs, protocols, and privacy trade-offs

Context

A VPN is a private tunnel over a public network, but the security value depends on what is protected outside the tunnel as much as inside it. The article explains encryption, IP masking, and protocol choice, while also acknowledging that browsing history, cookies, and site-side tracking can still expose user activity.

For identity and access teams, the key issue is that VPNs are a transport control, not an identity governance model. They can support remote access, but they do not replace authentication, device trust, privileged access controls, or policy decisions about who should reach what from where.

Key questions

Q: How should security teams govern VPN access in a zero-trust model?

A: Security teams should treat VPNs as one transport control inside a broader zero-trust design, not as the trust decision itself. Access should still depend on identity verification, device posture, least privilege, and continuous session evaluation. A VPN can encrypt traffic, but it should not grant broad network access by default or bypass application-level policy checks.

Q: When does VPN use create more risk than it reduces?

A: VPN use creates more risk when it becomes a shortcut to broad internal access, especially for users, contractors, or admins who do not need full network reach. It also becomes risky when legacy protocols remain in place, when device posture is unknown, or when teams assume the tunnel itself proves trust. That is a governance failure, not just a technology issue.

Q: What do security teams get wrong about VPN privacy?

A: Teams often overstate what VPN privacy actually delivers. A VPN can hide the source IP and encrypt traffic in transit, but it does not erase browser history, stop site tracking, or make the user anonymous across all layers. If policy, legal, and user guidance do not reflect that distinction, the organisation creates false confidence about privacy and safety.

Q: How should organisations decide between VPNs and application-level access controls?

A: Organisations should prefer application-level access controls when the goal is to limit who can reach specific resources without exposing the whole network. VPNs can still have a role for legacy systems or secure transport, but they should not be the only control. The best design is usually narrow access, strong identity checks, and minimal network exposure.

Technical breakdown

How VPN tunnelling masks network origin

A VPN creates an encrypted tunnel between the user device and the VPN server. To external resources, the connection appears to come from the server's IP address rather than the end device. That hides location and network origin, but it does not authenticate the user by itself or prove the endpoint is safe. The protection is about transit confidentiality and address substitution, not full access assurance. Practical implication: treat VPN presence as a transport layer control, then pair it with strong identity, device posture, and session controls.

Practical implication: require separate identity and device checks before granting access.

VPN protocols and security trade-offs

The article contrasts PPTP, L2TP, and OpenVPN. PPTP is older and uses weaker encryption, while L2TP is described as using stronger keys and OpenVPN is presented as a widely used open-source option whose code transparency helps expose weaknesses. The broader lesson is that protocol choice changes the security envelope, but only within the limits of the overall remote access design. A stronger protocol does not fix poor endpoint hygiene, weak credentials, or overbroad access entitlements. Practical implication: standardise on modern protocols and treat legacy tunnelling as a deprecation risk.

Practical implication: retire weak VPN protocols and align remote access standards across the estate.

Why VPN privacy is incomplete

VPNs can conceal IP addresses and encrypt traffic, but they do not make a user anonymous in the full sense. Browser histories remain, websites can still track sessions, and service providers may still infer VPN usage. That means the privacy promise is partial and context dependent. For IAM and security teams, this matters because access assurance often gets overstated when a VPN is treated as a substitute for identity assurance. Practical implication: do not let VPN adoption become a proxy for trusted user state.

Practical implication: separate network privacy from identity assurance in policy and user communications.

NHI Mgmt Group analysis

VPNs are a transport control, not an identity control. The article correctly describes encrypted tunnelling and IP masking, but those properties do not answer the harder governance question of who should have access under what conditions. That distinction matters because identity programmes still need authentication, device trust, least privilege, and revocation discipline. A VPN may reduce exposure on the wire, but it does not govern entitlement. Practitioner conclusion: remote access architecture should be evaluated as part of the identity stack, not as a substitute for it.

Remote access architectures often overstate the trust signal they create. A VPN connection can look reassuring because traffic is encrypted and the source IP changes, yet the endpoint, browser, and application layers can still leak identity and activity. This is the same governance mistake seen when organisations treat network location as a proxy for trust. The implication is that access policy should be driven by identity, device posture, and session context, not by tunnel presence alone.

Legacy tunnelling protocols create security debt that looks invisible until an incident. The article's discussion of PPTP versus L2TP versus OpenVPN shows that protocol choice still matters, especially where older deployments remain in place for convenience. Weak protocol defaults do not simply reduce encryption strength. They also normalise outdated remote access assumptions that are hard to unwind later. Practitioner conclusion: inventory protocol versions as part of access governance, not only as a network hygiene task.

Identity programmes need to distinguish privacy from assurance. VPNs can help users browse more privately, but privacy and trusted access are not the same control objective. If a programme blurs those two, it risks allowing users, administrators, and auditors to assume that the connection itself proves safety. It does not. Practitioner conclusion: document VPNs as one layer in a broader access model and set expectations accordingly.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why VPN-centric thinking cannot substitute for identity governance.
• For a broader control baseline, read Ultimate Guide to NHIs , Key Challenges and Risks for the governance gaps that create persistent identity exposure.

What this signals

Identity teams should stop treating VPN adoption as a proxy for trust. The operational signal is not whether users connect through an encrypted tunnel, but whether remote access decisions are still tied to identity, device, and session context. That shift matters across human IAM, privileged access, and contractor access alike.

The governance gap becomes obvious when organisations assume network privacy equals access safety. In practice, the more reliable control pattern is narrow application reach, explicit authentication, and auditable entitlement decisions, supported by references such as NIST SP 800-207 Zero Trust Architecture.

Remote access programmes need a named concept for this problem: tunnel trust debt. It describes the accumulated risk that builds when VPN presence is mistaken for trust, even though the endpoint, browser, and application layers still decide the real exposure boundary. Teams should use that concept to challenge legacy remote access exceptions.

For practitioners

• Classify VPNs as a transport layer control Document VPNs in your access architecture as encrypted transit, not as proof of user or device trust. Tie access decisions to identity verification, endpoint posture, and policy enforcement at the application layer.
• Retire weak or legacy tunnelling protocols Inventory PPTP and any similar legacy configurations, then create a deprecation path to modern protocols with stronger cryptography and supportability. Make protocol review part of access governance and network hardening cycles.
• Separate privacy claims from security guarantees Update user guidance so VPN communications explain what is protected in transit and what still remains visible through browser history, cookies, and application logs. That prevents false confidence from spreading into operational decisions.
• Review remote access trust assumptions regularly Check whether VPN access is being used as a shortcut for privileged access approval, exception handling, or broad network reach. If it is, tighten the policy so the tunnel does not become an entitlement in itself.

Key takeaways

• VPNs improve transit privacy, but they do not replace identity assurance, device trust, or application-level access control.
• Older tunnelling choices and broad network access can turn remote connectivity into a governance weakness rather than a protection.
• Identity teams should treat VPNs as one layer in a zero-trust access model, not as evidence that access has been safely validated.

Key terms

• Virtual Private Network: A Virtual Private Network is an encrypted tunnel that carries traffic across a public network while masking the user's source IP address. It improves transit privacy and can help secure remote access, but it does not by itself prove the user is trusted or the device is safe.
• Transport Layer Control: A transport layer control protects how data moves between endpoints rather than deciding who should access a system. VPNs are a common example. In identity programmes, transport controls must be paired with authentication, device checks, and policy enforcement to create meaningful access assurance.
• Zero Trust Architecture: Zero Trust Architecture is a security model that treats network location as insufficient evidence of trust. Access decisions are made continuously using identity, device, context, and policy rather than relying on a connected network or private tunnel as the primary signal.

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.

This post draws on content published by DigiCert: What is a VPN? Read the original.