Developer Access Lifecycle: Onboarding, Moving and Offboarding Engineers Without Leaving Credentials Behind

Engineers create more credentials than anyone else in the organisation, and most of them sit outside the identity provider that the leaver process switches off. A developer collects personal access tokens, SSH keys, cloud access keys, package registry tokens, CI secrets, signing keys and service accounts they set up for a project. Disabling the directory account removes very few of these. This guide applies the joiner, mover and leaver model to engineering roles: designing onboarding so credentials are short-lived and attributable from day one, handling team moves, and running an offboarding sweep that finds and transfers or revokes what the person created. It is for engineering managers, platform teams and identity teams. The general process is in the Joiner-Mover-Leaver Guide and the general leaver sequence in the Employee Offboarding Security Guide; this page goes deeper on engineering access only.

Key takeaways

• Design for offboarding at onboarding. Every credential an engineer can create should be short-lived, tied to their SSO identity or registered against them, so the leaver sweep can find it.
• Disabling SSO is not enough. Tokens, keys and registry credentials often keep working after the directory account is disabled; GitHub notes that revoking a credential's SAML authorisation does not delete the token or key itself.
• Separate personal from project credentials. Anything a service depends on must belong to a service identity with a team owner, not to the engineer who built it.
• Movers are the quiet risk. Engineers who change teams keep old repository, cloud and on-call access unless the mover process removes it.
• Prove the sweep. A leaver ticket should close only when each platform's credential report shows nothing active for that person.

Where engineers' credentials live

The Coupang Breach 2025 shows the cost of missing one row: a token signing key a former engineer kept after leaving was never revoked or rotated, and was later used to forge access tokens.

Onboarding engineers so offboarding works

• SSO everywhere it exists: connect source control, cloud consoles, CI, registries and SaaS tools to the identity provider, with SCIM where supported. See the SCIM Provisioning Guide.
• Federated cloud access, not IAM users: give engineers cloud access through federation and short sessions, for example AWS IAM Identity Center. See the AWS IAM Identity Center Guide.
• Token policies on day one: GitHub organisations can restrict classic personal access tokens, require administrator approval for fine-grained tokens (the default) and set a maximum lifetime per token type. Fine-grained tokens default to expiring within 366 days; classic tokens have no expiration requirement unless you set one. See the GitHub Personal Access Tokens Security Guide.
• Short-lived SSH: issue SSH certificates with a validity of hours from an SSO-backed CA instead of distributing static public keys to servers. See the SSH Protocol and Certificate Authority Guide.
• Pipelines use workload identity: CI jobs authenticate to cloud and registries with OIDC federation or trusted publishing, so no engineer's personal token sits in a pipeline. See the GitHub Actions OIDC Federation Hardening Guide and the npm Trusted Publishing and Provenance Guide.
• Register what cannot be federated: where a platform only supports static keys, record the key, its owner and its purpose in the secrets inventory at creation.
• Team-owned service identities: when an engineer creates a service account, bot or API key for a system, assign it to the team that owns the system, not to the engineer. See the NHI Ownership Guide.

Movers: changing teams and roles

Engineering moves are frequent and rarely trigger access changes. The mover process below is an NHI Mgmt Group recommendation.

1. Trigger: the HR or team change in the source of truth updates group membership in the identity provider within one working day.
2. Remove by default: repository teams, cloud accounts or projects, on-call rotations and production access tied to the old team are removed on the move date, with a grace period of no more than two weeks for handover, recorded with an end date.
3. Transfer ownership: service accounts, bots, keys and scheduled jobs the person owned for the old team are reassigned to a named owner in that team.
4. Review personal credentials: the engineer reviews their own tokens and keys and revokes those scoped to the old team's resources.
5. Confirm: the old team lead attests that access has been removed. See the Access Reviews Guide.

The engineering offboarding sweep

Run this in addition to the general offboarding sequence, starting the day notice is given for planned leavers and immediately for unplanned ones.

1. Freeze and capture: export the person's credential inventory from each platform before disabling anything, so you know what existed.
2. Find what they created: list service accounts, bots, API keys, deploy keys, webhooks, scheduled jobs and cloud resources created by the person, from audit logs and resource tags.
3. Transfer, then revoke: reassign anything a system depends on to a team-owned identity, rotate any secret the person could have seen (including shared team secrets), then revoke the person's own credentials.
4. Source control: remove the person through SCIM or the identity provider rather than manually where membership is managed that way, as GitHub recommends. Revoke their SSO-authorised credentials and active SAML sessions from the organisation's member view. Deploy keys belong to repositories rather than to the person, so review the keys they added and remove or replace them. Note that GitHub retains membership data for three months so a returning member can be reinstated, and removed members can keep local copies of code they cloned.
5. Cloud: delete IAM users and access keys, service account keys and role assignments held by the person. The AWS IAM credential report lists each user's passwords, first two access keys, MFA devices and last-used dates; check additional_credentials_info for users with more keys.
6. Registries and publishing: remove maintainer rights and revoke publish tokens on every package registry. See the npm Tokens Security Guide.
7. Servers and clusters: remove authorised keys from hosts and role bindings from clusters, or rely on certificate expiry where SSH certificates and OIDC are in use.
8. Signing and vault: rotate signing keys the person could access and revoke their vault tokens. Treat any key that lived on their laptop as exposed.
9. Verify and close: rerun each platform's credential report and confirm nothing active remains for the person before closing the ticket.

