Mullvad's account number model — no email, no username, just a 16-digit string handed to you at signup — is routinely framed as the most privacy-respecting account architecture in the VPN market. It is genuinely useful. It is also not a substitute for a threat model, and read naively it will fail, quietly, against adversaries the architecture was never designed to resist.

Before you treat the account number as a privacy guarantee, understand what the guarantee actually is, and — more importantly — what it is not.

TL;DR

Red Flag #1: Payment Correlation Defeats Account Pseudonymity

What it looks like: you sign up with no email, receive a 16-digit account number, then pay with a personal credit card. The account number is pseudonymous. The payment is not.

Why it matters: the card issuer holds a merchant record tied to your legal identity. A subpoena to the issuer — not to Mullvad — produces a list of every customer who paid that merchant in a given window.

The provider does not need to log anything for this correlation to succeed. The correlation happens upstream of whatever no-logs architecture the VPN has. It is outside the provider's trust boundary entirely.

The account number model was designed to harden the provider's side of the fence. Card payments re-introduce an identified party on the other side. If your adversary has subpoena power over a major card issuer — civil litigants, domestic law enforcement, MLAT-authorized foreign agencies — account pseudonymity is cosmetic.

Red Flag #2: The Account Number Is a Single Point of Failure

What it looks like: sixteen digits. No email recovery. No second-factor authentication on the account itself, because 2FA requires a second channel and the whole point of the architecture is that no second channel exists.

Why it matters: the account number is both the username and the password. If it leaks — phishing, shoulder surfing, a stolen clipboard entry, a poorly redacted support screenshot — anyone holding it can authenticate as you and read your subscription state.

The traditional email-plus-password model has a recovery channel that is also an attack channel. Mullvad closed the attack channel by removing the recovery channel. This is a reasonable trade.

It also means you carry the full weight of credential hygiene alone, and the failure mode for losing the account number is terminal. There is nothing to reset to. You buy a new account.

Red Flag #3: Cash-by-Mail Has a Return Address Problem

What it looks like: an envelope of local currency mailed to a Swedish postal address with a handwritten token that gets associated with an account number on arrival. It is the most elegant payment option in the catalog.

Why it matters: the digital payment rail is removed from the correlation surface entirely. Three new correlation surfaces appear in its place.

First, the envelope itself. If you write a return address you are one postal inspection away from an identified sender. If you don't, carriers can refuse the parcel.

Second, postal scanning programs in the US and EU routinely capture exterior envelope metadata at scale — postmark, destination, weight, date. That metadata is not content, and therefore carries weaker legal protection than mail content in most jurisdictions.

Third, the handwriting. It is a biometric with nonzero evidentiary weight if anyone ever cares to look. Cash-by-mail is the strongest payment option in the catalog for most realistic threat models. It is not a cloak.

Red Flag #4: Crypto Is Pseudonymous, Not Unlinked

What it looks like: you pay in BTC or some other transparent-ledger cryptocurrency, congratulate yourself on "anonymous" payment, and move on.

Why it matters: transparent blockchains publish every transaction. Chain analysis firms sell subpoena-grade tooling that clusters addresses and correlates them to exchange KYC records. If the BTC you used to pay came out of a KYC-compliant exchange withdrawal, the correlation is mechanical and fast.

This is not a theoretical attack. It is the default capability of every tier-one chain analysis provider.

OK here is where it gets genuinely interesting — Monero is a different category entirely. Ring signatures, stealth addresses, and RingCT make on-chain correlation substantially harder than Bitcoin. "Substantially harder" is not "impossible," and the research literature on Monero traceability is genuinely active, but the cost curve is real.

Lightning Network payments sit somewhere in between, and the forensic story there is still being written. The account number model assumes the payment layer is clean. It is the user's job to make it so.

Red Flag #5: Device Fingerprints Cross the Tunnel

What it looks like: you route your browser through WireGuard, feel protected, and visit sites that read your TLS fingerprint (JA3/JA4), your canvas fingerprint, your installed font list, your WebGL identifiers, and your time zone.

Why it matters: the account number model hardens the link between you and the provider. It does nothing for the link between your browser and the destination server.

Commercial anti-fraud stacks and ad-tech libraries correlate sessions across IP changes routinely. That is the entire business model of fingerprinting-as-a-service vendors.

You can be on a fresh Mullvad endpoint in Bucharest and the destination site can still recognize you as the same browser that visited yesterday from a residential ISP in Sweden. The WireGuard whitepaper is about transport confidentiality. It is not about application-layer linkability, and the provider has never claimed otherwise. The confusion belongs to the reader.

Red Flag #6: Swedish Jurisdiction and the Limits of "Nothing to Seize"

What it looks like: Mullvad is headquartered in Sweden, often framed as privacy-friendly relative to the classic 14-eyes bloc. The provider's stated posture is that it retains nothing on users at rest.

Why it matters: "nothing to seize" is an architectural claim about past data. It is not a claim about future compelled cooperation.

