Where the Tunnel Begins: Threats a VPN Can Never See

A VPN starts working after your traffic has already been assembled by software on your device, which means every threat living on that device is inside the tunnel rather than outside it. Malware, a hostile browser extension, a keylogger, a family member with your unlocked laptop: all of them operate at a point the tunnel does not cover. The encryption protects your traffic from the network. It has nothing to say about where that traffic came from.

Once you see where the boundary sits, a whole class of confused expectations resolves itself.

Where the boundary actually is

Traffic on your machine passes through several stages before it reaches a cable or an antenna. Roughly: an application decides what to send, the operating system’s networking stack turns that into packets, routing rules decide which interface those packets take, and the interface transmits them.

A VPN client inserts itself near the end of that sequence. It creates a virtual network interface, tells the operating system to send traffic there, encrypts whatever arrives, and forwards it to the VPN server. Details vary by implementation and platform, but the position in the chain is the same everywhere: the VPN sees packets, not intentions.

So the content of those packets — which was decided by an application, using data the application had access to — is simply carried. If the application is malicious, or has been manipulated, the VPN carries the malicious traffic with exactly the same care as everything else. It is a courier, not an inspector.

The threats this leaves untouched

Malware and remote-access tools. Software that has execution on your machine can read files, capture keystrokes, screenshot your session, and open its own network connections. A tunnel neither prevents nor detects any of that, and in one narrow sense it helps the attacker: the traffic is now hidden from any network monitoring that might have flagged it.

Browser extensions. An extension with permission to read page contents sees your banking session after decryption, in plain form, in the browser. This is one of the most under-appreciated exposures in ordinary computing, and it sits entirely inside the tunnel.

Compromised or malicious applications. An app you installed that asks for broad permissions has them regardless of your network configuration.

Anyone with physical or remote access to the device. An unlocked machine, a shared account, or a remote support tool left installed operate before the network is involved at all.

Data at rest. Files on the disk are not affected by a VPN in either direction. Disk encryption is the tool for that, and it protects against a different event — the device being lost or seized.

Phishing and the user being persuaded. If you type your credentials into a convincing fake, the tunnel delivers them faithfully to the attacker. This is the most common real-world compromise and the one a VPN is least relevant to.

Why “VPN with built-in protection” features are a separate product

Many clients now bundle a blocklist that refuses connections to known-malicious or advertising domains, and some include something described as threat protection or malware scanning.

What those features actually are: a DNS or connection filter, and sometimes a file scanner, packaged with the VPN. They can be genuinely useful. But they are additional products sharing an installer, not the VPN doing the work, and it is worth evaluating them as such. A blocklist works by seeing your requests, which means the provider is inspecting the traffic you routed to it — a reasonable trade for a filtering service, and worth noticing given that the reason you installed a VPN was to reduce who observes your traffic.

What they do not do: stop an attacker who already has execution on your machine from doing anything it wants to do.

The one place a VPN genuinely interacts with device security

There is a real interaction, and it runs the other way: a VPN client is privileged software.

To do its job it needs to create network interfaces and modify routing rules, which on most systems requires elevated privileges and a component that keeps running. Some clients install a system service or kernel-level driver. This is normal and necessary, and it also means you are extending considerable trust to that software — more than you extend to an ordinary application.

That is not an argument against VPNs. It is an argument for taking the choice of provider seriously, since you are installing privileged code from them, and for preferring official distribution channels over repackaged installers found elsewhere. It also connects to the trust question this site keeps returning to: you are not only trusting the provider with your traffic, but with code on your machine. The evaluation methods in what a no-logs claim is worth apply here too.

What to actually do about device-side risk

The tools are unglamorous and unrelated to VPNs, which is exactly why they get skipped:

1. Keep the operating system and browser patched. Most successful attacks use known vulnerabilities, not new ones.
2. Audit your browser extensions. Remove anything you do not actively use, and be suspicious of anything requesting access to all sites.
3. Do not run as an administrator for daily work where the platform makes that practical.
4. Install software from official sources, especially anything privileged.
5. Use full-disk encryption and a strong device password, which addresses loss and theft rather than network observation.
6. Use a password manager and multi-factor authentication, which limit the damage when something does go wrong.
7. Treat a device you suspect is compromised as compromised — a VPN, a new password, or a reinstalled browser does not clear it.

The general lesson

A defence is only relevant if it sits between the attacker and the thing being attacked. The tunnel sits between your device and the network. That makes it useful against network-position adversaries, as what a VPN protects against sets out, and structurally irrelevant against anything already on your side of the boundary.

This is also why lists of features rarely help you decide. The question is not how many protections a client advertises, but where each of them sits in the chain — and whether the threat you actually have is on the other side of it. If you have not named that threat yet, build a threat model first.