Why does GitLab offboarding still create identity risk after automation?

Why This Matters for Security Teams

GitLab offboarding looks automated on paper, but identity risk persists when deactivation is treated as a single event instead of a full revocation workflow. Accounts can be disabled while project membership, group inheritance, deploy keys, personal access tokens, and service-linked permissions remain reachable. That creates a blind spot in offboarding assurance and leaves a path for unintended access after a user leaves.

For security teams, the problem is not just user accounts. It is the full identity surface around code, CI/CD, and collaboration scopes, which is why NHIMG treats lifecycle control as a core NHI discipline in the NHI Lifecycle Management Guide and the Top 10 NHI Issues. NIST CSF 2.0 also frames this as a governance and access control failure, not a tooling problem, because identity status and effective access are not the same thing when permissions are inherited or tokenised. In practice, many security teams discover residual GitLab access only after a former user has already retained access to repos, pipelines, or secrets.

How It Works in Practice

Effective GitLab offboarding needs to verify every place the identity can still act. That includes direct project access, inherited group memberships, subgroup permissions, runners or deployment integrations, and any tokens or SSH keys tied to the account. Deactivation should trigger a revocation checklist, but the checklist alone is not enough unless it confirms the actual access graph has collapsed.

A practical approach is to separate identity closure from entitlement closure. The identity may be disabled immediately, but security teams should also revoke or rotate all credentials issued to that user, remove memberships across all nested scopes, and validate that automation accounts are not impersonating a human identity. This is especially important in GitLab because access can be granted indirectly through group inheritance or reused in pipeline and integration contexts. The general lifecycle pattern described in the Ultimate Guide to NHIs applies here: inventory first, revoke second, then verify with evidence.

• Confirm the user is removed from all groups and subgroups, not only the top-level account.
• Revoke personal access tokens, deploy tokens, SSH keys, and any API credentials issued to that identity.
• Check project-level permissions, protected branches, and CI/CD variables that may still reference the account.
• Validate that linked automations and service accounts were not created with the departing user as an implicit owner.

Security teams often pair this with access review evidence and log review, using the NIST Cybersecurity Framework 2.0 as the control baseline. The operational goal is simple: a deactivated identity must not remain an effective identity anywhere in GitLab. These controls tend to break down in large, nested GitLab estates because inherited permissions and token sprawl are easy to miss during fast-moving offboarding.

Common Variations and Edge Cases

Tighter offboarding often increases administrative overhead, requiring organisations to balance rapid employee exit handling against the cost of exhaustive verification. That tradeoff is real, especially in GitLab environments with many groups, automation hooks, and cross-functional repos. Best practice is evolving, but there is no universal standard for whether every token must be manually reviewed or automatically invalidated in every case.

The biggest edge case is shared or delegated access. If a former employee helped set up runners, service hooks, or deployment tokens, the account may be removed while the operational trust relationship survives. Another common issue is shadow ownership, where a user is not the formal owner of a project but still has enough inherited access to modify code or pipelines. NHIMG breach analysis shows why lifecycle failures are so dangerous, and the patterns discussed in the 52 NHI Breaches Analysis remain relevant whenever permissions outlive the person who created them.

The strongest control is a post-offboarding verification step that proves no active path remains, rather than assuming deactivation is sufficient. Where teams skip that step, the account may be gone but the access still functions. The Oasis Security & ESG report found that 91% of former employee tokens remain active after offboarding, which is a strong indicator of how often this problem persists in real environments. That pattern is most likely to surface in organisations with nested group structures and long-lived tokens because revocation is fragmented across multiple control planes.

Related resources from NHI Mgmt Group

• Why do former employees create identity risk after offboarding?
• Why do legacy platforms create persistent identity risk?
• Why do decentralised SaaS environments create offboarding risk?
• Why do lifecycle gaps create so much identity risk?