What the PIN is for
A support case usually reaches a point where the person on the other side needs to know they are talking to the real account owner. The GitLab Support PIN exists for that moment. It is a code the account owner produces on demand so support can check the request against the account, and it is deliberately narrower than a password.
That narrowness is the point. A password opens the whole account. A recovery code can reset access. A public user ID or profile handle is visible to anyone. The PIN is meant to answer one question — is this the owner? — and nothing more.
Before you generate anything: verify the channel
Do not start from a message that asked you for a code. Start from the support channel you can confirm independently, then open the case from there.
- Confirm you have a real open support case and know how it was opened. If you did not open it, treat the request as unverified until you can confirm it another way.
- Reach support through a route you control — the support entry point you already use — rather than a link or address supplied inside an unexpected message.
- Check who is asking. A request for a PIN that arrives unprompted, or that pressures you to reply quickly, is a reason to slow down, not to comply.
- Keep the conversation in the verified channel. Moving to a new address or thread at someone else’s request breaks the check you just did.
No message is automatically trustworthy because it looks official. The verification step is yours to perform, and it is the part that makes the PIN safe to use.
Generate the PIN
Once you are satisfied the case is genuine, generate the PIN yourself while logged in as the owner.
An owner can open Edit profile, Account, and Generate New PIN. Source
The PIN is created by you, in your own account settings. You are not receiving it from support, and support cannot produce it for you. If someone offers to generate a PIN on your behalf, that is a contradiction worth noticing.
Understand how long it lasts
A Support PIN expires seven days after it is created and can be reviewed in the same account settings. Source
The expiry is a built-in limit, not a suggestion. Generate the PIN when the support conversation actually needs it, not days in advance, and check the same settings screen if you are unsure whether an earlier PIN is still valid.
What support may ask for
GitLab Support can ask for a Support PIN to validate the account holder’s identity. Source
Notice the direction of that request: support asks, you provide, and the purpose is validating that you hold the account. It is a check on identity, not a transfer of control.
Keep the PIN separate from everything else
| Item | What it can do | How to treat it in a support case |
|---|---|---|
| Password | Signs in to the account | Never send it to support, in any channel |
| Recovery code | Can restore access to the account | Keep it private; it is not a support verification token |
| Public user ID or handle | Identifies the profile to anyone | Fine to reference, but it proves nothing on its own |
| Support PIN | Lets support validate the account holder | Share only inside the verified support conversation, and only while it is valid |
A PIN shared with the wrong party is still a leak, even though it is less powerful than a password. Treat it as sensitive for the days it remains valid.
Failure paths to plan for
- The PIN has expired. Generate a new one in the same account settings and continue in the verified thread. Do not reuse an old value or paste it into a different conversation.
- The request came from an unexpected message. Stop. Verify the case through a channel you chose, and treat the original message as unconfirmed.
- Someone asks for your password, a recovery code, or a PIN generated by them. Decline. None of these belong in a legitimate identity check.
- You are unsure the case is real. Do not send the PIN while uncertain. Resolve the channel question first; the PIN can wait.
- You have already shared a PIN outside a verified conversation. Return to your account settings, review the PIN, and let it expire rather than assuming the exposure is harmless.
A short checklist
- I confirmed the support case exists and I know how it started.
- I reached support through a route I chose, not one supplied in an unexpected message.
- I am logged in as the account owner and generated the PIN myself.
- I checked when the PIN was created and whether it is still within its validity window.
- I am sharing the PIN only in the verified conversation, and I have not sent a password or recovery code.
- I know what I will do if the PIN expires mid-case.
Next step if the contact itself is in doubt
The PIN only helps once you trust the conversation. If the approach came through social media or a direct message and you are still deciding whether the person is genuine, work through the channel question first using our guide to checking fake customer support social accounts. Come back to the PIN once the support channel is confirmed.
A username search can support that kind of channel check by surfacing public profiles that use a similar handle, but a match is a lead, not proof of who is behind an account. The decision still rests on the verified support route, not on a profile that looks right.