What to do if your VPN provider is breached

Every service is breached eventually, and a VPN provider is a more interesting target than most because of what it might hold. The severity depends entirely on what it was holding, which is a question worth answering before an incident rather than after.

What could be exposed

Account data. Email address, hashed password, subscription status, payment records. Every service with accounts has this, and it is the most likely category to be lost.

Connection records. Which account connected to which server, when, and from what source address. This is the category that matters, because source address plus timestamp links a person to a session.

Traffic content or DNS queries. Should not exist at any credible provider, and would be catastrophic if it did.

Server keys. Which, without forward secrecy, would allow decryption of previously recorded traffic — and with it, would not.

Why the retention policy is the whole answer

A provider that never recorded source addresses cannot lose them. A provider that keeps them for thirty days loses thirty days' worth.

This is the practical reason specificity in a privacy policy matters more than a no-logs slogan. "We do not log" tells you nothing about what a breach would reveal. "We retain the server used and the session time, and never the source address, browsing history or DNS queries" tells you precisely.

VPNmine's privacy policy states it that way for exactly this reason: a policy is a description of your exposure in the worst case, not a marketing line.

What the provider is obliged to do

Under GDPR, a controller must notify the supervisory authority without undue delay and where feasible within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals.

Where the risk to individuals is high, the provider must also communicate the breach to those affected, describing its likely consequences and the measures taken.

Similar obligations exist in many jurisdictions. A provider that discloses promptly and specifically is behaving correctly; one that discloses months later in a blog post is not, and that is a signal about how it operates generally.

What to do as a user

1. Change the password, and anywhere you reused it. Reuse is how one breach becomes several.
2. Enable two-factor authentication if the service supports it and you had not.
3. Read the disclosure carefully for what categories were exposed. "Account data" and "connection logs" are very different findings.
4. Rotate keys or configurations if the provider issues per-device credentials and the breach touched them.
5. Watch for phishing. A breached customer list is used for targeted phishing referencing the service, and this follows nearly every incident.
6. Decide whether to stay, based on the response rather than on the incident alone.

Judging the response

Good signs: prompt disclosure, specificity about what was and was not affected, a named individual accountable, a technical post-mortem, and changes described concretely.

Bad signs: delay, vagueness, blaming a third party without detail, minimising, and a statement that no sensitive data was affected without saying what was.

The response is more informative than the breach. Every service will have one eventually; not every service handles it well.

What to check before you need this

Read the retention section of your provider's policy today and note what it says would exist. Check whether the provider has had incidents and how it handled them. And check that the terms name a real operator with a real address, because a provider you cannot identify is one you cannot hold to any of the obligations above.

Why VPN providers are a distinctive target

An ordinary breach yields a customer list. A VPN provider's records, if it keeps the wrong ones, yield something closer to a movement log: which account was active from which address at which time, across months.

That is valuable to more parties than a password dump is, and it is why the retention question is not academic. A provider's stated policy is, in effect, a statement of how bad its worst day would be for its users.

It is also why the architecture choices some providers make — diskless servers, in-memory state, aggressive rotation of peer records — are worth something even though they are not a substitute for not collecting the data at all.

Server compromise versus database compromise

Worth separating, because they expose different things.

A compromised server exposes what is in its memory now: active peers, their tunnel addresses, and where they are connecting from at that moment. Forward secrecy means previously recorded traffic stays unreadable, and nothing historical is on the machine if it keeps nothing.

A compromised central database exposes accumulated records: accounts, payments, and whatever connection metadata the provider chose to centralise.

Most incidents that matter to users are the second kind, and most architectural marketing is about the first. That gap is worth noticing when reading a provider's security page.