Who is accountable when GitLab access is not fully revoked?

Why This Matters for Security Teams

When GitLab access is not fully revoked, the issue is rarely a single missed checkbox. It usually means the identity source of record, IAM operations, and the application owner each assumed someone else completed the offboarding step. That gap matters because GitLab often sits at the centre of source code, CI/CD, deploy keys, tokens, and integration access. If any one of those paths remains active, the account can still be used long after employment or role changes.

NHIMG research shows why this is not a minor hygiene issue: only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification. That delay creates a practical window for misuse, accidental access, and privilege drift, especially when GitLab is tied to production delivery workflows. Current guidance in the OWASP Non-Human Identity Top 10 and NHIMG’s NHI Lifecycle Management Guide both point to the same operational reality: lifecycle ownership must be explicit, or revocation becomes partial by default. In practice, many security teams discover incomplete revocation only after an audit, incident, or contractor departure has already exposed the gap.

How It Works in Practice

Accountability should be assigned at the lifecycle level, not just the ticket level. The application owner is responsible for knowing which GitLab access paths exist, the IAM team is responsible for enforcing identity changes, and security governance is responsible for setting evidence, timing, and exception standards. A clean offboarding process must cover the human account, group membership, personal access tokens, deploy keys, project access, runner permissions, and any service accounts associated with pipelines.

Practitioners usually reduce risk by treating revocation as a workflow with verification, not a one-time action. That workflow typically includes:

• Triggering revocation from the identity source of record when employment or role status changes.
• Removing GitLab group and project membership, not just disabling the primary account.
• Revoking personal access tokens, deploy tokens, SSH keys, and linked application credentials.
• Validating that CI/CD jobs, integrations, and automation no longer authenticate with the removed identity.
• Recording who confirmed completion, when it happened, and what residual access was checked.

This aligns with the broader lifecycle controls described in Ultimate Guide to NHIs and with Guide to the Secret Sprawl Challenge, because GitLab revocation often fails when credentials are distributed across code, runners, and external integrations. The practical test is not whether the account was disabled, but whether every active authentication path was actually cut off. Guidance from the NIST Zero Trust Architecture also reinforces this approach by treating identity and access as continuously verified rather than assumed.

These controls tend to break down in enterprises where GitLab is integrated with multiple IdPs, self-managed runners, and legacy automation that still uses long-lived tokens.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance speed against proof that access is truly gone. That tradeoff becomes visible when GitLab is used by contractors, platform teams, and shared DevOps accounts, because each group may have different approval paths and exception rules.

There is no universal standard for this yet, but current guidance suggests that accountability should be shared and documented, with one named owner for lifecycle completion. In practice, that owner is often the application or platform team, while IAM executes the technical disablement and security validates the evidence. If the account is tied to a service pipeline, a separate control owner may be needed for the workload identity or bot credential. This distinction matters because an employee offboarded from GitLab may still leave behind runner tokens, webhook secrets, or deploy keys that continue functioning independently.

For teams seeking broader governance context, NHIMG’s Top 10 NHI Issues highlights why incomplete revocation often coexists with secret sprawl and excess privilege. The OWASP Non-Human Identity Top 10 is useful here because the same lifecycle failure patterns appear across both human and non-human access. The edge case to watch is shared or inherited access in nested groups, where a user may appear removed at the top level but still retain effective permissions through a child project or token-backed integration.

Related resources from NHI Mgmt Group

• Who is accountable when access is approved for removal but not actually revoked?
• Who is accountable when offboarding leaves access behind?
• Who is accountable when access workflows sit in ITSM but enforcement sits elsewhere?
• Who is accountable when automated deprovisioning does not happen after access review?