The Security Tasks Everyone Forgets During Offboarding

Most companies handle the obvious offboarding steps: disable the email account, collect the laptop, revoke building access. The problem is the less obvious steps. SSH keys on production servers. Personal access tokens in GitHub. OAuth grants that persist after SSO is disabled. Shared passwords in a vault that were never rotated.

These are the gaps that create security incidents. A departing employee does not need to be malicious for this to matter. Unrevoked credentials are an attack surface. If that employee's personal device is compromised six months later, the attacker inherits every credential you never cleaned up.

SSH keys

Engineers add SSH keys to servers, jump hosts, and Git providers. Over time, a single developer might have SSH keys deployed across a dozen systems. When they leave, the keys stay unless someone actively removes them.

The problem is inventory. Most companies do not maintain a central list of where each employee's SSH keys are deployed. The key is added during setup and forgotten. Six months later, nobody knows which servers have a former employee's public key in their authorized_keys file.

What to do:

• Remove SSH keys from GitHub, GitLab, and Bitbucket accounts before disabling the accounts themselves.
• Audit authorized_keys files on production servers and jump hosts. If you use a configuration management tool (Ansible, Puppet, Chef), the key should be managed there and removable centrally.
• If you use SSH certificate authorities (like Smallstep or Vault), revoke the user's certificate. This is cleaner than hunting individual keys.

Personal access tokens and API keys

GitHub personal access tokens, Jira API tokens, AWS access keys, GCP service account keys. These are long-lived credentials that often outlast the employee who created them. Unlike SSO-backed sessions, they do not expire when you disable the user's identity provider account.

The risk is significant. A GitHub personal access token with repo scope gives full read/write access to every repository the employee could access. If that token was stored in a CI/CD pipeline, a local config file, or a password manager the employee takes with them, it remains functional until explicitly revoked.

What to do:

• Revoke all personal access tokens in GitHub, Bitbucket, and other source control platforms.
• Rotate AWS access keys and GCP service account keys that the employee had access to.
• Check CI/CD pipelines for stored credentials created by the departing employee. Replace them with new credentials owned by a service account.
• Review Jira and Confluence API tokens. These persist independently of SSO status.

OAuth grants and connected apps

Employees connect third-party apps to company services: GitHub Apps, Slack integrations, Jira OAuth connections, Google Workspace third-party access. These OAuth grants often persist after the employee's account is disabled.

A common scenario: an engineer connects a personal CI tool to the company GitHub org. They leave. The OAuth grant remains, and the tool still has access to company repositories through the departed employee's authorization.

What to do:

• Review OAuth applications authorized by the departing employee in GitHub, Google Workspace, and Slack.
• Revoke third-party app access grants tied to their account.
• Check for GitHub Apps installed under their account that have organization-level permissions.

Shared credentials and secrets

Teams share credentials. Database passwords, API keys for third-party services, admin passwords for SaaS tools that do not support SSO. These live in password managers (1Password, Vault, LastPass) or sometimes in environment variables, config files, and Slack DMs.

When someone leaves, every shared secret they had access to should be rotated. This is the most frequently skipped step because it is the most tedious. Rotating a database password means updating every service that connects to that database. Nobody wants to do this on a Friday afternoon when someone's last day happens to be.

What to do:

• Audit the departing employee's access in your secrets manager. Identify every shared credential they could view.
• Rotate credentials on a priority basis: production database passwords first, then service account tokens, then shared tool passwords.
• If your team stores secrets in environment variables or .env files, update and redeploy affected services.

Cloud infrastructure access

AWS IAM users, GCP IAM bindings, Azure RBAC assignments. Cloud providers have their own identity layers that may not be fully connected to your SSO. Even with SSO federation, some access may have been granted directly (an IAM user with console access, or a service account key downloaded to a local machine).

What to do:

• Remove IAM users and revoke direct access in AWS, GCP, and Azure.
• Review IAM role assumptions. If the employee assumed a role with elevated privileges, verify those temporary credentials have expired.
• Check for service account keys that were generated and downloaded. Delete them and reissue to current team members.
• Audit CloudTrail, GCP audit logs, or Azure Activity Logs for the employee's account to identify any access patterns you might have missed.

Code ownership and deploy access

This is less about security and more about operational risk. If the departing employee was a CODEOWNERS entry, a required reviewer, or the only person with deploy access to a specific service, their departure creates a gap.

What to do:

• Update CODEOWNERS files in all repositories where the employee was listed.
• Reassign required reviewer status in branch protection rules.
• Transfer ownership of any deployment pipelines or release processes they managed.
• Document any operational knowledge that was not previously written down (runbooks, incident procedures, escalation paths).

Making this repeatable

The reason these tasks get skipped is not that people do not know about them. It is that they are not in the checklist. If your offboarding process is a mental list or a Google Doc that has not been updated since 2023, security tasks will be missed.

The fix is a structured checklist that includes every security task, assigned to the right person, with a due date of the employee's last day or sooner. The Engineering Offboarding template in TeamOps includes all of the above. For the broader offboarding process including HR and legal tasks, see the full offboarding checklist.