Platform-specific notes

• GitHub: organisation owners can view and revoke a member's linked SSO identity, active SAML sessions and authorised personal access tokens and SSH keys. Revoking an authorisation removes only the SSO authorisation, not the credential itself. For incident response the organisation's authentication settings can revoke SSO authorisations or, for Enterprise Managed Users, delete keys and tokens. Tokens that breach a maximum lifetime policy are blocked from the organisation but not revoked. See the GitHub Organisation Security Checklist.
• GitLab Self-Managed: administrators can block, deactivate, ban or delete users. Blocking stops sign-in and repository and API access while keeping data; a deactivated user is automatically reactivated if they sign in, so use block for leavers. Automatic deactivation of dormant users can be enabled with an inactivity period of at least 90 days. See the GitLab Tokens Security Guide.
• AWS: the credential report can be generated at most every four hours and covers IAM users only; federated users leave no IAM user entry, which is one more reason to federate. See How to find unused AWS IAM roles and access keys.

AI coding assistants and agents

Engineers increasingly connect AI coding assistants, IDE extensions and agents to repositories, cloud accounts and ticketing systems. These tools usually act with the engineer's own tokens or OAuth grants, so they belong in the lifecycle too.

• Onboarding: publish an approved list of AI tools and the connection method for each (organisation-approved app, scoped token or managed integration), so connections are visible and attributable.
• Movers: agent configurations often hold tokens for the old team's repositories and tools; include them in the mover review.
• Leavers: revoke OAuth grants and tokens issued to AI tools by the leaver, and check for agent configurations or Model Context Protocol server settings in shared repositories that reference their credentials. See the Shadow AI Discovery Guide.

Contractors, interns and temporary engineers

Contractors and interns often get the same engineering access as staff but leave on dates the identity team never hears about. Give them accounts with an end date set at creation, sponsor attestation every 90 days (our recommendation), and access to the minimum set of repositories. Where a contractor works in the supplier's own accounts on public platforms, require the supplier to use organisation-managed accounts or confirm removal at contract end. See the Orphaned and Dormant Accounts guide.

Small and large organisations

Detection and measurement

Alert on use of a leaver's tokens or keys after their leave date, new personal tokens created during a notice period, bulk repository clones by a leaver, and keys added to repositories by accounts about to be removed. See the GitHub Audit Log Detection Guide.

• Sweep completion time: time from leave date to verified zero active credentials across engineering platforms.
• Post-leave activity: credential uses after the leave date (target: zero).
• Orphaned service identities: service accounts, bots and keys whose owner has left.
• Static credential share: percentage of engineer access using federated or short-lived credentials rather than static keys.
• Mover clean-up: percentage of moves with old team access removed within the grace period.

Framework mapping

In ATT&CK, a former engineer's surviving cloud credentials map to T1078.004 Cloud Accounts.

Common failure patterns

• SSO off, tokens on: the directory account is disabled but personal access tokens, SSH keys and registry tokens keep working.
• Service built on a person: a production integration runs on the leaver's personal token, so revoking it causes an outage and the team asks to keep it "for now".
• Signing keys on laptops: keys copied to developer machines cannot be recovered at offboarding and must be rotated, as the Coupang case shows.
• Registry access forgotten: package maintainer rights held on public registries outside SSO survive the leaver process.
• Movers keep everything: years of team moves leave senior engineers with access to most repositories and cloud accounts.
• Contractor end dates unknown: temporary engineers keep access after their contract ends because no system held the date.

Practitioner checklist

• Connect source control, cloud, CI, registries and engineering SaaS to SSO, with SCIM where supported.
• Set organisation token policies: restrict classic tokens, require approval and a maximum lifetime.
• Use federated cloud access, SSH certificates and OIDC in pipelines instead of static keys.
• Assign every service identity an engineer creates to a team owner.
• Remove old team access on moves within a fixed grace period.
• Run an engineering offboarding sweep: capture, transfer, rotate, revoke, verify.
• Rotate shared secrets and signing keys the leaver could reach.
• Set end dates on contractor and intern accounts at creation.
• Alert on any credential use after a leave date.

Standards and references

• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• GitHub Docs: Viewing and managing a member's SAML access to your organisation
• GitHub Docs: Setting a personal access token policy for your organisation
• GitHub Docs: Removing a member from your organisation
• GitLab Docs: Moderate users
• AWS: Generate credential reports for your AWS account

Related NHI Mgmt Group resources: Joiner-Mover-Leaver Guide · Employee Offboarding Security Guide · How to find unused GitHub deploy keys and SSH keys · NHI Ownership Guide