Sharing a login does not make you invisible, and it does not make the other users your colleagues. It changes who can be identified and who can be removed, and it leaves every other property of the connection where it was. The myth is that common credentials imply anonymity or trust; the reality is that they remove accountability and add shared failure modes.

What the credential actually controls

A username and password answer one question: may this connection be established. They do not decide what the operator logs, what other clients can reach, or whether the exit node is honest. Those are separate properties of the service, and a shared account says nothing about any of them.

The gateway still sees the source address, the connection time and the volume of traffic under its own policy. Shared credentials do not erase those records; they only make it harder to attribute them to a person. If the operator keeps logs, the log now shows a session that could belong to anyone holding the credential.

That is the opposite of anonymity, and it is also the opposite of accountability.

Removal and rotation affect everyone

With unique identities you can disable one device and leave the rest working. With a shared credential, rotating the password disconnects every user at once, and removing one person means changing the secret for all of them. Plan for that before you distribute it. The cost is not only inconvenience: it pushes operators toward never rotating at all, which is how a leaked credential stays valid for years.

A credential posted in a forum or a chat group should be treated as public from that moment.

The practical consequence is that a shared login fits poorly with anything you would need to audit or revoke individually, which includes most work deployments and any family setup where one device is lost.

Other clients are not your local network

Client-to-client reachability is a configuration choice, not a property of the word private. Some services isolate clients from each other; others route between them. A shared account does not tell you which one you are on.

Assume the other clients are strangers until the service's documentation says otherwise. Keep the host firewall on, do not enable file sharing on the tunnel interface, and do not treat a VPN address as a trust signal for an application. WireGuard's own limitations page is explicit that the protocol does not hide the endpoints or provide anonymity by itself, and that is the right mental model for any VPN.

The tunnel protects the path, not the peers.

What to check before you use one

Read the operator's published policy for logging, jurisdiction and retention, and notice what is missing. A provider that does not state a retention period has not promised one. Then compare the exit address you actually get with the location the service advertises.

curl -s https://example.net/cdn-cgi/trace | grep -E '^(ip|loc)='

If the visible exit address sits in a country you did not expect, the profile and the claim disagree, and that is worth resolving before you send anything through it.

For a paid service, prefer a plan with per-device credentials even when the marketing pushes the shared one. It costs a little more administration and buys the ability to revoke.

A better default for work and family

If you are setting up access for a group, create one identity per person or per device, keep the list of who holds them, and remove entries when a device retires. That is more work than mailing a password, and it is the difference between a service you can operate and a secret you cannot recall. The shared account is convenient precisely because it hides that work, and the bill arrives the first time someone leaves. Hand the list to whoever handles offboarding, so removal does not depend on remembering a chat message.

Document the rotation path before the first incident, not during it. Write down who can create an identity, who can revoke one, and where the list of holders lives. Those three answers are what make the arrangement operable rather than merely convenient.

A shared login has a narrow use: a public exit you do not depend on for privacy or accountability. Treat it that way and the risks become predictable.

Allakkat attuumassuteqartut