Offboarding remote access: revoke device access same day

When an employee leaves, the urgent risk isn’t a resignation letter — it’s the half-hour window between HR notification and the first unauthorized reconnect. This guide is a practical, same‑day checklist for offboarding remote access so you can revoke a departing employee’s device access the same day and leave nothing useful behind.

Quick, actionable 12-step checklist

1. Get the inventory: list devices, sessions, service accounts, agents, and VPN/RMM access tied to the user.
2. Immediately disable the user identity (AD / Azure AD / IdP).
3. Terminate active remote sessions and revoke session keys or tokens.
4. De-register or revoke device certificates used by remote‑access agents.
5. Block the device’s network access (VPN, firewall rules) if it’s company-managed.
6. Rotate passwords and secrets for shared accounts the user touched within 24 hours.
7. Remove the user from privileged groups and local admin lists.
8. Uninstall or disable remote‑access agents on known endpoints; if not possible, block agent registrations.
9. Revoke SSH keys and API tokens the person owned or used.
10. Collect forensic artifacts and write a short incident log of actions and timestamps.
11. Audit logs from your relay/proxy and the target hosts to confirm disconnects.
12. Communicate status to HR and security; confirm completion in writing.

Which things to revoke (and why it matters)

Offboarding remote access means removing every credential or artifact that could be used to re‑establish a session. That includes three categories: identity credentials (user accounts, MFA devices), device authentication (certificates, device registrations), and session authentication (active session tokens, SSH keys, API tokens).

Important truth about relays and direct connections: when two endpoints connect peer‑to‑peer the session is end‑to‑end between those devices. When a connection falls back to a relay, TLS terminates at the relay — so whoever operates that relay can observe the session. For that reason you must treat both device certificates and relay registrations as revocable attack surface.

Detailed steps per platform and control plane

Below are pragmatic commands and patterns you can adapt. Always run these from a management host or jump box and test on a single device before mass automation.

Windows (Active Directory and endpoints)

Immediate actions:

• Disable the AD account: Disable-ADAccount -Identity "jsmith" (requires the ActiveDirectory module).
• Block sign‑in for Azure AD users (if you use Azure AD): either disable the account via your IdP or use Graph API commands.
• Terminate RDP/remote sessions: run query user / logoff <ID> on the host, or use your remote‑management console to kill sessions.
• Remove local admin rights: Remove-LocalGroupMember -Group "Administrators" -Member "DOMAIN\jsmith" (PowerShell 5.1+).
• Uninstall or stop the remote agent service: Stop-Service -Name "RemoteAgent" -Force; sc.exe delete "RemoteAgent" — replace the service name with your agent's service.

macOS and Linux

Immediate actions:

• Lock or disable the user account: macOS: sudo dscl . -passwd /Users/jsmith "" (or use your MDM). Linux: sudo usermod -L jsmith && sudo chage -E 0 jsmith.
• Remove SSH keys from ~/.ssh/authorized_keys on managed hosts. Example (replace the comment or fingerprint):

  ssh admin@host 'sed -i "/user-ssh-key-comment/d" ~/.ssh/authorized_keys'

• Stop and disable remote agent services:

  ssh admin@host 'sudo systemctl stop remote-agent.service && sudo systemctl disable remote-agent.service'

  — substitute your agent's service name.

SSH, API tokens, and service accounts

Shared or personal SSH keys and API tokens are high‑value artifacts. Rotate any shared credentials the user could access. For SSH, remove authorized keys and rotate host keys where appropriate for unclear exposure. For APIs and CI/CD systems, revoke any tokens issued to the user and rotate the tokens used by automation that the user could edit.

How to revoke remote‑agent/device registration safely

Every remote agent typically maintains a device identity — a certificate, a registration entry on a relay or a device registry. Your offboarding flow must remove both the registration and any certificate or token that allows re‑registration.

• Console de‑registration: use your remote‑access admin console to de‑register or quarantine the device. This prevents new connections and invalidates long‑lived device credentials.
• Block agent registrations at the relay: if you run a managed relay, create a deny rule for that device ID or fingerprint until you can either re‑image the machine or perform an on‑site wipe.
• Uninstall the agent when possible — but do not rely on user action. If the device is remote and not reachable, block network access and revoke the device identity from your relay.

Automation templates and quick scripts

Automation reduces human error during time‑sensitive offboarding. Below are two template scripts you can adapt — one PowerShell for AD/Windows tasks and one Bash for Linux host chores. Replace variables and service names with your environment specifics and vet in a staging account first.

# PowerShell template (run from admin workstation with AD module)
$User = 'jsmith'
# Disable AD account
Disable-ADAccount -Identity $User
# Remove from local Administrators on a list of machines
$computers = @('PC01','$PC02')
foreach ($c in $computers) {
  Invoke-Command -ComputerName $c -ScriptBlock {
    param($u)
    Remove-LocalGroupMember -Group 'Administrators' -Member $u -ErrorAction SilentlyContinue
    # Stop remote agent service (replace 'RemoteAgent' with your agent)
    Stop-Service -Name 'RemoteAgent' -Force -ErrorAction SilentlyContinue
    sc.exe delete 'RemoteAgent' | Out-Null
  } -ArgumentList $User
}
# Rotate shared password note: call your password manager or runbook here
Write-Output 'Disabled account, removed local admin, stopped agent (where reachable)'

