Sharing one VPN login with family: what breaks later

Copying a VPN username and password onto a second device takes a minute and works fine, which is exactly why the problems surface months later. The credential you handed over usually controls more than a tunnel: it may own the subscription, the recovery mailbox and the device list. Before the second phone connects, work out what the login actually authorizes and how one device will be removed without touching the rest.

One password, several different privileges

Commercial VPN accounts typically bundle three things behind a single login: the tunnel credential, the billing or plan record, and the account recovery channel. Sharing the first is a connection decision; sharing the other two hands over control of the subscription. Many providers keep them on the same credential until you deliberately separate them, so the question is not whether the password works on two devices but what else it opens. Ask the operator which of those three the login controls, and whether a separate billing owner or recovery address can be appointed. That single answer decides how much of the account you are actually handing over.

Server-side, the account is a row with a plan and a connection counter. The client app is only a view of that row, and it enforces nothing you could not bypass with a different client. That is why a "one device" plan still connects from three devices until the server decides to reject the fourth session.

Two-factor authentication makes the sharing question sharper. A TOTP secret enrolled on four phones is four copies of the same second factor, and any one of them can satisfy the login. If the account supports separate app passwords or per-device enrollment, use them; if it does not, treat the shared second factor as a known weakness rather than a solved problem.

Per-device keys change what removal means

Self-hosted setups differ because identity lives in the configuration rather than in an account row. A WireGuard peer is a public key plus an allowed set of addresses, and the server authorizes a handshake by matching that key. Delete the peer entry and the device cannot complete a handshake, no matter what password it still holds.

That model gives you clean removal but no per-person accounting, which WireGuard documents as a known limitation. The server sees keys, not family members.

sudo wg show wg0 peers
sudo wg set wg0 peer 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVg= remove
sudo wg show wg0 latest-handshakes

An OpenVPN deployment reaches the same place through certificates and a revocation list: each client gets its own certificate, and revoking one entry leaves the others working. In both designs the identity is per device, so a lost phone is a single deletion rather than a household-wide credential reset.

Concurrency limits live on the server

Providers that sell "five devices" usually count simultaneous sessions, not installed apps. Two laptops and a phone can be fine while a third laptop pushes the account over the limit and one existing session is dropped. The client rarely explains this, so the symptom looks like a flaky connection rather than a plan boundary.

Read the plan terms for the actual rule before promising a device count. Some services count connections, some count distinct devices seen in a period, and some allow a higher number on the same local network.

Decide the household rules before device two

Write down four things: who holds the recovery mailbox, who can add or remove a device, who pays when the plan changes, and what happens when someone leaves. Those are policy decisions that no client setting can make for you, and they are much easier to agree on before an urgent removal is needed. Put the answers in one place the household can find, including which device names map to which person. A list of names is what turns a peer key or an app password back into somebody you can call.

Keep the tunnel credential out of shared notes and chat history. A password manager with a shared vault, or a per-device credential issued by the operator, keeps the secret transferable without leaving copies in three message threads.

Also check how the service handles supervised accounts and family controls, because a VPN changes the network path without replacing parental controls or device management. Then test one real task per person: mail, a video call, a work portal. A tunnel that comes up is not proof that routes, DNS and split-tunnel rules behave the same on each platform.

Prove the removal path while it is still easy

Removal is the part everyone defers, so test it on a device you control. Add a spare phone or laptop, confirm it connects, then revoke that device using the operator's documented method and confirm the tunnel fails while the others stay up.

curl -sS -m 8 -o /dev/null -w '%{http_code}\n' https://198.51.100.20/health

A revoked device should stop reaching the internal address within a session, not merely fail to reconnect after a reboot. If the old session keeps working, the revocation did not reach the server, and the credential is still live.

Record the result in the household note that already lists the devices, and revisit it when a phone is replaced. The arrangement stays manageable only while the identities, the limits and the removal step are all written down.