Offboard a Departed Admin When You Don’t Know Which Passwords They Knew

TL;DR — If someone left the company and you do not know which admin passwords they knew, treat it as a privileged-access incident: first remove their access and active sessions, then rotate shared passwords in this order: identity provider, email, domain/DNS, cloud hosting, code repository, database, and payment/third-party services. The single most likely gap is a shared admin login or an old password stored in a team vault, browser, or deployment script that was never rotated. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon and HR tells you a team member left last week. Then someone asks, "Do we know which admin passwords they had?" Nobody is sure. You know they touched the website, DNS (the system that points your domain to the right server), hosting, and maybe the shared mailbox. There is no obvious outage yet, but you need to reduce risk fast without locking out your current team or breaking production.

Symptoms

• You cannot answer basic questions like "Who can still log in as admin?" or "Which shared passwords were changed after they left?"
• A former employee account still appears in one or more dashboards.
• Shared logins exist, such as admin@company.com, billing@company.com, or a single root/owner account.
• Passwords are stored in multiple places: browser autofill, a shared spreadsheet, chat history, old onboarding docs, or deployment notes.
• Audit logs show recent sign-ins from unfamiliar devices, IP addresses, or locations.
• You see security emails such as:

New sign-in from Chrome on Windows
Password changed successfully
New API token created
MFA disabled
Recovery email changed

• You find automation using old secrets, for example in CI/CD (build/deploy automation) variables, .env files, or hosting settings.
• Team members say things like "I think they knew the registrar password" or "they set this up years ago" but there is no inventory.

Likely causes

Step-by-step diagnosis

1. Contain the person first, not the systems. In your identity provider dashboard (e.g. Google Workspace Admin, Microsoft Entra, Okta), open Users → [former employee] and check whether the account is suspended, blocked, or deleted.

   • This is your problem if: the account is still active, still in admin groups, or still has MFA devices enrolled.
   • Jump to: Fixes → Former employee still has direct access through SSO/IdP or local admin account.

2. Check for active sessions and remembered devices. In the same admin console, open Security → Sessions, Devices, or Sign-in activity for that user.

   • This is your problem if: you see active web sessions, mobile sessions, app passwords, or trusted devices still present.
   • Jump to: Fixes → Active sessions, remembered devices, or app passwords still work after account disablement.

3. List your critical admin systems. Make a short list: email tenant, domain registrar/DNS, cloud hosting, code repository, database, password manager, payment provider, analytics, and support desk. Then open each dashboard and check Users, Members, or Admins.

   • This is your problem if: the former employee is still listed, or there is a shared owner/admin login with no named users.
   • Jump to: Fixes → Shared admin passwords were never rotated after staff changes.

4. Check recovery options before rotating passwords. In each critical system, open Account/Security → Recovery email, phone, backup codes, MFA methods.

   • This is your problem if: recovery email points to their mailbox, their phone number is listed, or backup codes are untracked.
   • Jump to: Fixes → Recovery paths still point to the former employee.

5. Check tokens and keys used outside the browser. In your code host and cloud provider dashboards, open Settings → Access tokens, SSH keys, Deploy keys, Service accounts, or API keys.

   • This is your problem if: there are tokens named after the former employee, old personal access tokens, or unknown keys with broad scope.
   • Jump to: Fixes → API keys, SSH keys, deploy tokens, or personal access tokens are still valid.

6. Check automation secrets last, because rotation can break production. In your hosting provider dashboard, open Environment variables, Secrets, or Configuration. If you have shell access, inspect app config.

   • This is your problem if: you find credentials for database, SMTP (mail sending), storage, or third-party APIs that may have been known or copied.
   • Jump to: Fixes → Secrets are embedded in servers, CI/CD, or .env files and were not rotated.

[HR notice] ---- 1. disable user ----> [IdP/SSO]
     |
     v
[Critical systems list] ---- 2. check admins ----> [Dashboards]
     |
     v
[Sessions/devices] ---- 3. revoke ----> [Active logins]
     |
     v
[Tokens/keys] ---- 4. rotate ----> [Automation]
     |
     v
[Recovery options] ---- 5. fix ----> [Password resets]

Fixes

Former employee still has direct access through SSO/IdP or local admin account

Use the provider dashboard first:

• Identity provider: Users → [user] → Suspend/Block/Delete
• Remove from admin roles: Groups/Roles → Admins → Remove member
• If the service has its own local users, also remove them there: Settings → Team/Members → Remove

If you manage Linux server access directly, remove SSH access:

sudo passwd -l formeruser
sudo usermod --expiredate 1 formeruser
sudo rm -f /home/formeruser/.ssh/authorized_keys

Verify it worked: the user no longer appears in admin/member lists and cannot sign in.

Shared admin passwords were never rotated after staff changes

Start with the highest-impact shared accounts in this order:

1. Identity provider super admin
2. Shared email/admin mailbox
3. Domain registrar/DNS
4. Cloud hosting/control panel
5. Code repository owner/admin
6. Password manager admin
7. Database admin
8. Payment and support tools

