You delete the VPN entry, the profile list looks clean, and the credential is still there. Connection entries, saved passwords, certificates and private keys live in different stores, and a shared computer is the wrong place to assume that Disconnect or Uninstall finished the job. The walkthrough below moves from the client's own controls outward to the system store, then to the server side, because local removal and remote revocation are separate actions with separate evidence.

Do it in that order: removing access locally first means the remaining steps can be done without the credential you were trying to erase.

Start with the owning component

Use the app's supported saved-credential or profile-removal controls, not a guessed filename. A native operating-system profile usually lives in a system store, while a third-party client often keeps its own configuration directory, and only the client's own removal path knows which of those it used. That inventory also tells you which copies exist rather than which ones you remember creating, and the two lists rarely match.

Before you delete anything, identify what the entry refers to. A profile can point at a separate password file, an exported certificate or an embedded private key, and removing the connection does not necessarily remove any of them.

Write down what you found and where. That inventory is what makes the next step safe, because it tells you which copies exist rather than which ones you remember creating.

Check the files a profile references

Review the client's configuration directory, the download folder and any export location you are authorized to manage. Old installers and support bundles are common places for a key that nobody remembers copying, and they are exactly what an audit finds later. Check the modification date as well, because a key copied during a support session is easier to date than to explain.

Do not delete another user's identity material on a shared machine, and do not touch a managed organization's profile unless you own that decision. Removing somebody else's certificate can be an outage with your name on it, and it is not what "clean the VPN off this PC" meant.

On macOS, Keychain Access has its own documented controls, and the item may live under a name the client chose rather than the profile name. On other platforms, follow the actual client and system instructions instead of applying one generic filename recipe from a forum post.

Decide whether the server also needs revocation

Deleting a local copy does not disable the remote account and does not revoke a public-key authorization. If the device is no longer trusted, or a secret may have been copied, use the operator's password, certificate or peer-removal process. This is the step people skip, and it is the only one that changes what the far end accepts.

Separate per-device identities make that practical: you can retire one shared-computer installation without disrupting every other device that user owns. A password change alone may not revoke a separate client certificate or every session token, so check which credential actually authenticates the connection.

Ask the operator which of those applies before choosing a control. Changing a password for a certificate-authenticated tunnel feels productive and changes nothing. Ask for the artifact that proves removal, not a verbal confirmation, because the artifact is what an auditor will accept. Then file it next to the ticket.

Verify both halves

Check the local side by reopening the client and confirming the profile is absent, then check the referenced files again — a leftover key on disk is the finding, not a cosmetic issue. Check the server side by confirming the removal took effect, using whatever the operator provides: a peer list, a certificate revocation entry, or a session table. Do the server check from a different machine, since the point is what the far end accepts and not what this computer believes.

Record the action without the secret. A support note that says which profile was removed, by whom, and when is enough; pasting the credential into the note recreates the problem in a different system.

Apple's Keychain Access guidance is the reference for that store on macOS, and it is worth reading before you delete an item you did not create.

Leave the device in a state you can explain

Finish with a short statement of what is gone and what is not: client profile removed, credential store entry removed, key file deleted, server-side identity revoked. If any line reads "probably", it is not finished. Name who performed the server-side removal as well, because shared machines change hands without a change record. Store the statement with the device record rather than in a personal note.

On a shared computer, that statement is the handover. The next person needs to know whether the machine is clean or merely logged out.

Ingingo zihuye