No-Log VPN Claims: How to Actually Verify Them

A VPN provider’s privacy policy is a marketing document before it is a legal one. The phrase “we do not log your activity” appears in dozens of provider policies, but the technical architecture behind those words varies enormously — from genuinely ephemeral RAM-only infrastructure to standard disk-based servers where deletion happens on a schedule rather than by design.

Verifying a no-log claim is not straightforward, and the honest answer is that most users cannot do it independently. What users can do is evaluate the available evidence systematically, understand which verification methods carry real weight, and recognize the specific failure modes that have exposed logging providers in the past.

What “No Logs” Actually Means — and Doesn’t Mean

The term “no logs” is not standardized. Some providers mean they don’t log browsing destinations or connection content. Others mean they retain connection timestamps and bandwidth figures but not URLs. A smaller number claim to retain nothing at all — no IP addresses, no session durations, no DNS queries. These are fundamentally different privacy postures, and a policy document rarely makes the distinction explicit without careful reading.

Metadata logging is the area most commonly glossed over. A provider can truthfully claim it does not log your traffic while still recording when you connected, for how long, and how much data you transferred. That metadata, particularly the connection timestamp paired with your account credentials, is often enough to correlate your identity with online activity when combined with external data sources. The 2011 HideMyAss case illustrated this precisely: the provider handed over connection logs to UK authorities that linked a LulzSec member’s real IP address to his VPN session, despite the company’s privacy claims at the time.

Jurisdiction matters here too, though not in the simple way it is often presented. A provider incorporated in the British Virgin Islands still faces legal pressure if its infrastructure runs on servers in the United States or EU member states. Infrastructure jurisdiction and corporate jurisdiction are separate questions, and no-log claims that ignore the former are incomplete.

The Verification Methods That Actually Carry Weight

Independent Audits

Third-party audits are the most widely cited verification mechanism, but their value depends heavily on scope and auditor independence. Cure53, a German penetration testing firm, has conducted audits for Mullvad and ProtonVPN, publishing the full findings including identified issues. KPMG audited ExpressVPN in 2022. The key questions to ask about any audit: Was the auditor given access to live production infrastructure or only documentation? Was the report published in full, or just a summary? How long ago was it conducted, and has the infrastructure changed since?

An audit that only reviews the privacy policy and interview statements is worth considerably less than one that inspects server configurations, running processes, and actual log file paths. The difference is between auditing a claim and auditing the system making the claim. Some providers have allowed auditors to SSH into production servers and verify that no logging daemons were running — that is a meaningfully stronger test than a document review.

Audits are also point-in-time assessments. A clean audit result from 18 months ago says nothing about the current state of the infrastructure. Providers who conduct annual or recurring audits provide better signal than those who have published a single report and treated it as permanent validation.

Warrant Canaries and Transparency Reports

A warrant canary is a statement, regularly updated, that a provider has not received any undisclosed government requests for user data. When the statement disappears or stops being updated, it signals — without the provider explicitly saying so — that a secret legal order may have arrived. The mechanism is based on the legal distinction between compelled disclosure and voluntary silence.

Warrant canaries are imperfect. They can be dropped for reasons unrelated to legal orders. They do not work in jurisdictions where even the act of removing a canary can be legally restricted. And a provider under a gag order may simply be prohibited from acting on the canary at all. Still, their presence is a meaningful signal about a provider’s stated commitment to transparency, and their absence from a provider that previously maintained one is worth investigating.

The most unambiguous evidence of a no-log policy comes from law enforcement requests where user data was sought and none was available to produce. ExpressVPN was subpoenaed in relation to a 2017 Turkish investigation into the assassination of the Russian ambassador Andrei Karlov. Turkish authorities seized an ExpressVPN server and found no relevant data. Mullvad received a police search of its offices in 2023 — Swedish authorities arrived with equipment expecting to seize user data and left with nothing, because no session logs existed to take.

These incidents are not marketing — they are documented legal outcomes. They are also rare. Most providers have never faced this kind of test, which means their no-log claims remain untested by adversarial circumstance.

Technical Architecture as Evidence

RAM-Only Servers

Some providers have moved their infrastructure to diskless, RAM-only servers. Because RAM requires continuous power to retain data, a reboot or power cycle permanently erases everything stored on the machine. Mullvad, ExpressVPN (through its Lightway infrastructure), and ProtonVPN have all announced full or partial deployment of RAM-only servers. This architecture makes persistent logging technically difficult by default — you cannot write logs to a disk that doesn’t exist.

The caveat is that logs can still be written to RAM and transmitted off-machine to a logging server before the session ends. RAM-only servers reduce the risk of forensic recovery from seized hardware, but they don’t make logging architecturally impossible. They’re a meaningful technical control, not an absolute guarantee.

Open-Source Clients and Server Software

A VPN client that runs on your machine has access to your DNS queries, connection metadata, and traffic before it is encrypted. An open-source client can be inspected to verify it isn’t sending telemetry back to provider servers beyond what’s necessary to maintain the VPN tunnel. Mullvad’s desktop and mobile clients are fully open-source and available on GitHub. ProtonVPN’s clients are also open-source across all platforms.

Open-source server software is rarer and harder to verify independently, since users can’t confirm that the version running on production servers matches the published source code. This is a genuine gap in the verification chain that audits partially address.

Putting the Evidence Together

No single verification method is sufficient on its own. A useful evaluation framework combines at least three signals: a published, full-scope technical audit from a named firm conducted within the past 18 months; documented evidence of a legal request where no usable data was produced; and a technical architecture (RAM-only servers, open-source clients) that reduces the structural opportunity for logging.

Providers who score on all three are a short list. Mullvad and ProtonVPN come closest to meeting all criteria as of 2024, though both have areas where independent verification remains incomplete. The majority of commercial VPN providers have one or none of these signals — a privacy policy and a marketing claim standing in for evidence.

The most honest framing is that no-log verification is probabilistic, not absolute. What users are evaluating is the cost and difficulty of a provider betraying its stated policy, combined with the track record of what happened when that policy was tested. The Mullvad 2023 police visit remains the clearest real-world data point: investigators expected to find logs, found nothing, and left.