VPNs are one of the most recommended security tools in existence — and one of the most misunderstood. Ask most people what a VPN does, and you'll hear some version of "it makes you safe online." That's not wrong, exactly. It's just dangerously incomplete.

A VPN creates a point-to-point encrypted tunnel between your device and a VPN server, authenticating the caller and transferring data securely across untrusted networks [2]. That tunnel is genuinely valuable. But it solves a specific, narrow problem: protecting data in transit. It doesn't protect data sitting on a compromised device. It doesn't stop you from clicking a phishing link. And it certainly doesn't make you invisible.

The security industry itself is signaling the limits of VPNs. Microsoft's Zero Trust model explicitly moves away from the assumption that everything behind a corporate firewall is secure [6]. Major vendors are actively building replacements. That shift tells you something important: VPNs aren't broken, but the threat model they were designed for has changed.

This article is a practical guide to what falls inside the VPN's protection boundary — and what falls outside it.

What VPNs Actually Protect: The Encrypted Tunnel Explained

At its core, a VPN uses tunneling protocols to make a virtual call to a virtual port on a VPN server [2]. That tunnel encrypts all data flowing between your device and the server, preventing anyone sitting between those two points from reading your traffic.

The Windows built-in VPN client supports four tunneling protocols: IKEv2, L2TP, PPTP, and SSTP. When set to "Automatic," the client cycles through protocols from most secure to least secure until a connection succeeds [2]. IKEv2 is the strongest of the four — it supports configurable IPsec/IKE cryptographic suites and is the only protocol that supports LockDown VPN, a feature that blocks all outbound network traffic the moment the VPN connection drops [1]. For organizations that need federal-level guidance on configuring these protocols securely, NIST SP 800-77 Rev. 1 covers IPsec VPN planning, implementation, key management, and security architecture for both site-to-site and remote access deployments [10].

The real-world value of this tunnel is easy to grasp. You're at an airport, connecting to public Wi-Fi. Without a VPN, an attacker on that same network can potentially intercept your traffic — login credentials, email contents, file transfers, all of it. With a VPN, that traffic is encrypted inside the tunnel before it ever leaves your device. The attacker sees nothing but encrypted gibberish.

This protection matters whenever you don't control the network: hotel Wi-Fi, coffee shops, conference centers, or any environment where you can't verify who else is connected. It matters equally for remote workers accessing corporate resources from home networks that may lack enterprise-grade security controls.

LockDown VPN takes this a step further. When configured, the system always attempts to keep the VPN connected, the user cannot disconnect or modify the profile, it uses forced tunnel connection, and if the VPN is unavailable, all outbound network traffic is blocked [1]. The device simply refuses to send unprotected traffic. For high-security environments, that guarantee is significant.

Force Tunnel vs. Split Tunnel: The Tradeoff Most Users Don't Know About

There's a single configuration choice that dramatically changes what your VPN actually protects — and most users have no idea which setting they're using.

Force tunnel routes all of your internet traffic through the VPN and into the corporate network. Every website you visit, every streaming service you use, every personal email you send — it all flows through the encrypted tunnel and through your organization's network infrastructure. IT teams get maximum visibility and security control, but at the cost of higher bandwidth consumption and added latency.

Split tunnel takes a different approach: only corporate-bound traffic flows through the VPN. When split tunneling is enabled, traffic to destinations outside the intranet bypasses the VPN tunnel entirely [8]. Your personal browsing, streaming, and other non-corporate traffic goes directly to the internet. Performance improves, but that personal traffic loses the protection of corporate security controls.

The implications are significant. With split tunneling, your organization's security stack — firewalls, intrusion detection, content filtering — only sees the traffic you send to corporate resources. Everything else is invisible to those controls.

Most consumer VPN services use force tunnel by default, which is why they can advertise that "all your traffic is protected." Many enterprise deployments, however, use split tunnel for performance reasons. If you're an employee on a corporate VPN, you should know which mode you're operating in. The Always On VPN device tunnel, for example, must be configured as split tunnel — force tunnel is not supported for device tunnels [3].

Then there's the problem of DNS leaks. In a split-tunnel configuration, DNS queries for non-corporate destinations may travel outside the tunnel, exposing which websites you're visiting even when corporate traffic is properly encrypted.

What VPNs Do NOT Protect Against

This is the section that matters most, because this is where the gap between expectation and reality is widest.

Endpoint compromise. If malware is already on your device, the VPN encrypts that malicious traffic just as faithfully as it encrypts your legitimate traffic. A keylogger, a remote access trojan, a credential stealer — their communications all flow through the tunnel without issue. The VPN has no mechanism to inspect what's inside the packets it encrypts. It's a pipe, and it doesn't care what flows through it.

