Don't Use VPN Services: A Threat Model Teardown of the Consumer VPN Category

The conventional wisdom is compact and forceful. Use a VPN. Encrypt your traffic. Hide from your ISP. Escape surveillance. Every mainstream security blog since roughly 2015 has repeated some version of this instruction, and the consumer VPN market — NordVPN, ExpressVPN, Surfshark, ProtonVPN and the long tail behind them — has grown into an estimated USD 44 billion category by 2027 forecasts published across industry trackers. The argument sounds airtight. Encryption is real. ISPs do log. Public Wi-Fi is untrusted. The recommendation follows. And that is exactly where the analysis usually stops.

The problem is not that the recommendation is wrong. The problem is that it is answered before the question is asked. Nobody in the "use a VPN" thread ever states the adversary. Nobody names the capability. Nobody defines what data is being protected from whom. The recommendation floats above the threat model, decoupled from it, and that is a category error we would not accept from a security researcher writing about anything else.

This desk's position, on the record: the consumer VPN category, as a general recommendation, has never survived a threat-model audit. It survives because the audit is never performed in the venues where the recommendation is issued. What follows is that audit.

Why This Is Actually True

Concede the strongest form of the argument first. There is a specific, narrow, defensible threat model where a consumer VPN is the correct tool. It is worth stating precisely, because most of the argument for VPNs collapses into this narrow band and then quietly expands to cover situations the band was never meant to hold.

The band is this. Adversary: a passive network observer with visibility into the layer-2/layer-3 traffic between the user's endpoint and the first upstream hop. Capability: read unencrypted metadata, correlate DNS queries with destination IPs, log flow records. Data at risk: which domains the user contacts, when, and from which IP. This is your coffee shop Wi-Fi operator. This is your hotel captive portal. This is, in some jurisdictions, your residential ISP writing DNS query logs to a data broker under a lawful-basis carve-out.

Against that specific adversary, at that specific layer, a competently implemented WireGuard or OpenVPN tunnel does exactly what it advertises. The WireGuard whitepaper (Donenfeld, 2017) specifies ChaCha20-Poly1305 for authenticated encryption and Curve25519 for key exchange. The construction is sound, the code base is small — under 4,000 lines in the reference kernel implementation, versus OpenVPN's roughly 100,000 — and independent review, including the Cure53 audit of Mullvad's stack published in June 2020, has not surfaced protocol-level breaks. TLS 1.3 as specified in RFC 8446 provides the same guarantee for the control channel in OpenVPN-over-TLS deployments. Ciphertext is opaque to the local network observer. Metadata leakage to the coffee shop router shrinks to "the user contacted a VPN endpoint IP for N minutes." That is a real, measurable reduction in observable surface.

Concede further. In jurisdictions where the ISP is legally compelled to retain browsing metadata — the UK under the Investigatory Powers Act 2016, Australia under the Telecommunications (Interception and Access) Amendment (Data Retention) Act 2015 — routing traffic through a VPN endpoint outside that retention regime meaningfully changes what the domestic ISP records. The threat model is legal-metadata-retention by a specific ISP. The mitigation is protocol-appropriate. The math works.

Concede all of this without qualification. The steel-man deserves the concession.

But the threat model that makes a VPN correct is a rounding error compared to the threat model the marketing sells.

Where It Breaks Down

Here is the pivot. The conventional recommendation does not stop at "protects you from the coffee shop router." It expands, inside two paragraphs of any given consumer VPN homepage, into a global privacy claim: hide from surveillance, browse anonymously, defeat tracking, escape government monitoring. Each of those expansions attaches to a different threat model, and the VPN's architecture actively fails several of them.

Start with the trust-shift problem. A VPN does not eliminate the party that sees your unencrypted metadata. It replaces one party — your ISP or local network — with another: the VPN operator. The traffic that used to terminate at Comcast's DNS resolver now terminates at NordVPN's egress node. If your threat model is "I do not trust an entity to see my browsing metadata," you have not solved the problem. You have moved the observation point. Whether that is an improvement depends entirely on whether the new observer is more trustworthy than the old one — and "more trustworthy" is not a property you can verify from the outside. It is a claim.

