Safeguard
Security Guides•

Offboarding checklist for identity, access and shared secrets

When someone leaves, disabling SSO is not enough. A checklist covering sessions, tokens, shared secrets, MFA devices and service accounts they owned.

Safeguard Security Team
3 min read

Disabling a leaver's SSO account is the first step, not the last. Also end active sessions, revoke tokens and keys they created, rotate shared secrets they could read, remove their MFA devices and reassign any service accounts they owned. Do it the same day, and keep a record.

Step 1: cut access at the identity provider

  • Disable the account and end all sessions.
  • Remove from groups that grant access to repos, cloud accounts and admin tools.
  • If the apps keep their own accounts, remove those too. SSO removal does not delete local accounts or API tokens inside the app. See SAML vs OIDC.

Step 2: tokens and keys they created

List personal access tokens, API keys, SSH keys and OAuth grants tied to the person. These often outlive the account. Revoke them, then check what broke so you can reissue to a service identity.

Step 3: shared secrets they could read

OWASP warns against giving engineers blanket access to all secrets and against sharing one credential across users or services. If your setup did either, the leaver knows values that are still valid. Rotate those, starting with the most privileged. Use the dual credential pattern to avoid outages.

A fair rule: rotate secrets the person could directly view in a manager, a CI variable page or a shared vault. For a secret they only used indirectly through a service, rotation is lower priority.

Step 4: devices and recovery

  • Remove their authenticators and passkeys from systems you control.
  • Remove them as a recovery contact or approver for others.
  • Collect hardware security keys.

Step 5: owned systems

Reassign service accounts, scheduled jobs, webhooks and shared mailboxes whose owner field names the person. OWASP's guidance to record ownership on each secret is what makes this step quick.

Step 6: check the logs

Look at their activity for the last weeks, plus any access after the exit time. Log secret requests and usage, as OWASP recommends, so you can answer what they touched.

Keep evidence

Auditors often sample leavers. Note the time the account was disabled, who did it and which secrets were rotated. See MFA and training evidence auditors sample.

If you want your policies enforced in the pipeline, Safeguard offers policies, gates and guardrails, and agent identity for non-human accounts. You can also run a free scan at gold.safeguard.sh/scan.

Automate what you can. Tie the checklist to your HR system event so it starts without anyone remembering, make each step a ticket with an owner, and report the time between the exit date and completion. The measure that matters is how long a former employee's access remained live, so track it and aim to shorten it each quarter. Review the process after every departure of someone with privileged access.

Quick check

Do we rotate everything when anyone leaves?

No. Rotate what they could read directly, starting with the most privileged, and use ownership records to find the rest.

What about contractors?

Treat them the same, and set an end date at the start so access expires by default.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.