Deprovision a Departing Employee Without Breaking Production

For: Engineering manager or CTO at a 20–80-person B2B SaaS company who just got a resignation letter from a backend engineer with admin-level access to production infrastructure, and needs to revoke everything safely before the last day without taking down the service or discovering six months later that a personal AWS key is still attached to a live Lambda

The dangerous part of offboarding a senior backend engineer is not deleting their IAM user. It is the personal access token they generated eighteen months ago that is still signing requests from a production Lambda, the Datadog API key tied to their email that pages the on-call rotation, and the GitHub PAT baked into a CI job nobody has touched since the last reorg. Revoke those in the wrong order and you will take down the service the moment you think you finished the offboarding. This playbook is how to run the sequence safely.

It applies to a specific situation: a 20–80-person B2B SaaS company, a backend engineer with admin-level access to AWS/GCP, GitHub org owner or maintainer, prod database credentials, and probably root access to several third-party SaaS tools. They just resigned. You have a two-week window, maybe less. You want them to leave clean, and you want to sleep on the Sunday after their last day without wondering what is still running under their name.

The core insight before you start

The outage risk in engineer offboarding is almost never the IAM user deletion. It is the personal API keys, service accounts, and OAuth tokens the departing engineer created under their own identity that are silently embedded in running infrastructure. The revocation itself does not break production — the audit you skipped before revoking is what breaks production.

So the sequence matters. You inventory first, migrate ownership second, revoke third. Do it in any other order and you are gambling.

Step 1: Freeze the surface area before you tell anyone else

The moment you accept the resignation, before HR sends the all-hands note, do two things. First, disable the ability for the departing engineer to create new long-lived credentials. Second, snapshot the current state of everything they touch.

Concretely:

• In AWS IAM, attach a deny policy to their user that blocks iam:CreateAccessKey, iam:CreateUser, iam:CreateRole, and sts:GetFederationToken. Leave everything else alone for now.
• In GitHub, if they are an org owner, downgrade to member with maintainer rights on the repos they own. This blocks new PAT scopes at org level.
• Export a full list of their current access keys, SSH keys, GPG keys, and personal access tokens. In AWS: aws iam list-access-keys --user-name. In GitHub: the audit log filtered by actor.
• Pull the last 90 days of CloudTrail events for their IAM principal. You want to know what they actually used, not what they theoretically had access to.

Anti-pattern: Announcing the departure company-wide before you have the audit trail exported. If the engineer is leaving on bad terms — even 5% odds — you want the forensic record locked before they know you are watching.

You'll know this step is done when you have a text file listing every access key ID, every SSH key fingerprint, every PAT, and every third-party SaaS admin session they hold, plus the CloudTrail events showing which of those they actually used in the last quarter.

Step 2: Hunt for personal credentials embedded in production

This is where offboarding actually gets hard, and it is the step most teams skip. Your goal: find every place the departing engineer's personal credentials are running production code paths.

Search in this order, because this is roughly the order of blast radius:

1. Lambda environment variables and Secrets Manager. Grep every Lambda's env vars and every secret for the string patterns of their known access key IDs (AWS keys start with AKIA). Also search for their email address — you would be surprised how many engineers hardcode alerts_to=jane@company.com in a config.
2. CI/CD secrets. GitHub Actions secrets, CircleCI contexts, GitLab CI variables. Look for anything named JANE_TOKEN, DEPLOY_KEY_JANE, or generic names like GH_PAT that were last rotated by the departing engineer.
3. Kubernetes secrets and ConfigMaps. kubectl get secrets --all-namespaces -o yaml and grep for the key prefixes.
4. EC2 user data and launch templates. These are often forgotten. Old auto-scaling groups can bootstrap with credentials embedded in user data.
5. Third-party integrations. Datadog, Sentry, PagerDuty, Segment, Stripe (test mode keys especially), Vercel, Cloudflare — any SaaS the engineer wired up. Check who owns the API key and who receives the webhooks.
6. Scheduled jobs and cron. EventBridge rules, GitHub Actions schedules, cron on any bastion or utility host. These fail silently for days before anyone notices.

For each hit, record: where it lives, what identity it uses, what it does, and what the blast radius is if it stops working at 2am on a Saturday.

Anti-pattern: Trusting your secrets manager as the source of truth. The whole point of this hunt is finding the credentials that are not in your secrets manager. If everything went through Vault or AWS Secrets Manager cleanly, you would not need this playbook.

You'll know this step is done when every hit from your grep has an owner assigned — either it will be rotated to a service account, or it will be deleted, or it will be reassigned to another human. No hit is left as "we'll deal with it later."

Step 3: Migrate ownership of every personal-key resource to a service identity

