API key offboarding checklist

When someone leaves, their API keys often keep working. Here's how to find, reassign, rotate, and log every credential they owned — not just their SSO and laptop.

By The Fally team · Updated September 25, 2026

Short answer: revoking someone's SSO and laptop doesn't touch the third-party API keys they created or knew — those keep working. To offboard credentials, inventory every key they owned, reassign each to a living owner, rotate any value they could know, update anything that uses it, and log the whole handoff. The checklist below walks through it.

What “credential offboarding” means

Most offboarding runbooks cover human access: email, SSO, the laptop, the badge. Those are about stopping a person from logging in. Credential offboarding is the other half — the machine and API credentials that keep working whether or not that person can still log in.

The plain version: every secret that person could use, or was listed as owning, has to be found, handed to someone else, rotated if they could know its value, and recorded. SSO is about the door; this is about the keys they already cut.

Why this gets missed

API keys don't live in one place. They're scattered across .env files, CI variables, vendor dashboards, personal password managers, and chat threads — so there's rarely a single list to work from. SSO or IdP offboarding removes the person, but it never touches the vendor keys they created; a Stripe webhook secret keeps signing events long after its author's login is gone.

And ownership is usually informal. Two engineers can each believe they own “the Stripe webhook,” with no shared record of who actually does — until one of them leaves and the other turns out to be wrong.

The checklist

Work through these in order. The first few are about knowing what you have; the rest are about handing it off safely.

Freeze the scope. Confirm their last day, the vendors and systems they touched, and which teams they were on (Growth, Infra, and so on). You can't offboard what you haven't scoped.
Pull the inventory of what they own. List every API key or secret where they are the owner or the last person to rotate it. No inventory yet? Start a spreadsheet with name, vendor, purpose, environment, and owner — you'll reuse it for every future departure.
Separate production from staging. Handle production keys first. A leaked staging key is a nuisance; a leaked production key can move money or expose customer data.
Reassign ownership before you revoke anything. Pick a living owner on the same team so each key still has an accountable human. Reassigning first means you don't create an orphan the moment you remove the person.
Rotate values the departing person could know. Rotate anything they created, copied, or kept in a personal store. Keep the record — name, purpose, owner — and replace only the secret value.
Update runbooks, CI, and apps. Anywhere the old value is injected (CI variables, .env files, deploy configs) has to move to the new value, or the rotation takes production down.
Revoke leftover personal access at each vendor. Remove their personal seats, dashboard invites, and personal access tokens in Stripe, GitHub, AWS, and the rest. Team-owned keys and a person's own vendor login are different things — handle both.
Log the handoff. Record who transferred what, when, and who rotated what. If a question comes up later, you want a trail, not a memory.
Spot-check for orphans. Scan for any key with no owner, or a departed owner still attached. These are the credentials that quietly outlive people.
Close the loop. Get a sign-off from security or the eng manager that nothing the person owned is still orphaned. Then the offboarding is actually done.

Example walkthrough

Say Ava is leaving Acme. She's on the Growth and Infra teams, and the inventory shows she owns 12 credentials — a Stripe webhook secret, an AWS upload key, a Postmark sending key, and nine others across production and staging.

You reassign all 12 to Casey on the same teams, rotate the four production values Ava could have seen, and update the CI variables and deploy config that inject them. You remove Ava's personal Stripe and GitHub seats, and log every transfer and rotation. Finally you remove Ava from Growth and Infra and confirm nothing she owned is left without an owner. Fifteen minutes, and nothing of hers is still live.

Where a tool helps (and where process still matters)

Process works right up until someone creates a key without recording who owns it or what it's for. After that, you're reconstructing ownership from memory during the worst possible week. The durable fix is to make ownership a requirement at create time, not a cleanup task at offboarding time.

That's the job Fally does:

Purpose and owner are required to save a key — there's no anonymous credential to inherit later.
The offboard flow lists everything one person owns, so the inventory step is a click.
Reassign ownership in bulk to a living teammate.
Every transfer and rotation is written to an activity log.
Rotating a key replaces the value but keeps the name, purpose, and owner.

Fally isn't a vault and doesn't replace your secrets manager or cloud provider. If a value needs to be injected into a runtime, keep doing that where you do it now. Fally is the record of which keys exist, who owns each one, and what happens to them when someone leaves.

Frequently asked questions

Do we rotate every key or only production?

Start with production — rotate anything the person created, copied, or could have seen there first, because that's where a leaked value does the most damage. For staging and development, reassign ownership and rotate on a normal schedule unless the key also reaches production data.

What if we don't know who owns a key?

Treat it as orphaned. Don't delete it blindly — something may depend on it. Trace what uses it from your code, CI, and vendor dashboard, assign a living owner, then rotate it. Going forward, require an owner and purpose at the moment a key is created so it doesn't happen again.

Is revoking SSO enough?

No. SSO and IdP offboarding remove the person's ability to log in, but third-party API keys they created keep working independently of that login. A key in a .env file, a CI variable, or a vendor dashboard doesn't care that the person's SSO is gone.

How is this different from a secrets manager?

A secrets manager or vault stores and injects the value securely. Offboarding is a lifecycle question — who owned each key, what it's for, and whether it can be safely reassigned or rotated. You can have a vault and still not know which keys a departing person owned. Fally is the record that answers that; it doesn't replace your vault.

More guides are on the way — orphaned (“ghost”) API keys, and a secrets inventory playbook. In the meantime, the docs cover how Fally organizes every key by owner and purpose.

Make offboarding a click, not a scramble.

Fally keeps every API key tied to an owner and a purpose — so when someone leaves, you already know exactly what they had.

Start free