Phishing and social engineering. A VPN can't stop you from entering your credentials on a fake login page. It can't prevent you from clicking a link in a convincing email that installs malware. These are application-layer attacks that operate entirely above the network layer where VPNs work. The tunnel is irrelevant because the user is the vulnerability.

Lateral movement inside the network. This is the problem that gave rise to Zero Trust. A traditional VPN grants access to the corporate network, and once inside that perimeter, a compromised device can potentially reach other resources. The VPN created a trusted boundary, but everything inside that boundary was assumed safe — an assumption that modern attackers exploit routinely.

Application-layer vulnerabilities. SQL injection, cross-site scripting, insecure API endpoints — these attacks target the application itself, not the network transport. A VPN encrypts the connection between you and the server, but it has no say in what your application does with the data once it arrives.

VPN Traffic Filters can provide some mitigation here. Organizations can define app-based rules that restrict VPN traffic to specific applications, or traffic-based 5-tuple rules that specify allowed ports, addresses, and protocols [1]. But these are policy controls on what enters the tunnel — not endpoint security. They control access, not behavior.

Anonymity. A VPN does not make you anonymous. Your VPN provider can see your traffic. Your activity remains trackable through cookies, browser fingerprinting, and account logins. Changing your IP address is not the same as becoming invisible.

Layered Defense: VPN Plus Conditional Access and Identity Controls

If VPNs only secure the tunnel, how do organizations secure everything else? The answer is layering additional controls on top.

VPN authentication alone verifies that a user has valid credentials to establish the tunnel. It doesn't evaluate whether the connecting device is compromised, whether the user's account shows signs of breach, or whether the application being accessed should even be available from that context.

Microsoft Entra Conditional Access addresses this gap. It functions as a Zero Trust policy engine, combining signals from user identity, IP location, device state, application context, and real-time risk detection to make access control decisions [5]. Where a VPN asks "do you have the right key?", Conditional Access asks a harder question: "should you be allowed in right now, given everything we know about this request?"

Conditional Access policies are enforced after first-factor authentication and can require additional verification steps: multi-factor authentication, device compliance checks, and Named Location verification — all before the VPN tunnel is even established [5] [6]. A user connecting from an unmanaged device, from an unusual location, or with an account showing risk signals can be blocked or challenged, even if their VPN credentials are perfectly valid.

Always On VPN supports advanced authentication methods that raise the bar further: machine certificate authentication for IKEv2, RADIUS authentication via NPS, and Protected EAP with smart card or certificate-based authentication [4]. These are meaningful improvements, but they still only secure the tunnel entrance.

The key insight is this: VPN secures the pipe; Conditional Access secures the door. You need both. A strong tunnel with weak identity controls is a locked highway with an open on-ramp. Strong identity controls without tunnel encryption leave data exposed in transit.

The Shift to Zero Trust: Why Microsoft Is Moving Beyond VPNs

The industry isn't abandoning VPNs because they failed. It's moving beyond them because the threat landscape changed.

Microsoft's Zero Trust model states it directly: instead of assuming everything behind the corporate firewall is secure, verify each request as if it originates from an uncontrolled network [6]. This is a fundamental inversion of the VPN model. VPNs draw a perimeter and trust everything inside it. Zero Trust trusts nothing and verifies everything.

Zero Trust Network Access replaces broad VPN tunnels with fine-grained, identity-aware, per-application connections. Microsoft's Global Secure Access, for example, swaps full network tunnels for app-specific, identity-driven connections that require no inbound firewall rules [6]. Instead of granting access to an entire network, ZTNA grants access to a specific application, for a specific user, based on a specific set of conditions.

The three Zero Trust principles driving this shift are: verify explicitly — authenticate and authorize based on all available data points; use least-privileged access — limit user access with just-in-time and just-enough-access policies; and assume breach — minimize blast radius, segment access, and verify end-to-end encryption for all sessions [6].

None of this means VPNs are useless. It means they were designed for a 1990s problem — secure the perimeter — while modern threats demand a fundamentally different model: secure every request. Organizations with legacy infrastructure will continue using VPNs for years. But the direction is clear, and treating the VPN as the final answer to network security grows more untenable by the day.

Conclusion: Use VPNs for What They Are, Not What You Wish They Were

A VPN protects the tunnel between your device and the server. On untrusted networks, that protection is genuinely valuable — it's the difference between broadcasting your traffic in the clear and encrypting it end to end.

But a VPN doesn't protect against compromised endpoints, phishing, lateral movement, or application-layer attacks. It doesn't make you anonymous. It doesn't inspect what flows through the pipe.

Know whether you're using split tunnel or force tunnel, because that single setting changes what traffic is actually protected. For enterprise environments, pair VPN with Conditional Access, endpoint protection, and a clear roadmap toward Zero Trust. For personal use, understand that a VPN protects your connection to the internet — not your behavior on it.

A VPN is a lock on the front door. Essential, but insufficient if someone is already inside the house.