Keep your GitLab seats in check with restricted access (opens in new tab)
GitLab’s restricted access feature helps organizations prevent unexpected seat overages by blocking new billable users once all purchased seats are occupied. Recent improvements make it work more reliably with SAML, SCIM, LDAP, OIDC, and SSO provisioning, while providing clearer warnings and audit information. The feature is forward-looking: it prevents future growth but does not automatically resolve existing overages. ## How restricted access controls seats - Available on GitLab.com and Self-Managed. - When all licensed seats are used, new billable users cannot be added. - Users who only need authentication can receive the non-billable Minimal Access role. - Existing billable members are not downgraded or removed when restricted access is enabled. - Organizations must resolve current overages by removing users or purchasing more seats. ## Identity provider integration - Users provisioned through SAML, SCIM, or LDAP are assigned Minimal Access when no paid seats are available. - Automated synchronization can continue without immediately creating billable overages. - OIDC-only users can be assigned Minimal Access at the top-level group and authenticate without consuming seats. ## Dormant user reactivation - GitLab can deactivate inactive users to free seats. - Previously, SSO or OIDC sign-ins could silently reactivate dormant users as billable members. - With restricted access enabled and no seats available, reactivated users enter a pending approval state. - Their existing group and project memberships are preserved until an administrator approves them. ## Improved operational visibility - Configuration warnings now appear for LDAP, SAML group links, and SCIM. - GitLab distinguishes between approaching and reaching the seat limit. - Group owners and instance administrators can receive email notifications when users fall back to Minimal Access. - Audit logs show Minimal Access fallback events. ## Self-Managed settings cache Self-Managed installations cache application settings for 60 seconds by default. Changes between restricted access and user cap may therefore take up to a minute to appear consistently. Administrators can adjust the cache interval if necessary. ## Restricted access versus user cap - **Restricted access:** Controls additions based on available licensed seats. - **User cap:** Sends new users into an administrator approval workflow regardless of seat availability. - The two features cannot be enabled simultaneously; enabling restricted access automatically disables user cap. ## Enabling the feature - **GitLab.com:** Settings > General > Permissions and group features > Seat control > Restricted access. - **Self-Managed:** Admin > Settings > General > New user account restrictions > Seat control > Restricted access. - GitLab.com does not support restricted access when the top-level group is shared with an external group. Restricted access is recommended for organizations seeking predictable licensing costs while retaining automated identity provisioning and controlled user reactivation.