# Bash template (run from admin host)
USER=jsmith
HOSTS=(host1.example.com host2.example.com)
for h in "${HOSTS[@]}"; do
  ssh admin@${h} "sudo usermod -L ${USER} && sudo chage -E 0 ${USER} || true"
  ssh admin@${h} "sudo sed -i '/user-ssh-key-comment/d' /home/${USER}/.ssh/authorized_keys || true"
  ssh admin@${h} "sudo systemctl stop remote-agent.service || true; sudo systemctl disable remote-agent.service || true"
done
echo 'Locked accounts, removed ssh keys and disabled agent service where reachable.'

Verification: prove the device can't access anything

Revocation without verification is a hygiene illusion. Your checklist must include hard verification steps with timestamps.

• Check active sessions: Windows hosts: query user / quser. Linux: who and ss -tnp to list active connections.
• Audit your relay: ensure the device’s registration or certificate is absent from the relay registry and that no session originated from the device after revocation.
• Confirm IdP logs show account disablement and that no successful authentication occurred after your action time.
• Confirm credential rotations for shared accounts, and list rotated secrets in your incident log (do not paste secrets into logs).
• Collect screenshots/exports of logs and store them with HR and security records.

When to self‑host your relay vs use a managed relay

Use a managed relay by default. A managed relay — Tenvo’s multi‑region managed relay in particular — keeps you off the maintenance treadmill: it handles certificate delivery, uptime, and multi‑region failover out of the box. Tenvo has native clients for macOS, Windows and Linux, a browser client in public beta, and managed relay pricing tiers (Free $0 / Lite $2.99/mo / Pro $7.99/mo).

Self‑hosting is the right choice only when a written requirement forces it: a compliance rule that bars third‑party infrastructure, a fully isolated network, or a data‑residency mandate that your provider can’t meet. Self-hosting forces you to own on‑call, patching, certificate renewal, key custody and multi‑region failover — those costs usually exceed the price of a managed relay once you factor incident response and uptime SLAs. If you must self‑host, see our detailed guidance at Self‑Hosted Remote Desktop: Why, How, and What Breaks.

Post‑offboarding checks, documentation, and lessons learned

Complete these post‑actions within 24–72 hours:

• Run an audit log reconciliation and export logs to your long‑term archive. See our recommendations on remote‑desktop audit logging.
• Perform a quick forensic snapshot of the device if there is any suspicion of compromise.
• Update onboarding/offboarding runbooks and add timing metrics: how long each step actually took, what broke, and where automation is needed.
• Train HR and first‑responders on the offboarding runbook so the technical team gets the notice earlier.

Practical pitfalls and anti‑patterns

Common mistakes that prolong exposure:

• Waiting to disable the IdP account until the manager requests final access — disable first, verify later.
• Assuming uninstall by the user removes certificates; it often leaves keys in the user profile.
• Rotating only passwords but not API tokens, SSH keys, or service account credentials the user could edit.
• Relying on VPN blocks alone; if an agent maintains an out‑bound connection it can re‑register once VPN returns unless its device identity is revoked.

Where this fits in a wider security program

Offboarding remote access is part of identity lifecycle and endpoint hygiene. Tie these actions to HR notifications (automated tickets), your PAM/vault for secrets rotation, and your SIEM for audits. If you want deeper threat modeling and controls, our article Is Remote Desktop Secure? An Honest Threat Model outlines where remote agents are commonly abused and which controls reduce risk.

For teams who manage many users and endpoints, combine offboarding with role‑based access controls, short lived credentials, and device posture checks to reduce the number of manual steps you must run in an emergency.

Final checklist (one page you can copy)

• Inventory: device IDs, agent versions, active sessions — timestamped.
• Disable identity at IdP immediately.
• Terminate remote sessions and confirm via host logs.
• De‑register device from relay and revoke device certs.
• Block network access if device unreachable.
• Uninstall/disable agent where possible; block new registrations at relay.
• Rotate shared credentials and revoke tokens/SSH keys.
• Export and archive logs; create incident note with timestamps and actors.
• Communicate to HR and security and close ticket when verified.

Offboarding remote access is operational work, not a theoretical checklist. Practice the flow on a test user, automate the trivial steps, and log timestamps for every action. If you run into a policy that insists on self‑hosting, read Self‑Hosted Remote Desktop first — you’ll often find the operational cost outweighs the perceived control.

If you want a practical tool that avoids port forwarding headaches and gives you a managed relay with a small set of predictable prices plus native clients and a browser option in beta, try Tenvo — download the client and test your offboarding runbook at Download Tenvo.