Now you do the actual work. For each personal credential you found in Step 2, you create a replacement that is not tied to a human, deploy the replacement, verify it works, and only then remove the original.

The pattern for each one:

• Create a new IAM role, service account, or bot user with the minimum permissions the workload actually uses (check CloudTrail for the last 90 days — do not just copy the departing engineer's permissions).
• Deploy the new credential to a canary environment or a single replica. Watch metrics for at least one full traffic cycle — usually 24 hours for a B2B SaaS, longer if there are weekly batch jobs.
• Roll out to the full workload. Keep the old credential live but unused for another 24–48 hours as a rollback.
• Only then, revoke the old credential.

For SaaS tools where the login is tied to the engineer's email, either transfer ownership to a shared team account (billing-owner@, ops@) or invite a replacement admin and demote the departing engineer to member. Do not just delete their user — half these tools will delete the associated integrations with it.

Anti-pattern: Big-bang rotation on the last day. If you rotate twenty credentials in one afternoon and something breaks at 3am, you have no idea which rotation caused it. Rotate incrementally over the notice period, one workload at a time.

You'll know this step is done when every production code path that used to authenticate as the departing human now authenticates as a named service identity, and you have at least one clean traffic cycle of metrics proving it.

Step 4: Rotate the shared credentials nobody wants to talk about

Every engineering org has them. The shared prod database read-only password in 1Password. The root Postgres password. The Stripe live-mode API key everyone copy-pasted into their local .env two years ago. The AWS root account password.

The rule is simple: if the departing engineer knew it, rotate it. Not because you distrust them personally, but because you have no idea where they wrote it down, whose laptop they synced it to, or which former teammate they shared it with over Slack DM in 2022.

Priority order:

1. Anything with financial blast radius: Stripe live keys, AWS root, domain registrar, DNS provider.
2. Anything with data blast radius: prod database superuser, S3 bucket keys for customer data, backup encryption keys.
3. Anything with identity blast radius: Google Workspace super admin, Okta admin, GitHub org owner.
4. Everything else in the shared vault they had access to.

For each rotation, you want a two-person process: one person rotates, one person verifies the new value works and updates the vault entry. Do not let one person do both in a hurry.

Anti-pattern: "They were trustworthy, we don't need to rotate." This is not about trust. It is about the fact that a shared credential the departing person knew is now, by definition, no longer a secret. If it leaks in six months from a source you cannot trace, you will not know whether it was them, their former laptop, or someone they shared it with.

You'll know this step is done when the shared vault has a rotation timestamp newer than the resignation date on every entry the engineer had access to.

Step 5: Revoke identity, in the right order

Only now do you actually delete the human's access. The order matters because some revocations invalidate your ability to do others.

1. Revoke active sessions first. In your SSO (Okta, Google Workspace, Azure AD), kill all active sessions. This immediately logs them out of everything federated.
2. Disable the SSO user. Do not delete — disable. You may need to log in as them for a forensic question in six months, and deleting the SSO identity often cascades in ways you cannot undo.
3. Revoke IAM access keys, then delete the IAM user. AWS keys first via aws iam delete-access-key, then the user.
4. Revoke GitHub access. Remove from org, revoke all PATs (you already inventoried them), revoke SSH keys, revoke authorized OAuth apps.
5. Revoke VPN and bastion access. If you use Tailscale, Cloudflare Access, Teleport, or a SSH bastion — kill their cert or user there. This is often forgotten because it lives outside the SSO umbrella.
6. Revoke SaaS admin sessions. For every SaaS tool, either force logout or delete the user (after Step 3 has migrated ownership).

Keep the mailbox live in read-only mode for at least 30 days, forwarding to their manager. Password reset emails from forgotten integrations will surface here — this is one of your last chances to find credentials Step 2 missed.

Anti-pattern: Deleting the mailbox on day one. Half the time you discover a stray SaaS account because a billing email or password-expiry notice hits the forwarded mailbox two weeks later.

You'll know this step is done when the departing engineer can walk into the office, sit at their old desk, open a laptop, and log into precisely nothing.

Step 6: Verify by trying to break in

Do not trust your own checklist. Verify.

• Attempt to authenticate as the departing user in every system on your list. Every failed login should be logged and confirmed.
• Run your CloudTrail query again 48 hours after revocation. Any activity from their IAM principal after revocation time is a red flag — usually a stale credential you missed.
• Check GitHub audit log for actions attributed to their account after the revocation timestamp.
• Ask another engineer — someone who was not doing the offboarding — to spend one hour trying to find any remaining access. Fresh eyes catch what the primary person missed.

You'll know this step is done when you have written proof of failed authentication for every access vector, and 48+ hours of clean audit logs post-revocation.

Step 7: Update your runbooks so the next one is boring

Everything you learned in Step 2 about where personal credentials were hiding — that is a bug in your platform, not a fact of life. Before you close the ticket:

• Add a pre-commit hook or CI check that blocks IAM access keys from being committed. gitleaks or trufflehog in CI.
• Move any workload still using long-lived AWS keys to IAM roles (for EC2/ECS/Lambda) or OIDC federation (for GitHub Actions). Long-lived keys are the root cause of most of what you just cleaned up.
• Require that every third-party SaaS integration is owned by a shared mailbox, not a person, at setup time. Add this to your onboarding checklist so new hires do it right.
• Write down the offboarding sequence you just ran. The next time you do this, it should be a two-hour execution, not a two-week hunt.

You'll know this step is done when a new engineer joining next month cannot create a personal long-lived credential that would become tomorrow's offboarding landmine.

Failure modes I have seen

The silent Lambda. Engineer leaves, IAM user is deleted, three weeks later a nightly data export stops running. Turns out it authenticated with the engineer's personal key, no alarms because the Lambda just returned early on auth failure. Customer noticed the missing weekly report before the team did.

The Datadog blackhole. Departing engineer was the API user for the Terraform-managed Datadog monitors. Key gets revoked. Next Terraform apply wipes half the monitoring config because the provider authenticates as a now-invalid user and gets partial responses. On-call rotation stops paging for a real incident 11 days later.

The Stripe webhook. Engineer set up the Stripe → internal-service webhook using their personal Stripe login. Ownership never transferred. Six months later someone rotates the webhook signing secret, nobody knows where the current one lives because it was in the departed engineer's password manager.

The forgotten bastion. SSO revoked, IAM revoked, GitHub revoked. But the SSH bastion had a local authorized_keys entry from before SSO was rolled out. Discovered nine months later during an unrelated audit.

The shared root password nobody rotated. The AWS root account password was in the shared vault. Engineer left on good terms, nobody rotated it. Two years later, unrelated breach at a former colleague's personal email exposes a synced password vault. Attackers try the AWS root login. It works.

Every one of these is preventable by running Steps 2 and 4 without shortcuts.

How CodeNicely can help

Most of the offboarding pain in a growing SaaS team is a symptom of platform debt: too many long-lived personal credentials, too many SaaS tools wired up by individuals, no clean service-identity story. If you are hitting this problem repeatedly, you probably need the underlying platform tightened, not just a better checklist.

The engagement closest to this pattern is GimBooks, a YC-backed fintech accounting SaaS where we worked on the production platform under real compliance pressure — the kind of environment where a stray credential is not just an operational risk but a regulatory one. The work involved rationalizing access patterns, moving workloads off personal credentials onto service identities, and building the kind of audit trail that survives an SOC 2 review. If your resignation letter just surfaced how much of your production runs on human-owned keys, that is the conversation to have. See also our digital transformation and services overview for the broader platform work.

Frequently Asked Questions

How long should we keep the departing engineer's email account active?

Minimum 30 days, ideally 60–90, in read-only forwarding mode to their manager. Password-reset emails from forgotten SaaS integrations often surface weeks after the departure. Deleting the mailbox immediately means you lose the ability to find those trailing accounts and often the ability to recover them without contacting each vendor's support.

Do we really need to rotate shared credentials if the engineer left on good terms?

Yes. This is not a trust question. A shared credential known by someone outside the current team is, by definition, no longer under your control — you cannot audit where they stored it, which devices synced it, or who they shared it with informally. If it leaks eighteen months from now, you will have no way to trace the vector. Rotation is cheap; forensic ambiguity is expensive.

What's the single most-missed access vector during engineer offboarding?

Personal API keys embedded in production infrastructure — usually AWS access keys in Lambda environment variables, GitHub PATs in CI secrets, or third-party SaaS API keys owned by the engineer's personal account on that platform. These do not show up in your SSO or IAM console because they were created outside the paved path. Grepping CloudTrail and your secrets stores for the departing engineer's key prefixes and email address is the only reliable way to find them.

Should we revoke access before or after the engineer's last day?

Incrementally over the notice period, with the identity revocation itself concentrated at end-of-day on the last day. Migrating ownership of personal-key workloads should happen throughout the notice period so you can catch breakage while the original owner is still available to help debug. Big-bang revocation on day one is only appropriate if there is a specific risk signal.

Can CodeNicely help us audit our current credential hygiene before someone leaves?

Yes — a platform audit that surfaces personal-credential dependencies, long-lived keys, and unmanaged SaaS ownership is a common first engagement. For a scoped assessment of your environment, contact CodeNicely for a personalized assessment based on your stack and team size.