For each service, use Account/Security → Change password and generate a new unique password in your password manager.

If you use a password manager, move secrets into named entries like:

{
  "title": "Cloud Hosting - Production Owner",
  "owner": "Operations",
  "rotated_on": "2026-10-30",
  "shared_with": ["alice@company.com", "bob@company.com"]
}

⚠️ Rotating a shared password can break integrations, cron jobs, or scripts that still use it. Before saving the new password, search your docs, CI/CD variables, and hosting settings for that username.

Verify it worked: old password fails, new password works, and the new credential is stored only in your approved password manager.

Active sessions, remembered devices, or app passwords still work after account disablement

In each major service, revoke sessions from the security page:

• Security → Sessions → Sign out all sessions
• Security → Devices → Remove device
• Security → App passwords → Revoke all
• Security → Trusted browsers/devices → Clear

If you run your own app with server-side sessions, force logout by rotating the session secret. For a Node app:

openssl rand -base64 48

Then replace your session secret in the hosting dashboard under Environment variables and redeploy.

For Django:

python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"

Set the new SECRET_KEY only if you understand the app impact; otherwise rotate the dedicated session secret if your app has one.

Verify it worked: the former user is prompted to log in again everywhere, and app passwords no longer authenticate.

API keys, SSH keys, deploy tokens, or personal access tokens are still valid

In your code host and cloud dashboards:

• Settings → Personal access tokens / Access tokens → Revoke any token owned by the former employee
• Settings → SSH keys / Deploy keys → Remove unknown or personal keys
• Service accounts / API keys → Rotate keys used by automation

CLI examples if needed:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Use that fingerprint to match and remove the key from dashboards.

For Git deploy keys on a server, replace the key pair:

ssh-keygen -t ed25519 -C "deploy@company.com" -f ~/.ssh/deploy_key

Then add the new public key in your repository dashboard and update the private key wherever deployment runs.

Verify it worked: old token/key returns unauthorized or fails authentication, and deployment succeeds with the new one.

Recovery paths still point to the former employee

In every critical service, update:

• Recovery email to a shared monitored mailbox you control
• Recovery phone to a company-managed number, not a personal phone
• Backup codes: regenerate and store them in your password manager
• MFA methods: remove the former employee’s authenticator app or hardware key

Typical path: Account settings → Security → Recovery / MFA / Two-factor authentication.

Verify it worked: password reset emails and MFA prompts go only to current company-controlled channels.

Secrets are embedded in servers, CI/CD, or .env files and were not rotated

Open your hosting dashboard and rotate environment variables for sensitive services:

• DB_PASSWORD
• SMTP_PASSWORD
• AWS_SECRET_ACCESS_KEY or equivalent cloud secret
• STRIPE_SECRET_KEY or other payment keys
• SESSION_SECRET

If you have shell access, inspect common locations:

grep -R "PASSWORD\|SECRET\|TOKEN\|KEY" /var/www /srv /opt 2>/dev/null | head -50

⚠️ Rotating database, SMTP, or cloud secrets can cause immediate downtime if the app is not updated at the same time.

After rotating in the upstream service, update the app config and restart/redeploy. Example .env pattern:

DB_USER=app_user
DB_PASSWORD=NEW-LONG-UNIQUE-PASSWORD
SMTP_USERNAME=mailer
SMTP_PASSWORD=NEW-LONG-UNIQUE-PASSWORD

Verify it worked: the app stays healthy after restart, and logs no longer show authentication failures.

Prevention

1. Use named accounts, not shared logins. In each service, create individual admin users and remove generic accounts like admin@ where possible. Keep one break-glass (emergency) account in the password manager with MFA backup codes stored beside it.

2. Keep a privileged access inventory. Maintain a simple sheet or password-manager vault folder listing every critical system, owner, and last rotation date:

system,admin_url,owner,last_rotated,recovery_email
DNS,https://registrar.example.com,Ops,2026-10-30,it-admin@company.com
Hosting,https://cloud.example.com,Ops,2026-10-30,it-admin@company.com

1. Add an offboarding checklist with forced session revocation. Include these exact actions: disable IdP account, remove admin roles, revoke sessions, revoke tokens, remove MFA methods, rotate shared passwords, update recovery options.

2. Move secrets into a password manager and CI/CD secret store. Do not keep credentials in chat, docs, or personal browsers. For apps, reference environment variables instead of hardcoding:

DATABASE_URL=${DATABASE_URL}
SMTP_PASSWORD=${SMTP_PASSWORD}

1. Alert on privileged changes. Turn on email or webhook alerts for events like new admin added, MFA disabled, recovery email changed, API token created, and password changed. Most major providers expose this under Security, Audit log, or Notifications.

2. Rotate on role change, not just on incident. Set a recurring calendar task every 90 days for shared admin credentials that cannot yet be eliminated, and rotate immediately after any departure or contractor end date.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.