Treat the divergence as a governance signal, not a billing-only issue. If active licences, login frequency, and project access no longer align, recertify access and confirm that dormant users, feature flag memberships, and elevated roles are all being reviewed together.
What the mismatch actually tells IAM teams
When GitLab licence counts and access usage diverge, the signal is usually broader than procurement. It can point to stale accounts, overprovisioned access, or a broken review process where licensed seats, project membership, and actual activity are being managed as separate problems instead of one governance issue.
That matters because the control failure is often in the overlap: a user may still have access even if they are no longer active, or they may be active in a project without being covered by the licence and review process that was supposed to govern that access. The fix is to reconcile entitlement, activity, and ownership together.
What IAM teams should reconcile first
The first step is to align the datasets that define who should have access, who actually uses it, and who is accountable for it. That means comparing active licences, login and usage evidence, project membership, and elevated role assignment in the same review cycle rather than treating licence cleanup as a separate admin task.
In practice, the highest-value check is whether dormant users still have project or group access, whether feature flag memberships have drifted away from their intended owners, and whether privileged roles are being reviewed on the same cadence as ordinary access. The Lifecycle Processes for Managing NHIs pattern is useful here because the same lifecycle discipline applies: discover, recertify, remove, and verify that access is still justified.
GitLab-specific reconciliation should also account for indirect access paths. A user may not be the obvious licence holder but can still reach sensitive projects through inherited group membership, shared membership patterns, or delegated admin rights. That is why the question is not only “who is paying for a seat?” but “who can still act, approve, or see what?”
How to turn licence drift into a control
The goal is to make the mismatch operationally useful. Use it as a trigger for access recertification, entitlement cleanup, and ownership validation, not as a finance-only exception queue. Where the gap is persistent, map it back to the process failure: onboarding, transfer, offboarding, or periodic review.
A good control outcome is that every licence, dormant account, and privileged membership has a named owner and a review date, and that inactive users are removed or disabled on a predictable schedule. NHIMG’s Identity Security Programme Guide is relevant because this is a programme issue as much as a tooling issue: the decision rights, review cadence, and remediation workflow need to be explicit.
For teams managing GitLab at scale, the practical test is whether the organisation can explain why every active entitlement still exists. If that explanation depends on “the user still has a seat” rather than on business need and current activity, the access model is already lagging the environment.
Risk and Threat Considerations
Licence and usage drift can hide excessive access, increase the blast radius of dormant accounts, and leave privileged memberships in place long after the original business need has expired. In a GitLab environment, that is especially sensitive because repository access, CI/CD permissions, and project membership can all become a path to code or secret exposure.
Failure mechanism: The organisation reviews billing records or seat counts, but does not recertify actual entitlement and role membership together, so dormant or misaligned access remains active.
Impact: Stale users and overprivileged members retain access to projects, source code, and operational controls, which increases the chance of misuse, compromise, or unnoticed privilege creep.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Licence and access drift is an account lifecycle and entitlement hygiene issue. |
| Recommendation — Review and remove dormant or excess GitLab accounts and entitlements on a defined cadence. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The question concerns reconciling active access with current need and ownership. |
| AC-6 — Least Privilege | Divergence often indicates users retain more GitLab access than their current role needs. | |
| Recommendation — Revalidate GitLab accounts, disable stale access, and document owner-approved exceptions. Reduce GitLab permissions to the minimum required for current job and project need. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | GitLab licence drift is an identity governance and lifecycle control issue. |
| A.5.18 — Access rights | The answer centers on reviewing and correcting access that no longer matches usage. | |
| Recommendation — Maintain an authoritative GitLab identity inventory and remove obsolete access promptly. Recertify GitLab access rights and revoke permissions that no longer have business need. | ||
Practitioner Guidance
What to verify: Confirm that the licence report, activity log, and access list are being compared against the same source of truth. If those inputs come from different owners or different time windows, treat the reconciliation as incomplete.
Decision rule: If a user is inactive but still entitled, remove or suspend access unless there is a documented exception with a named owner and expiry. If the user is active but unlicensed, determine whether the entitlement model or the tracking process is wrong before assuming it is only a procurement issue.
What practitioners underestimate: Feature flag memberships and elevated roles often outlive the obvious licence record. If they are not reviewed alongside ordinary project access, the organisation can clean up seats while leaving the real exposure untouched.
Practitioner takeaway: Treat licence drift as a governance and entitlement signal, not a reconciliation nuisance, because the real control objective is proving that every retained GitLab permission is current, justified, and reviewable.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- What should IAM teams do when access reviews do not reflect live AI usage?