The claim is usually backed by a "no-logs policy." No-logs is a marketing artifact, not an audit finding. When PwC audited ExpressVPN's no-logs claim (report published 2022-11), the scope was limited to server configuration snapshots at the time of the inspection and to interviews with staff about internal policy. The audit did not — could not — establish that no logs had ever been written, that no logs would be written after the auditors left, or that a server compelled by lawful process would not begin logging under a gag order. The Cure53 penetration test of ExpressVPN's Lightway stack, also 2022, found no critical protocol flaws — a genuinely strong result — but a clean protocol audit and a "no-logs" claim are entirely different assertions.

The 2019 NordVPN Finland-server breach is instructive. An attacker gained access to a Tampere-based server via an insecure remote management system belonging to the data center provider. NordVPN's disclosure clarified the scope. The larger point that the industry did not want to concede: your VPN provider's security posture is only as strong as its weakest colocation contract. You are not just trusting the provider. You are trusting every data center in every jurisdiction where they lease rack space, plus every upstream transit provider those data centers use.

Then jurisdiction. "Panama-based" or "British Virgin Islands-based" or "Swiss-based" reads well in marketing. In legal reality, the operative question is where the servers are physically located and which jurisdictions can compel logs from those servers under mutual legal assistance treaties. The CLOUD Act (2018) permits US authorities to compel data held by US-headquartered providers regardless of where the servers physically sit. The Budapest Convention on Cybercrime (2001) provides an expedited framework for cross-border data preservation orders across 68 signatory states. Switzerland is not in the 14-eyes framework, but Swiss servers are reachable through Schengen mutual assistance channels and through the same colocation-provider legal exposure that any commercial server faces. "Located in a privacy-friendly jurisdiction" is a statement about the corporate letterhead. It is not a statement about your traffic.

And endpoint compromise defeats all of it. If your browser is fingerprinted through canvas rendering, WebGL parameters, font enumeration and TLS ClientHello signatures — as it is by every serious ad-tech and fraud-detection vendor — your VPN's egress IP is not the identifier being tracked. You are the identifier. The VPN changes one axis of a multi-axis correlation and leaves the other axes untouched.

The Rule I Use Instead

Here is the framework this desk applies before recommending any VPN, to any reader, for any purpose. It has four steps and none of them are "which provider has the best speed test."

Step one. Name the adversary. Not "hackers." Not "surveillance." A specific class of observer with a specific capability. Passive local network monitor. Logging-mandated domestic ISP. Advertising fingerprinter. Nation-state signals intelligence. Law-enforcement subpoena under a specific legal framework. Contractual data broker under a specific privacy regime. Different adversaries, different tools.

Step two. Name the data. Metadata (which domains, when, from which IP) is different from content (what was said). Identity correlation (linking pseudonymous account A to real-world identity B) is different from location (where the user physically was when they made the request). A VPN affects some of these variables and not others. Being explicit about which one matters is the entire game.

Step three. Ask what a VPN would actually change against that adversary, for that data, under that legal framework. Sometimes the honest answer is "quite a lot" — the coffee shop case, the domestic-ISP-retention case. Sometimes the honest answer is "the VPN moves the observation point without eliminating it, and the new observer is not obviously more trustworthy than the old one" — most residential broadband threat models in jurisdictions without mandatory retention. Sometimes the honest answer is "the VPN is irrelevant because the compromise is at the endpoint or the application layer" — most ad-tech, most malware, most account-takeover scenarios.

Step four. If the answer to step three is "the VPN meaningfully changes the observable surface for this adversary and this data," then and only then evaluate providers on architecture, audit history, jurisdiction of servers (not headquarters), protocol choice, and public breach record. This is where names like ProtonVPN, Mullvad and IVPN enter the picture — providers whose transparency posture is closer to defensible than the broad consumer market — and where cheap "unlimited devices" pitches drop out.

The rule, compressed to one sentence: a VPN is a routing decision, not a privacy product, and it should be evaluated against a named threat model or not deployed at all.

When the Old Rule Still Wins

The concession this framework demands. There are two cases where "just use a VPN" is defensible advice even without the threat-model work above, and they need to be stated because refusing to state them would be the same intellectual dishonesty this desk criticized at the top.

Case one. A non-technical user on hostile public Wi-Fi, actively logging into accounts, in a country where local network operators are known to inject content, harvest sessions, or mirror traffic. In that setting, the trust shift from "hotel captive portal" to "commercial VPN operator with a Cure53 audit and a public breach record" is a defensible net-positive. The user is not going to perform a threat model. Blanket advice is the operative choice.

