IAM teams often treat license cleanup as separate from access governance, but inactive users can still hold meaningful permissions. Optimising spend without checking effective access can leave dormant but privileged accounts in place. The better approach is to reclaim licenses only after entitlement review confirms that access is no longer needed.
Why This Matters for Security Teams
GitLab license optimisation is often treated as a finance or admin cleanup exercise, but that framing misses the security consequence: a deactivated seat does not automatically mean a de-risked identity. If a user, bot, or integration still has effective permissions, the organisation may simply be paying less for an access path that still exists. That is why NHI Management Group keeps licence reclamation tied to entitlement review, not just user inactivity.
This matters most in environments where GitLab is wired into CI/CD, automation, and developer workflows, because the residual access can include project visibility, repository write paths, or token-backed actions that are easy to overlook. The NIST Cybersecurity Framework 2.0 reinforces the basic principle that asset and access governance must be coordinated, not handled in separate silos. NHIMG research also shows how often identity sprawl and privilege creep are underestimated in practice, including the Ultimate Guide to NHIs, which notes that 97% of NHIs carry excessive privileges.
In practice, many security teams discover the access problem only after a license audit has already removed the wrong account or left a dormant one with meaningful permissions behind.
How It Works in Practice
The practical mistake is assuming GitLab seat utilisation and effective access are the same control. They are not. A seat can be inactive for billing purposes while still retaining inherited project membership, group access, deploy rights, or connected automation authority. The right workflow is to review identity, entitlement, and credential state together before reclaiming the license.
That means starting with a clear inventory of active human users, service accounts, and integrated tooling, then checking whether each identity still has a valid business purpose. If the answer is no, access should be removed first, then the seat reclaimed. If the identity is a service account or automation principal, the question is not merely whether a person is active, but whether the underlying workload still needs the token, key, or group membership that GitLab trusts. For broader access governance, the NIST Cybersecurity Framework 2.0 is useful as a baseline, while NHIMG’s CI/CD pipeline exploitation case study shows how pipeline trust can be abused when credentials and permissions outlive their purpose.
- Reconcile GitLab users against actual group and project entitlements.
- Check whether any inactive account still owns deploy tokens, personal access tokens, or runner-linked permissions.
- Remove or transfer access before reclaiming the license seat.
- Validate that automation still works after access changes, especially in CI/CD paths.
NHIMG research indicates the risk is not theoretical: the Azure Key Vault privilege escalation exposure and similar cases show how latent privileges become operational security debt. These controls tend to break down when GitLab is federated into many teams and automation accounts because ownership and effective access drift faster than license reviews can keep up.
Common Variations and Edge Cases
Tighter licence reclamation often reduces spend quickly, but it also increases the risk of breaking release pipelines or cutting off shared project ownership, so organisations have to balance cost recovery against operational continuity. Best practice is evolving here: there is no universal standard for how aggressively to reclaim GitLab seats when access is partially automated.
One common edge case is contractors or intermittent contributors. Their accounts may look inactive in GitLab while still being required for audit trails or release approval chains. Another is service accounts that are licensed through a human workflow even though they behave like NHIs. Those accounts should be governed as workload identities, with separate review logic and shorter retention for secrets and tokens.
This is also where entitlement sprawl becomes visible. If a user is removed from a team but remains in nested groups, seat reclamation can create a false sense of security. The safer pattern is to define licence-offboarding criteria that require no active membership, no token ownership, and no downstream dependency before deprovisioning. In complex environments, NHIMG’s Emerald Whale breach is a reminder that access pathways often persist beyond the account lifecycle, and that is where teams tend to get surprised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Licence cleanup must account for exposed or unused NHI access paths. |
| NIST CSF 2.0 | PR.AC-4 | Identity and access lifecycle review supports least-privilege governance. |
| CSA MAESTRO | GOV-2 | Agent and workload governance applies to GitLab automation accounts and tokens. |
Treat automation principals as governed identities with separate review and offboarding.
