How to revoke access when someone leaves

Summary

When someone leaves your team or project, you need to revoke their access so they can no longer log in or use resources. This guide walks through a repeatable process: revoke their SSH keys and API/token access, invalidate sessions and remove them from organizations and apps, rotate shared credentials they might know, then verify and document. It assumes you have admin or owner access to the systems involved (servers, GitHub, cloud, CI/CD).

Prerequisites

• Admin or owner rights on the systems where the user had access (servers, GitHub org, cloud account, CI/CD, shared apps).
• A list of systems the person used (or access to audit logs to see where they logged in).
• Ability to change shared credentials (passwords, tokens) and to remove users from teams and orgs.
• Optional: a simple checklist or spreadsheet to track what you revoke and when.

Steps

Step 1: Revoke SSH keys and API/token access

SSH keys on your servers

• On each server the user could access, edit ~/.ssh/authorized_keys in their account and remove their key lines (or delete their account and home directory if you deprovision entirely):

  # As root or with sudo, edit the user’s authorized_keys
  sudo -u theuser nano /home/theuser/.ssh/authorized_keys
  # Remove lines that belong to the departing user; save and exit.

• If you use a central or shared authorized_keys list, remove their key from that list wherever it is applied.

GitHub (and similar)

• In the org or repo: Settings → SSH and GPG keys (user’s own) — user can remove their own keys when they leave; if you have no access to their account, you cannot remove their keys from GitHub, but you can remove their access to the org/repos so their keys no longer work for your resources.
• Remove the user from the organization: Org Settings → People → select the user → Remove from organization. This revokes their access to all org repos and settings.
• Deploy keys / tokens: In each repo, Settings → Deploy keys and Secrets and variables → Actions (and similar): remove any deploy keys or tokens that belonged to or were used by that person. Rotate any shared tokens they might have known.

Cloud and CI/CD

• In the cloud provider (AWS, GCP, Azure, etc.): delete or disable the user’s IAM user/account, or remove their access from IAM policies and groups. Revoke their access keys and any temporary credentials.
• In CI/CD (e.g. GitHub Actions, GitLab CI, Jenkins): remove their account or revoke tokens; rotate any shared secrets or integration tokens they could have used.

Step 2: Invalidate sessions and remove from orgs and apps

• Sessions: Where the product allows, revoke active sessions (e.g. “Sign out all devices”). This is common in identity providers, GitHub, and some cloud consoles. Do it as soon as the person is offboarded.
• Organizations and teams: Remove the user from every org and team they were in (GitHub, Slack, cloud, internal apps). Check “Members” or “People” in each product.
• Shared or team apps: If they had separate logins (e.g. a shared dashboard, DB UI), remove their account or change the shared password and revoke their session.

Step 3: Rotate shared credentials they could know

If the person might have seen or used shared secrets, treat them as compromised and rotate:

• Shared passwords (e.g. team account, DB, admin panel): change the password and update it only for people who still need access.
• Service accounts and API keys they used or could see: generate new keys or secrets, update systems that use them, then revoke or delete the old ones.
• Deploy keys, webhook secrets, integration tokens: Create new ones, update the apps/services that use them, then remove or expire the old ones.

Do not skip rotation because “they’re trusted”; access control assumes you revoke first, then rotate anything they could have copied.

Step 4: Verify and document

• Verify: From a test account or their old credentials (if you still have a test), confirm they can no longer log in or access repos/servers/consoles. Try SSH to a server they used; try opening an org repo or console they had access to.
• Audit logs: Where available, check login or audit logs to see their last successful access and confirm no new access after your revocation.
• Document: Record what you revoked and when (e.g. “Removed from GitHub org X, rotated deploy token Y, removed SSH key from server Z”). This helps for compliance and if you need to re-check later.

Verification

• The user cannot log in to any system they previously used (SSH, GitHub, cloud, apps).
• Their keys or tokens no longer work (e.g. their SSH key removed from servers; their or shared API tokens revoked/rotated).
• They are removed from organizations and teams; shared credentials they might have known have been rotated.
• You have a short record of what was revoked and when.

Troubleshooting

You don’t have admin on a system they used
Escalate to the owner or admin of that system and request revocation (keys, tokens, user removal, session invalidation). Provide the user’s identifier (email, username) and, if possible, a list of resources they had access to.

You can’t remove their GitHub SSH keys from their personal account
You can’t edit another user’s personal SSH keys. Remove their access to your org and repos so their keys no longer work for your resources. Rotate any deploy keys or tokens they had access to.

Shared secret is embedded in code or config
Search the repo and configs for the old secret (and avoid committing the new one). Rotate the secret, update the places that use it (CI, servers, apps), then revoke or delete the old secret. Use a secrets manager or CI secrets so the value is not stored in plain text in the repo.

Uncertain what they had access to
Check audit or login logs (GitHub, cloud, SSO) for their account and list systems they used. Cross-check with team leads and then revoke and rotate in those systems first; add the rest as you discover them.

Next steps

• Keep access under control over time: Accounts and access checklist before going live (periodic review).
• If you run into permission issues during or after revocation: Access denied: how to fix permission errors.