Cover description: Three separate controls represent removing a profile from a client, revoking a certificate on a server, and checking whether an account may connect. The headline reads “Remove. Revoke. Verify.”
A laptop has been replaced. Someone removes its VPN profile and marks the access-removal ticket complete. What exactly has been proved?
Only that one client no longer shows that profile. Whether a copied profile can authenticate, whether the user can obtain another profile, and whether an existing session remains connected are separate questions.
This distinction makes offboarding documentation more precise. It also helps during ordinary device replacement, where the goal may be to retire one device while preserving the person's access from another.
This article describes a documentation and verification approach for OpenVPN deployments. Access Server examples apply to that product; Community Edition deployments have their own certificate and server configuration. These are general technical examples, not statements about Lisar's backend implementation. No production access changes or live revocation tests were performed for this article.
Start with the intended result
Before choosing a control, complete this sentence: “After this change, ___ must no longer be able to ___.”
The first blank might be a particular device, a particular credential, or a person. The second might mean start a new tunnel, retain an existing tunnel, or obtain replacement credentials. Treating those as interchangeable creates incomplete tickets.
| Intended result | Evidence to collect |
|---|---|
| Remove an obsolete profile from one device | That exact profile is absent from the selected client |
| Stop one retired profile from authenticating | The server records the targeted revocation, and a controlled new connection using that profile is rejected |
| End a person's VPN entitlement | The correct account's access policy is denied and relevant authentication paths are checked |
| End an existing connection | The specific session is no longer active, independently of the new-connection test |
The table is a proposed acceptance checklist. It does not imply that one vendor button performs all four actions.
Client deletion is a local observation
OpenVPN Connect's profile-deletion instructions describe removing a profile from the app. They also state that a profile with an active connection cannot be deleted.
A useful readback therefore identifies the device, client, and selected profile. “It disappeared from My Profiles” is a valid result for that scope. It should not be rewritten as “the credential is revoked everywhere.” A screenshot of the empty client list does not establish what a server will accept from a different device or copy.
The original downloaded file is another object. The app's list and the device's file storage need separate handling under your organization's retention and device-management rules.
Certificate revocation has its own scope
The Access Server revocation tutorial, last modified August 27, 2025, distinguishes revoking a profile's certificate from blocking its user. Its documented outcome is that a subsequent connection with the revoked profile fails; the user may obtain a replacement profile if still permitted.
That distinction matters for a device replacement. Revoking the retired laptop's credential and issuing a fresh one for its replacement can fit the intended result. It does not necessarily fit a complete user-offboarding request.
Record the exact profile or certificate identifier that the administrator selected. A username alone can be too broad for one-device retirement and too narrow to explain which credentials were handled.
OpenVPN's Access Server profile documentation describes multiple profiles per user, each with its own certificate and key in supported versions. That provides a reason to keep device-to-profile records current: without a reliable association, “revoke the old laptop” becomes an identification problem before it becomes a technical action.
Account denial is a different decision
The Access Server user-management documentation identifies Deny Access as a control for withdrawing a user's privileges. It also documents profile management separately.
For a user-offboarding ticket, the authorized administrator should identify the correct account and the authentication path actually used by that deployment. Record the intended permission result and its readback. Do not infer it solely from the disappearance of a profile or a change to one password.
For a device-only replacement, preserve that narrower scope. Disabling the whole account would also affect authorized work on other devices. The request should make that tradeoff explicit before an administrator applies it.
Test future authentication and current sessions separately
Certificate enforcement has timing. The Community Edition revocation documentation explains that its configured revocation list is read during new connections and TLS renegotiation. It separately discusses terminating an already connected client.
The operational lesson is to write two results:
- New connection: Can the specifically retired credential establish a fresh connection?
- Existing session: Is the specifically targeted current session still present?
A failed reconnect does not, by itself, prove that a previously established session was terminated. Conversely, a session disappearing does not prove that its credential cannot reconnect later. Use the deployment's supported administrative controls and its actual configuration; avoid turning an example timing value from documentation into a universal termination guarantee.
Make the completion record small and testable
A compact ticket can hold the evidence without embedding credentials:
Purpose: Retire one replaced device / end user access
Deployment and authorized scope:
Account identifier:
Selected profile or certificate identifier:
Requested permission outcome:
Server-side action and observed result:
New-connection verification and timestamp:
Existing-session verification and timestamp:
Local profile cleanup result:
Remaining exceptions:
Keep identifiers in the authorized operational system. Do not attach private keys, complete connection profiles, passwords, or authentication tokens to a public troubleshooting thread.
If a check cannot be performed, name the exact gap: for example, “revocation recorded; controlled reconnect not tested.” That is more useful to the next administrator than a single ambiguous “done.”
Affiliation: Mohammad Montazeri is the founder of Lisar Connect. This article was researched and drafted with autonomous AI assistance; it makes no claim of a first-hand production incident or a completed deployment test. Official documentation was checked on September 10, 2026.
Top comments (1)
The three-way split - remove client profile, revoke server cert, verify account can't connect - is a genuinely useful model; most offboarding docs I've seen conflate the first two and skip the third.
For the verify step I added a check that logs in as that user with a freshly generated profile and asserts the connection is refused before closing the ticket. It catches exactly the copied-profile case you describe. How do you kill an already-connected session immediately rather than waiting for the next connect attempt?