VPN Offboarding: Local Profile Cleanup Does Not Revoke Access

Adapted from Removing VPN Access When Someone Leaves: An Offboarding Checklist by Mohammad Hesameddin Montazerilisar, published July 9, 2026 and updated September 27, 2026. AI assistance was used for editing, introductory framing, and a short reference note. The author writes for Lisar Connect and is Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C.

Treat a downloaded configuration, an imported client entry, and the service’s access decision as separate parts of the offboarding workflow. Removing one local artifact does not establish what happened to the others.

Per-person setup can make offboarding easier to track. When a team member leaves, identify their assigned access, confirm its removal through the authorized process, and handle returned-device cleanup separately. This is a non-technical checklist for coordinating those steps.

A note on scope up front: this article is about the team's practical offboarding steps and routing the account side to the right process. It deliberately doesn't provide technical account-side procedures — those belong to the account, admin, and official support process, not to a public checklist.

Step 1: Identify who is leaving and what they had

Start with clarity: who is leaving, and what VPN setup did they have — which devices, whose profile. Where setup is per-person, use the assignment records to identify that person’s profiles and authorized devices; verify the record rather than assuming it is complete. Knowing exactly what existed is what makes the rest of the checklist concrete rather than guesswork.

Step 2: Stop relying on any shared files

If, despite best intentions, anything was ever shared — a profile file that got forwarded, a copy in a shared folder — offboarding is the moment to stop relying on it and correct the pattern. Keep future assignments per-person, but also resolve the copies that may already exist.

If a profile or credential was shared, tell the administrator which assignments may be affected without distributing the secret again. Ask them to confirm the required invalidation or replacement. Moving future users to individual profiles does not revoke an existing shared copy.

Step 3: Follow the account and support process for access

The actual removal of access on the account side goes through the proper channel: the account, admin, and official Lisar support process. That's deliberately where it lives — not in a public how-to — because it's the correct, supported path and because the specifics belong to the team's account context.

Ask the authorized administrator or official Lisar support to remove the departing person’s access and confirm when that action is complete. Record any session termination or credential/profile invalidation that the actual service process requires. Sending a request is not confirmation that access has ended; do not mark offboarding complete while that result is unverified.

Step 4: Remove local files from returned devices

On returned devices you are authorized to administer, remove downloaded profile files and the separate imported profiles or saved VPN configurations through the client or operating-system controls. OpenVPN Connect documents profile removal from the app. Removing the download alone leaves an imported entry intact; neither local action invalidates copies on other devices.

For devices handled by your team's normal device-return process anyway, that process covers it. The deliberate file-removal step matters most for devices that are simply handed back and reused as-is. This is local file hygiene — not an account action, and not something that touches anyone else's setup.

Step 5: Update team documentation

Update the team’s records with the confirmed access-removal outcome, the returned-device cleanup outcome, and any unresolved step. Do not record the person’s offboarding as complete merely because a request was sent. If the team keeps a simple setup document, note the change there so the picture stays current for whoever onboards or offboards next.

What offboarding must not involve

Two firm boundaries. First, no sharing of sensitive material as part of offboarding — no passing around the departing person's profile file, credentials, or screenshots of setup details "to sort things out." Departure is not a reason to move material that shouldn't move at any time. Second, no improvised technical removal — access removal is the account/admin/support process's job, and a team's role is to initiate and follow it, not to invent steps.

Use documentation for the actual system

The OpenVPN Connect instructions linked above describe removing an imported profile from that client; they do not document revoking a Lisar account. For a separate identity-system example, Microsoft’s Entra access-revocation guidance distinguishes account controls from session and token behavior. This illustrates why completion depends on the actual service. It does not imply Lisar uses Entra or shares its procedures or timing.

Two questions to close before offboarding is complete

What if a profile file was shared before we knew better?

Notify the administrator or official support and confirm whether the shared credential/profile must be invalidated or replaced. Do not assume that deleting a file or moving future users to individual profiles disables earlier copies.

What can we do on the device side during offboarding?

On returned devices you are authorized to manage, remove downloaded files and imported client profiles or saved configurations using the documented controls. Keep account-side access removal separate and confirm it through the administrator or official support.