VPNs Still Encrypt Traffic—but the Tunnel No Longer Proves Trust

VPNs still protect traffic as it crosses an untrusted network, but enterprise security no longer treats admission to an encrypted tunnel as sufficient proof that a user or device should reach everything behind it. The important change is not the disappearance of the VPN: it is the separation of transport protection from trust and authorization.

That distinction corrects two persistent misconceptions. The early history was more complicated than one Microsoft employee inventing PPTP in 1996, while today’s alternative is not simply “VPN off, zero trust on.” VPN tunnels remain useful, but organizations increasingly place identity, device condition and resource-specific policy around them—or use those controls to avoid broad network access altogether.

The early VPN solved a connectivity problem

The historical Point-to-Point Tunneling Protocol belonged to an internet built around dial access, private corporate networks and sharply defined boundaries. It carried Point-to-Point Protocol traffic through an IP network, allowing geographically separated systems to behave as though a private link connected them.

The primary record is more precise than the familiar origin story. IETF RFC 2637, published as an informational document in July 1999, identifies six authors from several companies and says PPTP was developed by a vendor consortium. It also describes PPTP as a tunnelling vehicle rather than an internet standard and warns that an unprotected PPP payload could be captured, read or modified.

This matters because a tunnel and encryption are related but separate ideas. A tunnelling protocol determines how traffic is encapsulated and transported; authentication and cryptographic protection must still be supplied by the surrounding configuration. Calling every VPN connection “highly secure” therefore skips the questions that determine its actual security: which protocol is used, how keys and users are authenticated, what traffic enters the tunnel, and what the connected endpoint may access.

The protocols changed, but legacy configurations persist

VPN did not remain synonymous with PPTP. Modern deployments can use protocols and implementations built around stronger cryptography, better key exchange and support for mobile devices, while consumer applications have made encrypted tunnels available on phones, tablets and home routers. Yet an old configuration does not become safe merely because the server or operating system has been upgraded.

Microsoft’s current server guidance provides a concrete example of that transition. Windows Server VPN protocol documentation says new Windows Server 2025 RRAS setups do not accept PPTP- or L2TP-based connections by default, while SSTP and IKEv2 remain accepted. Existing configurations can retain their previous behaviour after an in-place upgrade, and Microsoft does not recommend PPTP or L2TP because they lack security features.

The consequence for administrators is straightforward: the product version alone does not reveal the effective security posture. Protocols, enabled ports, authentication methods and inherited settings need to be inspected after an upgrade. Compatibility switches that keep a legacy client working can also preserve the weakness the newer default was designed to avoid.

Personal and enterprise VPNs now answer different questions

A personal VPN usually changes the path between a device and a provider-operated exit server. It can conceal traffic from the local Wi-Fi operator, replace the public IP address seen by destinations and protect data on the segment between the device and VPN endpoint. It does not make a malicious site trustworthy, remove tracking performed through accounts or browser storage, or protect traffic after it leaves the provider’s server.

Using one also transfers part of the trust relationship. Instead of the local network or internet provider seeing the original connection metadata, the VPN operator occupies a privileged position in the route. Readers choosing such a service should therefore examine who operates it, what data it says it retains, how its applications are updated and whether the required device supports a reliable method of preventing accidental traffic outside the tunnel.

An enterprise VPN has a different job: connecting an employee, contractor, branch or managed device to organizational resources. Encryption remains important, but the central risk is what happens after the connection is accepted. A broadly routed tunnel can expose more of the internal network than a person needs for one application, increasing the value of stolen credentials or a compromised endpoint.

Modern access policy no longer trusts network location

Zero trust changes the unit of the decision. Instead of assuming that a device inside a private address range is trustworthy, the system evaluates access to a particular resource using information about the user, device and request. That decision can be revisited when the session, device condition or risk signals change.

NIST’s Zero Trust Architecture states that physical or network location and asset ownership do not create implicit trust. It places authentication and authorization of both the subject and device before a session to an enterprise resource, shifting attention from protecting network segments to protecting resources.

This does not prohibit VPNs. A tunnel can still secure traffic between an approved endpoint and a gateway, connect two sites, carry protocols that cannot safely face the public internet or provide a controlled route for administrative work. The mistake is allowing successful tunnel authentication to become a blanket authorization for unrelated systems.

In practice, a narrower model may combine several controls:

• strong user authentication that is resistant to simple password theft;
• device identity and checks for required security posture;
• least-privilege access to named applications or limited network segments;
• central logs that connect authentication, device and resource activity;
• prompt patching and retirement of exposed gateways and unsupported protocols.

What a VPN decision should establish now

The first question is no longer “Do we have a VPN?” but “Which problem must this connection solve?” Protecting traffic on public Wi-Fi, linking two offices, reaching a legacy file server and granting a contractor access to one web application are different requirements. They can justify different protocols, routes and authorization boundaries.

For an existing enterprise deployment, inventory the gateways, client software and protocols before comparing replacements. Determine whether users receive access to an entire subnet or only required services, whether unmanaged devices can connect, what happens when posture checks fail, and whether a compromised account can move laterally. A migration that preserves the same broad permissions behind a newer label has not delivered the central benefit of identity-aware access.

For personal use, judge the VPN by the narrower promise it can actually keep: protecting a segment of the network path and changing the visible exit address. Continue to use encrypted websites, software updates, strong account authentication and browser privacy controls, because the tunnel does not replace any of them.

The durable idea from the early VPN era is private transport over shared infrastructure. What changed is the security conclusion drawn from that transport. An encrypted route remains valuable; entry into it is no longer a sufficient reason to trust the person, the device or every action taken at the other end.

Also read:

• VLMs Can Already Hunt for the “Interesting.” But They’re Still Bad at Walking Away from What They’ve Found
• Not Microdramas, But TikTok Dramas: The Platform Is Now Actively Producing Its Own Mini-Series
• The Empire is Changing Face: But It's Still an Empire - And the Role of DOGE