The laptop is going back to the leasing company, or to a colleague, or to the recycler. Somewhere inside it are VPN profiles that authenticate as somebody, and a disconnected client icon does not mean they are gone. The inventory you want is a list of identities and owners, not a folder of copied keys. The first is useful; the second is a new incident waiting for a date.

Five steps, starting from what the machine already knows about itself.

Step 1: list what the system thinks is installed

On Windows, Get-VpnConnection and Get-VpnConnection -AllUserConnection list native profiles in both scopes, and the installed-programs view catches the third-party clients. On macOS the Network pane shows the configured services, and profiles live in system configuration rather than in a folder you can browse. On Linux, NetworkManager keeps connection files and the tunnel daemons keep their own. Write the list down before deleting anything.

A client that is installed but has no visible profile still matters, because it may hold cached credentials in a system store.

Step 2: find the profiles the clients keep

Profiles hide in predictable places once you know the platform. Windows keeps phone books under the user profile and under ProgramData, with certificates in the personal store. macOS keeps network services in the system configuration plist and credentials in Keychain. Linux distributions keep NetworkManager connections under /etc/NetworkManager/system-connections/, and WireGuard or OpenVPN definitions under /etc/wireguard/ and /etc/openvpn/. Files in those paths frequently carry a private key inline.

Search by content as well as by name. A file called backup.txt can be an OpenVPN profile with a key inside it.

Step 3: record ownership, not key material

For each profile, record the identifier, the owner, the last known use, and where the authoritative copy lives. Do not copy the key, the certificate or the password into the inventory, because an inventory travels through tickets, spreadsheets and chat, and it will outlive the laptop. A reference such as the operator vault entry for profile X is enough to act on.

An inventory containing the secrets it was meant to help retire has made the problem larger.

Step 4: retire the identity at both ends

Deleting a file removes one copy. If the device will never be trusted again, ask the operator to remove its authorization, revoke its certificate or delete the account, because a copy elsewhere still authenticates. Managed profiles and machine certificates usually have an offboarding workflow that already knows about both ends, and it is faster than improvising one. Leave unfamiliar system entries alone until you know who owns them.

Local deletion without remote revocation is cleanup, not offboarding.

Step 5: check the backups you forgot

Old exports live in download folders, in backup archives, in a note file, and on the external drive from two jobs ago. Check the ones you control, and keep any required historical record separate from live credentials, because an archive of a revoked profile is a record rather than a working key.

Then verify the end state: the intended access no longer works, and the person who owns the account knows it was removed.

Inyandiko zihuye