Account Ownership Verification

Workflow detailing how and when to verify account ownership including disable 2FA

Overview

This workflow covers how a user can provide account verification. It should be used for any account changes.

Account actions can only be completed if the workflow below is successful.

User Account Verification

GitLab.com requires that users without 2FA enabled verify their email address when a login attempt meets certain high-risk criteria. For users requesting support when their email address is no longer valid and are unable to receive the email, please see the Email account lost workflow.

If the user has questions about the email, phone, or credit card verification GitLab is requiring, please refer to the Internal Handbook for the workflow to follow.

GitLab Team Members

If the user is a GitLab team member, have them contact IT Ops.

2FA removal within GitLab

See the 2FA Removal workflow for instructions to process 2FA removal requests.

Workflow

The workflow applies to all cases where account verification is required, aside from 2FA removals.

Keeping the Ticket Simple and Accurate

Because an ownership-verification ticket is a matter of record, the ticket must be simple, accurate, and tightly focused on the access issue. Do not allow the customer to bring up unrelated topics.

Step 0: Ticket metadata

Ensure that the ticket form, category, subcategory, and topic are accurate.

Most SaaS Account categories have automations or triggers.

Account verification matrix

The table below provides a summary of the available verification options based on the owner and user type:

Requester Target Challenges Support PIN Notes
Enterprise Owner Own account Owner passes challenges on own account Support PIN must be provided by a different owner If no other owner is available for vouch, see internal handbook for other challenges.
Enterprise Owner Enterprise User Owner or target user passes challenges on their own account Support PIN is from requesting owner Multiple enterprise users may be handled per ticket. Target user does not have to be CC’d on ticket.
Owner Non-enterprise user (who is a member of or intends to be added to owner’s paid group) Target user passes challenges on own account Support PIN from owner One user per ticket. Communication is direct from the target user who must be CC’d on ticket.
Paid User Own account User passes challenges on own account N/A If owner is needed, owner must open a new ticket.
Paid User Other member of same paid group Target user passes challenges on own account N/A If owner is needed, owner must open a new ticket.
Free User Non-member of group with intent to be added Not allowed - request must come from group owner Owner vouch required

Enterprise Owners are owners at the top level of a paid group with Enterprise Users. They must also be an Enterprise User. See the Enterprise User section on how to identify if a user is an Enterprise User.

Step 1: Sending Challenges

Before sending challenges, determine whether the ticket was opened by an Enterprise Owner. If so, please use the Support::SaaS::GitLab.com::Account Ownership Verification - GitLab.com - Enterprise Owner macro. Otherwise, use the Support::SaaS::GitLab.com::Account Ownership Verification - GitLab.com macro.

Any audit / log requests must be made by the owner of a top-level namespace. We should always use the Enterprise Owner macro in these requests.

Step 2: Checking challenge answers

Note: In case the user sends back very minimal information and it’s clear it’s not sufficient or the answers are vague, reply asking for more information immediately after their response. You can provide some additional guidance, such as “please provide the exact date and time of the commit, not just an approximate one”.

  1. To verify the challenge answers, use the Zendesk GitLab User Lookup App or, for those who have admin access, check at https://gitlab.com/admin/users/USERNAME.

  2. Use the ZenDesk GitLab Super App’s 2FA Helper to determine the risk factor (GitLab internal) based on the user’s answers. Data classification criteria and any notes are in the GitLab Internal Handbook - Data Classification table, which is considered the source of truth.

    • Challenge answers must be evaluated against a paid namespace if the user is a member of any paid namespace. If the user is not a member of a paid namespace, refer to Conditions for 2FA Reset Consideration for further guidance.
    • If a group owner is answering on an enterprise user’s behalf, see the Account verification matrix for which account to evaluate the answers against. Even if the Enterprise user is not a current member of the paid namespace, the data classifcation is RED.
    • Audit and log requests for groups/projects should use the General Account Verification form since the Enterprise owner verification form is aimed toward user related action requests.
    • If you need to leave a comment manually (instead of through the app), use the Support::SaaS::GitLab.com::2FA::2FA Internal Note macro to put an internal note on the ticket.

  3. If verification passed: Request that your decision be peer-reviewed by another member of the team through Slack #support_gitlab-com.

  4. If the verification failed: Move to step 3b

Step 3a: User successfully proves account ownership

For reviews of 2FA removal or other user changes, the reviewer will typically complete the final action. Requests such as audit events or console escalation work will typically be handled by the original ticket owner.

  1. If you agree with the decision to take action on a user, sign into your admin account and locate the username in the users table or by going to https://gitlab.com/admin/users/usernamegoeshere
    1. Please see Account Changes workflow.
    2. Under the account tab, click Edit, add an Admin Note, and save.

Step 3b: User Fails to Prove Account Ownership

Note: Do not provide hints to answers, or let the user know which challenges they got right or wrong. That is how social engineering works!

  1. If the user is unable to pass the risk factor but we have not provided all the applicable challenges, you may offer further challenges. This is true for all users, including owners.
  2. If the user is unable to pass the available challenges:
    1. Inform them that without verification we will not be able to take any action on the account. For 2FA, use the Support::SaaS::GitLab.com::2FA::2FA Removal Verification - GitLab.com - Failed - Final Response macro.
    2. Mark the ticket as “Solved”.

Authenticating an Owner Vouch

In a paid namespace: If the user elects to have an Owner vouch for their request, apply the macro Support::SaaS::GitLab.com::2FA::2FA ask owner vouch. This will direct the requester to have an Owner (top-level) create a Snippet with a Support-provided string. Once they have replied verifying they have done so:

  1. Use your Admin or Auditor account to browse to the Snippet provided (for example https://gitlab.com/-/snippets/2057341)
    • Verify the text of the Snippet matches the string you specified
    • Verify that the author of the Snippet is an Owner and direct member of the top-level paid group
  2. If the Owner passes, you may count this towards the account verification challenges.

Note that you can also request that an Enterprise Owner create and share with us their Support PIN as a form of Owner Vouch.

Note: Due to this bug some group owners are not able to create snippets. In that case, we can ask the Owner to generate and share with us a Support PIN instead.

Note: If another user is CC’d on the ticket, once you’ve verified the PIN ask them to generate a new PIN to revoke the previous one.

Account Ownership Changes

This section has been moved to the Account Changes workflow.

Last modified September 1, 2026: Add log request verification steps (80b8f1da)
View page source - Edit this page - please contribute. Creative Commons License