Engineer Offboarding Checklist: Tokens, Keys and Sessions, Not Just SSO

When a contractor with administrative access to CISA's code platform published plaintext credentials on a public GitHub profile, reported by KrebsOnSecurity on 18 May 2026, the story that followed was about cleanup. More than a week after GitGuardian's first notice, the agency was still invalidating and replacing exposed keys. The lesson applies to every team: the speed of your offboarding is the speed of your slowest credential.

This is a checklist for the day an engineer or contractor leaves, aimed at the credentials that single sign-on does not reach.

What's affected

Removing a person from the directory ends one kind of access. It does not end:

• Personal access tokens and SSH keys they created on code hosts and registries.
• Cloud access keys and service account keys in their name or created by them.
• Refresh tokens and browser sessions that are still valid.
• Secrets they know or can read, such as shared passwords, CI variables, and kubeconfigs.
• Access through forks, local copies and personal accounts.

GitHub's own page on removing an organization member is a good example of the limits. A removed member loses access to private forks of the organization's private repositories, but they may keep local copies they can no longer sync, and a fork held by another organization may keep granting access. GitHub's page says you are responsible for making sure they delete confidential information. Membership data is kept for three months so an accidental removal can be restored.

How to check if you're exposed

Build the list before the person leaves. For each engineer, answer these questions from systems, not from memory.

1. Which cloud users and keys carry their name? AWS: aws iam list-access-keys --user-name NAME, then aws iam get-access-key-last-used --access-key-id KEYID.
2. Which service account keys did they create? GCP: search organization-wide for keys older than a date with Cloud Asset Inventory.

gcloud asset search-all-resources \
    --scope="organizations/123456789012" \
    --query="createTime < 2026-01-01" \
    --asset-types="iam.googleapis.com/ServiceAccountKey" \
    --order-by="createTime"

3. Which tokens do they hold on your code host? For a GitHub organization, open Settings, then Personal access tokens, and review both the Fine-grained tokens and Tokens (classic) tabs.
4. Which secrets can they read? Check CI variables, vault policies and shared password folders.
5. Where could their identity still sign in? Identity provider, VPN, cloud console, registries, monitoring and ticketing.

What to do now

Work in this order, on the day, and record the time of each step.

1. Revoke sessions first. In Microsoft Entra, Revoke-MgUserSignInSession -UserId $userId resets the sign-in time and invalidates the user's refresh tokens and browser session cookies. Microsoft warns there can be a delay of a few minutes. Disable the account in the same sitting.
2. Remove from the identity source, not just the app. If GitHub membership is managed by an identity provider or SCIM, remove the user there. GitHub's doc says to do this instead of removing them manually.
3. Cloud keys. Follow the vendor procedure so you do not cause an outage. AWS says to create the second key, update applications, check last used, set the old key to Inactive, confirm everything works, then delete. Google says the same shape: identify, create, replace, disable, delete. AWS lists "when an employee leaves your company" as a time to update access keys.
4. Tokens they created. Revoke personal tokens they used for automation, and move that automation to a GitHub App or an OIDC role. If a token is found outside your control, the credential revocation API can revoke it in bulk without authentication.
5. Rotate what they could read. Shared passwords, CI secrets, kubeconfigs and app private keys. Treat access to the secret as access to the value.
6. Hand over ownership. Reassign repositories, runbooks, cron jobs and on-call so nothing important depends on a disabled account.
7. Check forks and personal accounts. Ask the person to confirm in writing that company code and data are removed from personal accounts and devices, and confirm that no unapproved copy remains in your own org forks.
8. Review a few weeks later. Look at sign-in and audit logs for attempts using the old identity and for old keys that suddenly appear.

Why it matters

Offboarding failures are rarely malicious. They come from credentials with no owner on file. The CISA case shows the cost of the opposite: when credentials sit in files nobody inventoried, replacing them takes longer than a week even with an outside party pointing at each one.

Two habits make this day easy. First, give every non-human credential an owner and an expiry, so a departure is a reassignment, not a search. Second, prefer identities that expire by design: OIDC roles for CI, short-lived tokens, and GitHub Apps rather than a person's token.

Contractors need the same treatment on a fixed end date. The access should expire unless someone renews it.

Try it yourself

Pick one engineer who joined at least a year ago and run steps 1 to 5 of "How to check" on paper. Count the credentials you find that nobody else has the owner for. That number is your offboarding gap.

Quick check

Sources

• Lawmakers Demand Answers as CISA Tries to Contain Data Leak (KrebsOnSecurity, 18 May 2026)
• Removing a member from your organization (GitHub Docs)
• user: revokeSignInSessions (Microsoft Graph, Microsoft Learn)
• Update access keys (AWS IAM User Guide)
• Key rotation (Google Cloud IAM docs)
• Credential revocation API (GitHub Docs)