How to revoke shared password access when someone leaves

Quick answer. To revoke shared password access cleanly when someone leaves: (1) revoke their account in your password manager — this rotates the affected vault keys and makes their cached ciphertext undecryptable, (2) rotate the underlying credentials they actually used (production passwords, API keys, deploy tokens) on the source tools — because they may have copied or memorized the values during use, (3) revoke any tool-specific access (GitHub org, AWS IAM, Slack workspace) where they signed in with their own account. Step 1 is instant; step 2 takes longer but is the part that actually closes the leak. Start free with LitePassword.

The mistake almost everyone makes

When a teammate or contractor leaves, most teams do one of these things:

Nothing. (You meant to but forgot. It’s been three months.)
Remove them from Slack and the password manager. Done in five minutes.

Neither is enough.

Removing them from the password manager closes their ability to re-read credentials from your vault. It does not invalidate the credentials they already used. If they copied your Stripe restricted key into their local notes app a month ago, that value is still valid until you rotate it on Stripe.

The complete offboarding is two steps, in this order.

Step 1 — Revoke in your password manager

In LitePassword:

Users page → find the person’s row.
Row menu → Revoke Access.
Done. Vault keys for every vault they had access to rotate automatically. Their cached ciphertext on any device becomes undecryptable.

This is the first step because it’s instant. From this moment, the leaving person cannot read new credential values out of your vault.

If you only need to remove access to specific vaults (e.g., they’re rotating to a different project), use Manage Vault Access instead and toggle off only the vaults in question.

Step 2 — Rotate underlying credentials

This is the step most people skip. Here’s why it matters:

While the person had vault access, they pulled credential values into the actual tools — typed them into AWS console, pasted them into Stripe configuration, copied them into local scripts. The vault stores the password; the brain stores the memory of the value.

After you revoke vault access, they can’t fetch new values. But the values they already remember are still valid until you rotate.

For high-value credentials, rotate now:

AWS access keys → IAM → generate new, deactivate old.
Stripe restricted keys → roll in Dashboard.
GitHub PATs / deploy keys → regenerate in Settings.
Database passwords → rotate on the database.
Production SSO admin accounts → reset.
Any production credential a leaving engineer touched.

For low-value credentials, you can defer or skip:

A SaaS tool’s login they used once.
A marketing analytics login.
Credentials that, if known, can’t be used to escalate or extract data of meaningful value.

The rule of thumb: rotate everything that touches money, customer data, or production infrastructure. Defer the rest if it’s high effort.

Step 3 — Tool-specific revocation

The password manager handles the vault layer. Each tool with its own auth system needs its own revoke:

GitHub: Org → People → Remove from organization. Revoke any PATs they generated under their own account if they had org-wide permissions.
AWS IAM: Deactivate (don’t delete) their IAM user. Preserves CloudTrail history; prevents new authentication.
Google Workspace / Microsoft 365: Suspend the account first, fully delete after 30 days. Forward email to a manager during the suspension.
Slack: Deactivate the account (not delete — keeps message history).
Linear / Notion / etc.: Remove from workspace. Each tool’s admin handles this.

The minimum acceptable timeline

Within 1 hour of departure: Revoke vault access. Deactivate tool accounts (Slack, Google Workspace, GitHub, AWS console).
Within 24 hours: Rotate all high-value production credentials they touched.
Within 1 week: Audit and clean up — anything you missed in the first two passes.
Within 30 days: Delete (not just deactivate) their accounts on tools you no longer need history for.

If you can’t get to step 2 in 24 hours, at least disable the credentials at the source where possible (e.g., disable IAM users, even if you haven’t yet rotated their long-term keys).

A common gotcha: cached credentials in CI/CD

Service accounts and CI/CD pipelines often store credentials in environment variables or secret managers (GitHub Actions secrets, Vercel env vars, etc.). When you rotate a credential, update every consumer of that credential in the same change window.

The pattern:

Generate the new credential.
Update it in every CI/CD environment that uses it (GitHub Actions, Vercel, your own infra).
Deploy.
Confirm pipelines work.
Deactivate the old credential.

Skipping step 4 means you deactivate the old credential and break production. Skipping step 5 means the old credential is still valid, which defeats the rotation.

What about people who refuse to give back their device?

Rare but real. The pattern:

Revoke everything you can server-side (vault, GitHub, AWS, Slack, etc.).
Force sign-out of all active sessions where the tool supports it (Google Workspace, AWS, Slack).
Rotate credentials they may have cached locally (production keys, deploy tokens).
If the device contains your company’s data and they won’t return it, that’s a legal matter — not a technical one.

The vault revocation step makes cached vault ciphertext undecryptable. The credential rotation step makes cached literal values invalid. Together they close the offline-data attack window.

Summary

Revoke vault access — instant, rotates keys, cached ciphertext useless.
Rotate underlying credentials on source tools — closes the cached-memory attack window.
Tool-specific revocation (GitHub, AWS, Workspace, etc.) — closes per-tool authentication.

Step 1 alone is incomplete. The two-step pattern is what actually closes the door.

Create your free LitePassword vault →