Enforcing two-factor authentication in self-managed GitLab

The software cost depends on your tier. GitLab's pricing page lists Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced, with all three tiers available for self-managed installations. Enforcing 2FA is a configuration change, so most of the engagement cost is labor: planning the policy, testing enrollment, writing user guidance, staffing the helpdesk and checking the result. Planning and rollout work is mostly one-time, while per-user subscription fees recur if you are on a paid tier. The main cost drivers are user count, the number of groups with different rules, whether an identity provider already handles sign-in, and how much helpdesk capacity you have. Ask any partner for a quote that lists each of these as a separate line, with the scope agreed in writing.

The pace is set by your user population, your grace period and your change process, not by the setting itself. Timing depends on how many users, groups and time zones are involved, how long users get to enroll before enforcement applies, and how many approvals your change process requires. A common sequence is to enforce for administrators first, pilot with one group, then extend to the rest of the instance, with communication and helpdesk readiness set before each step. The materials behind this page do not give a duration, so ask your internal lead or a partner to produce a dated plan from your own inventory of users and groups. Avoid holidays, audit windows and your own upgrade windows. GitLab ships patch releases twice a month, so schedule 2FA changes on their own calendar rather than stacking them onto upgrade work.

Before work starts, your team needs to provide administrator access, a written identity policy and a communication plan. Administrator access should include an account that can change instance-wide sign-in settings and group settings, plus a way to reach the server for recovery if a change locks out the wrong population. The identity policy decides which authentication methods are allowed, which groups or roles are covered, how long the grace period runs and how exceptions are approved. The communication plan covers announcements, the enrollment steps users will see, the support channel and the escalation path. You should also supply an inventory of service and automation accounts, a named approver for each stage and a pilot group willing to test early. Without these inputs, any scope agreed in writing will rest on assumptions that surface during the rollout.

Yes, most teams can enforce 2FA with their own administrators, because the core work is configuration and communication. The hard parts are rarely the setting itself. They are deciding the policy, testing edge cases such as service accounts and users without a supported device, and handling the first wave of lockouts. A team that already operates a GitLab instance and has a helpdesk runbook can usually do this internally. A partner adds value when staff are stretched, when the rollout spans many groups or identity sources, or when you need documented evidence for an assessment. DeployOpen plans, implements and documents self-hosted platforms inside your own infrastructure, works on fixed-scope engagements with scope, deliverables and timelines agreed in writing first, and offers retainers for ongoing support. Either way, name who owns the helpdesk queue during the grace period.

A grace period lets users enroll in 2FA before enforcement blocks their normal sign-in, so the length and timing of that window shape when support tickets arrive. Most of the load lands at the deadline, when users who have not enrolled are sent to the setup page and some discover they have no working device. Stagger deadlines by group so that one support team is not handling the whole organization at once. Pre-enroll administrators and service owners, send reminders before the deadline and publish a short guide for each supported method. Plan for the users who lose a phone or security key, since recovery requires a defined identity check and an administrator who knows the steps. Ask your helpdesk to estimate volume from the enrollment report of the pilot group, and treat that estimate as your own planning input rather than a fixed figure.

No. Enabling 2FA is one input to a control, and it rarely satisfies a control by itself. Frameworks such as NIST SP 800-53 describe identification and authentication requirements in terms of control families and enhancements, so map the setting to the specific control IDs your assessor uses, then document how it meets each one. The evidence an assessor will ask for usually includes the written policy, the configuration in effect, enrollment reports, exception records with approvals and the procedure for recovering locked accounts. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early which control IDs and evidence formats your auditor expects.

Allow the methods your users can actually use, and require a recovery path for each. Time-based one-time passwords work with widely available authenticator apps and need no hardware purchase, but they depend on a phone and can be phished by a user who enters a code on a fake page. WebAuthn works with security keys and platform authenticators and resists phishing better, but it needs hardware budget, a distribution process and a plan for lost keys. Many teams enable both, encourage WebAuthn for administrators and privileged roles, and require at least two enrolled methods for those accounts. Confirm the exact options your GitLab version offers in its authentication documentation before writing the policy, and test each method with a pilot group on a non-production instance first.

Automation accounts cannot complete an interactive 2FA prompt, so enforcement must account for them before it goes live. Inventory every service account, bot, CI integration and provisioning script that authenticates to the instance, and decide for each whether it needs a token, a dedicated non-human account or an exception. Use the API settings for 2FA to configure the instance from scripts, so the policy is reproducible across environments and recorded in version control. Test each automation path in a staging instance before enforcement, because a broken pipeline is often the first visible symptom of an incomplete inventory. Check how personal and project access tokens behave under your chosen enforcement mode in the documentation for your version, and confirm the expected behavior with a test account rather than assuming it.