One VPN Identity Per Device: Why Sharing Breaks Removal

One profile copied onto a laptop, a phone and a tablet works fine until one of them is lost. At that point the choice is to interrupt every device sharing the identity or to leave the unwanted access in place. Both options are worse than the ten minutes it would have taken to issue three identities. The mechanism is not complicated: a VPN peer is an authorization record, and one record per device is what turns removal into a single precise action.

What a shared profile shares

Copying a private key copies the entire authorization: the peer entry, the tunnel address, and whatever routes and policies are attached to it. The server cannot distinguish the copies, because the protocol identifies a peer by key rather than by device. Every log line, every limit and every revocation decision applies to the group. A shared profile is therefore not a convenience with a small security cost, it is a single point of failure with several devices attached.

The same logic applies to a shared account holding one certificate.

Provision through the identity model you have

A WireGuard deployment can authorize distinct peer keys, one per device. A certificate-based deployment can issue individual client certificates from its own authority. An account system may combine a user with separate device records, depending on the product. Use the operator's supported enrollment process, because generating a new local secret does nothing until the peer or gateway recognises the matching authorization.

The supported path is also the one that survives the next upgrade.

Inventory without secrets

Keep the device label, the public identifier and the owner in an inventory you can search. Do not copy private keys into that inventory, because it turns an asset list into a credential store.

A row saying "Ana's laptop, peer public key, issued 12 March" is enough to act on.

Removal is a procedure, not a button

Record how to disable exactly one device and whether an active session needs a separate termination step. Check persistence, so a restart or an old configuration backup does not reintroduce the authorization. Confirm the removal took effect by trying to connect from the removed device. Then check whether anything else referenced that identity, such as a monitoring probe or a shared route.

The step people skip is the last one, and it is the only one that proves the change.

Replacement order

Issue the new device first, verify it against the resource it needs, then retire the old one. The exception is exposure: if the old device may be in someone else's hands, remove it first and accept the interruption.

Either way, review saved exports on the retired hardware before it leaves the building.

What separate identities buy you

Three things, and each one shows up during an incident:

• Revoke one device without touching the others.
• Attribute a connection to a device, not to a group.
• Explain a failure without collecting everyone's activity.

The operator's guidance is the authority on its own provisioning model, whether that is per-peer keys as in the WireGuard quickstart or individual certificates from a local authority. Distinct records are the difference between a fleet you can reason about and a fleet you can only reset.