When a Developer Leaves: How to Find and Revoke API Keys, Tokens, and Developer Credentials

When a developer quits, disabling their Google or Okta account is not enough. API keys, personal access tokens, and service credentials live outside identity providers, they keep working long after the person's last day. This guide covers how to find every credential type your departing developer created, why the revocation order matters, and how to close the loop in your HR offboarding flow without an IT team.

Why Developer Offboarding Is a Different Problem

Regular employees access SaaS tools through SSO. Disable their IdP account and most access disappears. Developers are different. Over a typical engagement at a 20-person startup, a senior engineer will have created: GitHub personal access tokens scoped to your organization's repos, AWS IAM access keys with production permissions, Stripe restricted keys to test payment flows, Slack bot tokens for internal tooling, Vercel deployment tokens, and local .env files with credentials from every service they ever ran locally.

None of these are managed by SSO. Each credential stays valid indefinitely until someone explicitly revokes it. The average startup developer has created credentials they've forgotten about themselves. You cannot ask them to enumerate everything on their way out, you need a systematic search.

Step 1: Inventory Developer Credentials Before You Start Revoking

You cannot revoke what you do not know exists. Start with a rapid audit across the systems where developer credentials live.

GitHub: Organization owners can view all personal access tokens (fine-grained and classic) that can access the org at Settings → Developer Settings → Personal access tokens. Classic tokens are particularly risky: GitHub cannot enumerate them per-owner at the org level. Remove the developer from the organization entirely, then audit any GitHub Actions secrets that may reference their personal tokens.

AWS IAM: Go to IAM → Users → [username] → Security credentials. Look for access keys (AKID values), check last-used dates, and check for MFA devices registered to their personal phone number. If they set up any IAM roles with trust policies pointing to their user, those need to be updated too.

Stripe: Navigate to Developers → API keys. Look for restricted keys created under their name. Also check for webhooks pointing to services they personally owned.

Vercel, Heroku, Render: Each platform has a team tokens section. Remove the user from the team, then check for any deploy hooks or personal tokens they created on behalf of the project.

Slack: Check Settings & Administration → Manage apps for bot apps they installed and Tools → Access Logs for recent API activity. If they wrote internal Slack bots, those bots may authenticate with tokens tied to their Slack user account.

Supabase, PlanetScale, Neon: Database services common in early-stage teams have service-role API keys and personal API tokens separate from team membership. Check project settings for tokens created by the departing user.

The local .env problem: Any credential they ever needed to run your app locally is probably sitting in a .env file on their laptop, and possibly in a committed file in a private repo. Treat credential rotation as mandatory after any developer departure, not optional.

Step 2: Revoke in Priority Order

The order matters because some credentials carry more blast radius than others.

Tier 1: Billing and payments (revoke first, within minutes)

• Stripe: revoke restricted keys, remove from team, check for billing portal access
• AWS root account: verify they never held root credentials; if they were the AWS account owner, initiate account ownership transfer immediately

Tier 2: Code and infrastructure (revoke within the first hour)

• GitHub: remove from organization, then explicitly revoke any PATs visible at the org level; rotate GitHub Actions secrets that embed their tokens
• AWS IAM: disable then delete their IAM user; rotate any access keys immediately; check for IAM roles with trust policies pointing to their user account
• Vercel/Heroku/Render: remove from team, delete deploy hooks

Tier 3: Communication and monitoring (revoke same day)

• Slack: deactivate account; revoke bot tokens for apps they installed
• PagerDuty, Datadog, New Relic: remove user, check for API keys created under their account
• Twilio, SendGrid, Postmark: check sender identities and API keys scoped to their account

What SSO Doesn't Kill

The most common mistake after developer offboarding: disabling the IdP account and assuming the job is done. It is not.

GitHub PATs survive SSO deactivation. GitHub can require SAML SSO authorization for fine-grained tokens, but classic personal access tokens bypass this entirely. A developer can create a classic PAT that persists indefinitely regardless of SSO status. Even fine-grained tokens need explicit revocation at org → Settings → Personal access tokens; removing the user from the org alone is not enough.