Sweden has a domestic signals intelligence framework — the FRA-lagen, passed 2008 — authorizing bulk collection on cross-border cables. Sweden cooperates under the Budapest Convention on Cybercrime (2001) and is subject to EU mutual legal assistance instruments.

A request routed through the Swedish Ministry of Justice does not bounce because the recipient has a no-logs policy. Lawful process can compel prospective logging, infrastructure access, or both, within whatever the domestic framework permits. The account number model removes historical correlation material. It does not make the provider immune to an order to start producing correlation material going forward. Different attack, different defense.

Red Flag #7: Account Leakage on Shared Systems

What it looks like: the account number is stored in plaintext in the client config, appears in support tickets, may be cached by password managers under a generic label, and is often copy-pasted into forums when users debug connectivity issues.

Why it matters: in email-plus-password models, leaking the username alone is usually harmless. Here, the account number is the entire credential.

A single screenshot of the app's settings pane posted in a public troubleshooting thread — and these exist, by the hundreds, indexable on the open web — is a functional credential disclosure. There is no revocation path besides provisioning a new account.

This is a direct consequence of the design trade-off. The architecture that prevents the provider from tying your account to an email also prevents it from offering a normal rotation channel. Operational burden shifts to the user, and the user is statistically the weakest link in every threat model we have ever studied.

What it looks like: the Mullvad architecture is audited, open source on the client, and reviewed by well-known firms. You still have no way, as an outside observer, to verify what the production servers are doing at any given moment.

Why it matters: audits are scoped. A penetration test or no-logs review is a snapshot — the auditor examined a defined set of systems over a defined window and concluded a defined set of things. Meaningful; not continuous verification.

Here is the primary-document tension worth sitting with. Mullvad's published privacy policy describes a server architecture that retains nothing. The underlying Swedish legal framework permits compelled prospective cooperation under lawful order.

Both documents are operative. They describe different time windows. The account number model defends against historical-data attacks. It cannot, at the architectural level, defend against compelled-future-collection orders. Reading one document without the other is how the confusion ends up written down as protection.

The Verdict

The Mullvad account number is a genuinely well-designed piece of privacy engineering inside its actual scope. The scope is narrow and worth naming precisely: it prevents the provider itself from accumulating an identified user base, reduces the correlation surface in a database breach, and raises the cost of server-side investigation. Against a passive network observer, a casual data broker, or an ISP logging destination metadata, it does real work. Against an adversary with subpoena power over payment processors, postal systems, or the provider's upstream carriers, it is pseudonymity — not privacy.

The threat model we would apply: the architecture materially helps users whose adversary is commercial tracking, ISP traffic logging, and breach-driven correlation. It helps less, and in some cases not at all, against adversaries with MLAT authority, chain analysis budgets, or endpoint-capable tooling. Whether the account number architecture materially changes outcomes in a compelled-disclosure proceeding — or simply relocates the correlation work to the payment and network layers outside the provider's control — is a question the public record has not yet answered with a citable example. If you have read a court order where the account model itself, not the no-logs policy, changed the legal outcome, we want to see it.

FAQ

Is the account number model actually better than email-based VPN signup?

For most realistic threat models, yes — but "better" is load-bearing. Removing email removes a correlation primitive that would otherwise sit in the provider's database, which is a direct reduction of breach-exposure surface. It does not remove the correlation primitives that live outside the provider: payment, DNS, endpoint fingerprint, destination-site tracking. Treat the account number as one layer of defense that works when the other layers — payment hygiene, endpoint hardening, browser compartmentalization — are also doing their job. Alone, it is a single good choice among many that must be made.

Does the 2023 Swedish police visit to Mullvad prove no-logs works?

It demonstrates that at one specific point in time, investigators who appeared in person left without obtaining the data they wanted, because the architecture did not retain it. Real and meaningful data point. It is not equivalent to proving the model holds against every form of future legal process. Compelled prospective logging under a lawful order is a procedurally different animal from a historical-data seizure, and the public record does not yet contain a documented test of that scenario in a way outside observers can cite with confidence.

Can I pay with Monero and be truly untraceable?

Monero meaningfully raises the cost of on-chain correlation relative to transparent ledgers — that is what ring signatures and stealth addresses are for. "Truly untraceable" overclaims. Active research continues on Monero tracing, ring-signature decoy analysis, and statistical heuristics at the transaction-graph level. For most commercial adversaries, Monero plus an account number is as close to unlinked as current payment rails allow. For a nation-state adversary with multi-year forensic patience, nothing in this answer is a guarantee, and anyone who tells you otherwise is selling something.

Should I use Mullvad or a different audited no-logs provider?

The question we prefer: what is your adversary, and what are you willing to trust? If the adversary is passive commercial tracking, Mullvad's architecture is among the better defaults because the account model genuinely closes a correlation path other providers leave open. If the adversary includes anyone with compelled-disclosure authority, the provider choice matters less than the payment rail, the endpoint posture, and whether the device was clean before the tunnel opened. The account number is a feature. It is not a strategy. Match the tool to the threat, every time.