Case two. A user in a jurisdiction with mandatory ISP retention where the domestic legal framework is the specific concern — the UK IPA 2016 case, the Australian TIA-DR case — and where routing to a provider outside that retention regime measurably changes what the domestic regulator can compel. The framework works because the adversary is unusually well-defined by statute.

Outside those two bands, the burden of proof sits with the recommendation, not the reader. And that is where this desk's position stops.

We would revise the position if a large-scale independent audit — comparable in scope to the Chrome Root Store's compliance program, published on a recurring cadence, with jurisdiction of every server disclosed and every colocation contract listed — became standard practice across the consumer VPN category. Until such a program exists, the trust shift is unverifiable, and the recommendation cannot be issued as a general one.

FAQ

Does a VPN make me anonymous online?

No. Anonymity is a property of a system, not a routing hop. A VPN changes your egress IP, which is one variable in a multi-variable identity correlation. Browser fingerprinting, canvas rendering, TLS ClientHello signatures, account cookies, and payment identifiers remain untouched. Tor, combined with a hardened browser, gets closer to anonymity than any VPN; even that is not absolute. Marketing language that uses "anonymous browsing" for VPN service is an overclaim and this desk treats it as such.

Is a no-logs policy the same as a no-logs audit?

No, and the distinction is where most of the industry's marketing shortcuts live. A policy is a written statement of intent. An audit is a third-party inspection with a defined scope. The PwC and KPMG-scoped no-logs reviews published for major providers between 2019 and 2023 examined server configurations at a moment in time and interviewed staff about internal practice. They did not — and could not — prove no logs had ever been written, or that a compelled server would not begin logging under a lawful order.

Does using a VPN protect me from my ISP's data retention obligations?

Partially, and only against the domestic ISP itself. Traffic between your device and the VPN egress node is opaque to your ISP; the ISP sees connections to the VPN endpoint IP and nothing more granular. The VPN provider, however, now occupies the observation point your ISP used to hold. In jurisdictions with statutory ISP retention — the UK under the Investigatory Powers Act 2016, Australia under the 2015 TIA-DR amendment — this trade is defensible if the VPN's jurisdiction and audit posture are stronger than the domestic ISP's.

Are WireGuard-based VPNs meaningfully more secure than OpenVPN ones?

"More secure" is the wrong axis. WireGuard has a smaller code base (under 4,000 lines in the reference implementation versus OpenVPN's roughly 100,000), a modern cryptographic suite (ChaCha20-Poly1305, Curve25519), and a smaller audit surface. That makes review tractable. OpenVPN-over-TLS 1.3 (per RFC 8446) is not broken; it is older and more complex. For most consumer threat models the practical difference is negligible. The bigger variable is provider implementation quality, not the protocol choice itself.

Should I trust a VPN based in Switzerland or Panama more than one in the US?

Not on the basis of the corporate letterhead alone. Servers physically located in a jurisdiction are subject to that jurisdiction's compulsion process regardless of where the parent company is registered. The CLOUD Act (2018) extends US legal reach to data held by US-headquartered providers globally. The Budapest Convention on Cybercrime (2001) provides expedited cross-border data preservation across 68 signatory states. Ask instead where the specific server you are routing through physically sits, and what colocation contract governs it.

Does a VPN protect against browser fingerprinting or ad-tech tracking?

No. Fingerprinting operates at the application layer using signals — canvas rendering, font enumeration, WebGL parameters, screen resolution, installed extensions — that the VPN does not touch. The VPN masks your source IP, one of dozens of correlatable variables. Browser hardening, container isolation, and tracker-blocking extensions address this problem. A VPN does not. Conflating IP masking with tracking protection is the single most common category error in consumer VPN marketing.

What is the correct baseline behaviour without a VPN?

For most users in most residential settings: HTTPS-everywhere enforcement, encrypted DNS (DNS-over-HTTPS per RFC 8484 or DNS-over-TLS per RFC 7858), browser hardening, and endpoint patching. That stack addresses more real-world threat surface for the median user than a consumer VPN does, and it does not shift trust to an unaudited third party. Reserve the VPN for named threat models — hostile local networks, mandated-retention jurisdictions, or specific traffic that needs to egress from a different geography.