How to Revoke a Lost VPN Device: Key, Certificate or Account

Your laptop is gone, and the VPN still lists it as a client. The urgent question is not how to delete the profile on a machine you no longer have, but which identity the server still accepts. WireGuard checks a public key, a PKI-based OpenVPN setup checks a client certificate, and an SSO-fronted VPN checks an account and its session token. Those three revoke in different places, at different speeds, and fixing one while ignoring the others is how a lost device stays connected.

Three identities and what each one gates

Each mechanism answers a different question. A peer key answers whether this is the machine you enrolled. A certificate answers whether it was signed by your CA and has not been revoked. An account answers whether this person authenticated recently enough. A deployment that layers two of them, certificate plus directory login for instance, only closes the door when every layer that issued the device something has been told to stop accepting it.

The practical trap is that the missing machine holds the private half of each credential, so nothing you do locally reaches the server.

WireGuard: remove the peer, because there is no revocation list

WireGuard keeps no deny list. The interface accepts exactly the public keys configured as peers, so revocation is deletion: run wg set wg0 peer <public-key> remove, the form documented in wg(8), then delete the matching [Peer] block from wg0.conf. Do both. A runtime-only removal survives until the next reboot or config reload, at which point the file puts the key back.

Existing sessions do not need a timer to die. Removing the peer drops its handshake and key material, so traffic stops as soon as a valid keypair is required again. Check wg show wg0 latest-handshakes on the server: the entry for the lost key should vanish and stay gone, while the other peers keep reporting recent epochs.

One caveat matters more than it looks. If the lost device shared a key with other devices because someone copied one config file, removing that key disconnects all of them; that is still the right move, and you reissue per-device keys afterward instead of restoring the shared one.

Certificates: a CRL only counts if the daemon reads it

Certificate-based access adds a step that people skip. easyrsa revoke laptop-01 marks the certificate revoked in the CA database, but the VPN learns nothing from that database. You then run easyrsa gen-crl to write crl.pem, copy it to the path named in the server's crl-verify option, and confirm the running daemon is using the new file. Revoking without regenerating and distributing the CRL is a no-op.

Timing is the second half. A CRL is consulted when a client connects or renegotiates, so an established tunnel can keep forwarding until then. If the device must be cut off immediately, terminate that session explicitly through the OpenVPN management interface rather than waiting for the next handshake. Reloading or restarting the service, depending on how the deployment loads the CRL, is part of the change and not an optional extra.

Verification is worth doing from another machine: present the revoked certificate and expect a handshake failure, typically VERIFY ERROR: depth=0, error=certificate revoked. If the connection still succeeds, the client is reading a different CRL than the one you updated.

Accounts and sessions: disable is not the same as evict

Directory or SSO logins are checked at authentication time. Disabling the account blocks the next login, but the refresh token and the established tunnel may keep working until they expire. Revoke the sessions and tokens for that user, or bump a session version if the identity provider supports it. Remove the lost device from the MFA enrollment as well, since a registered authenticator is an access path of its own.

RADIUS-backed VPNs can push a disconnect message or a change-of-authorization to drop an active session, but not every network access server honours it. When in doubt, end the user's session from the server side and confirm in the logs that the old session closed.

Order of operations for the next hour

Start from inventory, not from the client: list every identity tied to the device, whether peer key, certificate serial or account. Revoke at each issuing system in the order the connection is built, meaning account first, then certificate, then peer. Then prove the refusal from a machine you control.

Two follow-ups are easy to forget. First, rotate anything else the device held, especially SSH keys, cloud console credentials and a shared WireGuard preshared key. Second, check that configuration management, snapshots or golden images cannot reintroduce the removed client on the next rebuild.

The durable fix is one identity per device. When every laptop carries its own peer key or certificate, a loss costs one revocation command and a reissue rather than a rebuild of the whole fleet.