AWS IAM access keys are not federated. When you use Google Workspace SSO for AWS, the SSO session expires on disable. But any IAM access keys (AKID/secret pairs) the developer created directly in IAM persist independently. You must delete the IAM user explicitly.

Committed credentials in repos. Run git log -p | grep -i "AKIA\|sk_live\|ghp_" across your codebase to check whether credentials were ever committed. Any credential found in git history should be treated as compromised and rotated immediately, even in private repos.

Step 3: Close the Loop in Your HR Offboarding Flow

Developer credential revocation is an IT task, but it must be triggered by an HR event, the termination record, and verified before the offboarding is marked complete.

The gap most startups fall into: the founder handles the HR side (final payslip, benefits, equipment return) while credential revocation is left to a fellow engineer who is also trying to ship. It happens partially, or not at all. Finding credentials you did not know existed is its own separate problem, the shadow IT offboarding guide covers the discovery method for unmanaged SaaS accounts that surface at departure.

Three ways to close the gap at a 5–30 person startup without an IT team:

1. Assign a dedicated offboarding owner. For developer departures, this should be the CTO or lead engineer, with a named checklist they sign off on before the termination is closed in your HR system.
2. Tie credential revocation to equipment return. When the developer hands back the laptop, check off AWS key deletion, GitHub org removal, and Stripe key rotation in the same 30-minute session. Physical handoff is the natural forcing function.
3. Use your HR platform to trigger the workflow. If your HR system tracks termination dates, set a T+0 reminder for developer credential revocation to run concurrently with equipment collection, not three days later.

For the broader multi-SaaS offboarding checklist, see How to Offboard an Employee Across 12 SaaS Tools When You Have No IT Team. For involuntary same-day departures where speed matters most, the immediate termination access revocation protocol covers the emergency sequence.

FAQ

Q: Does removing a developer from our GitHub organization revoke all their access? Removing a user revokes their membership and repo permissions, but it does NOT automatically revoke personal access tokens they created while a member. Classic PATs remain valid unless the user deletes them or you explicitly revoke them as an org owner via the token audit settings (Settings → Personal access tokens → Active tokens). Always audit and revoke tokens separately after removing someone from the org.

Q: What if the developer created AWS resources under a personal IAM user account? Resources created under their IAM user remain accessible via those credentials until the user is deleted. Disable the IAM user first so the access keys stop working, document what resources they owned, transfer ownership, then delete the IAM user. Never delete the user before auditing what they owned, some resources may have the IAM user baked into their permissions model.

Q: How do we handle API keys in .env files on their work laptop? Treat all credentials on a departing developer's laptop as compromised, regardless of whether the device was returned. Rotate every API key and secret they had local access to: new restricted keys for Stripe, new PATs for automation workflows, new IAM access keys under a service account. The cost of rotating is lower than the cost of a breach via a retained credential.

Q: What about credentials used by AI coding assistants? Tools like GitHub Copilot, Cursor, and Claude Code store API tokens locally in shell profiles or config files. Disabling the developer's SSO account does not revoke these. Wipe the work device and rotate any API keys that may have been stored in their local tool configuration.

Q: How do we verify a former developer no longer has active access? After revoking credentials, check AWS CloudTrail, GitHub's audit log (Settings → Audit log), and Stripe's event log for API activity originating from their former credentials. Any activity after the revocation date indicates a missed credential that still needs to be rotated.

Optserv Ties Developer Offboarding to Your HR Flow

Most HR tools record the termination event and stop there. The credential revocation work, the part that actually reduces risk, gets handed off by Slack message and tracked in a shared doc. Optserv connects the HR termination record to the offboarding workflow, including a developer credential checklist that gets assigned to the right engineering owner at T+0 with a sign-off audit trail. When the offboarding closes in Optserv, you know the access is gone, not just that the paperwork is done. See how Optserv handles offboarding →

Sources

• GitHub Docs: Reviewing and revoking personal access tokens in your organization
• AWS Documentation: Revoke IAM role temporary security credentials
• Palo Alto Networks: Top 3 IAM Risks in Your GitHub Organization
• passwork.pro: Employee offboarding: Guide to secure access revocation in 2026