How to Turn On 2FA for GitHub, GitLab and Developer Accounts

Why developer accounts are prime targets

To an attacker, your GitHub or GitLab account is worth far more than a typical email login. It can hold push access to private repositories, deploy keys, package publishing rights and direct paths into production infrastructure. Compromise it, and the attacker inherits your permissions — often without triggering any obvious alarm, since pushes and workflow runs look like normal activity from an authenticated user.

That is why a single leaked password can be so damaging. Private repos may contain configuration files, API keys and database credentials committed by mistake. CI pipelines often carry cloud tokens that can spin up resources or inject malicious code into builds. A credential dumped from one repo can be reused across every environment that trusts it. Attackers have also used stolen maintainer accounts to push backdoored updates to downstream users, which means one hijacked account can compromise thousands of machines.

The industry knows this. GitHub already requires two-factor authentication for many active contributors, and GitLab and other platforms strongly encourage it. Enabling it yourself puts you ahead of the curve rather than behind a mandate — and avoids the lockout pressure of doing it at deadline when a platform forces the issue.

Finally, developer security is rarely just personal. Your employer's source code and the open-source projects you maintain all depend on your credentials. A single weak link can expose customer data, supply chains and release processes. Turning on 2FA protects colleagues, users and your own reputation in one step.

Choosing your second factor

Authenticator apps (TOTP)

Apps such as Google Authenticator, Authy or 1Password generate a six-digit code every 30 seconds on your phone. They work offline, cost nothing and are far harder to intercept than text messages. For most developers, this is the sensible baseline.

Two practical points before you pick one. First, check whether the app supports encrypted cloud backup: Authy and 1Password do, plain Google Authenticator historically did not. If you reinstall your phone's OS or upgrade devices, a backup saves you from re-enrolling every account. Second, enrol the TOTP app before you confirm 2FA — GitHub shows a QR code once, and if you scan it with the wrong app or lose the screen, you will have to restart setup.

Passkeys and security keys

Passkeys and hardware security keys use cryptography tied to the website's own domain, so a phishing page can't trick them into signing in. GitHub and GitLab both support them. If your repositories have real value, register a passkey or hardware key as your primary factor and keep a TOTP app as backup.

Register two keys if you go this route — one on your keychain, one in a drawer. A single lost hardware key leaves you locked out until support verifies you. Also register a TOTP method anyway: some corporate VPNs and CI tools still only accept codes, not passkeys.

SMS codes

Text messages can be hijacked through SIM swapping — an attacker convinces your carrier to port your number to their SIM, then receives your codes. They also fail on flights, ships and anywhere without signal. Use SMS only if nothing else is available, and switch away as soon as you can.

Recovery codes

When you enable 2FA, the site offers a set of one-time recovery codes. Generate them, then store them offline: printed on paper or in a password manager's secure notes. Lose your phone without them, and regaining access becomes a slow support ordeal — GitHub's recovery process can take days and requires proving account ownership.

Treat recovery codes like a password: never commit them to a repo, never paste them into chat. If you suspect they leaked, regenerate them immediately — regeneration invalidates the old set.

Enabling GitHub 2FA

Sign in, then go to Settings > Password and authentication > Two-factor authentication and click Enable two-factor authentication. GitHub may ask you to re-enter your password first — normal, and worth noticing: any prompt for your password outside this flow is a phishing red flag.

Register a TOTP app

GitHub shows a QR code. Scan it with your authenticator app (Aegis, 1Password, Google Authenticator and similar all work), then enter the six-digit code from the app to confirm. The app now generates a fresh code every 30 seconds. Codes rotate on the half-minute boundary; if a code fails repeatedly, your phone's clock is probably off — enable automatic time sync and try again. If you cannot scan the QR code, click the link beneath it to reveal the setup secret and type it into the app manually.

Add a passkey or security key

TOTP codes can be phished. After setup, register a passkey or hardware security key as a second method under the same settings page. Keep TOTP as your backup, not your only factor. Register the key on a second browser or device too, so a dead laptop battery does not lock you out.

Download recovery codes

GitHub offers recovery codes during setup. Download them and store them offline — printed or on an encrypted drive, never in a repository or cloud notes. Each code works once, and they are the only way back in if you lose all your second factors. You can regenerate them later from the same settings page; regenerating invalidates all previous codes.

Tokens and SSH keys afterwards

Existing SSH keys and personal access tokens keep working unchanged. HTTPS pushes will now ask for browser authentication or a token instead of a password — a plain password over HTTPS stops working immediately, which surprises people who only push occasionally.

Enabling GitLab 2FA

In GitLab, select your avatar, choose Preferences, open Account in the left sidebar, then click Enable two-factor authentication.

Pairing your app

Scan the QR code with your TOTP app — Aegis, 1Password, Google Authenticator or similar — and enter the six-digit code it generates to confirm the pairing. If you prefer hardware, you can register WebAuthn devices such as security keys or passkeys as a second factor from the same Account page. Hardware keys resist phishing better than TOTP codes, so use one if your employer issues them.

Saving recovery codes

GitLab then displays a list of one-time recovery codes. Each works once if you ever lose access to your authenticator. Download, copy or print them and store them somewhere safe, such as a password manager. You can generate a fresh list later from the same page, but keep this first set safe. A common mistake is screenshotting the codes into a photo library that syncs to cloud storage — that undermines the point of the second factor.

What changes for Git operations

Once 2FA is on, your account password no longer works for Git over HTTPS. Push and pull using a personal access token instead, or switch to an SSH key. Create the token before enabling 2FA so you are not locked out mid-workflow. Give the token read_repository and write_repository scopes only — broader scopes are unnecessary for Git traffic and increase the damage if the token leaks. If you use a CI runner that clones over HTTPS with your password, update it to a token at the same time, or pipelines will start failing the moment 2FA activates.

SSH keys and tokens after 2FA

Once 2FA is on, password-based git pushes stop working. Switch your remotes to SSH so daily work needs no password prompt at all:

git remote set-url origin [email protected]:owner/repo.git

Test before deleting the old HTTPS remote from memory:

ssh -T [email protected]

GitHub greets you by username on success; GitLab does the same via ssh -T [email protected]. A failed handshake here is easier to debug than a failed push mid-task.

Generate an SSH key

Create a modern key with a passphrase protecting it:

ssh-keygen -t ed25519 -C "[email protected]"

Ed25519 is short, fast, and avoids the aging RSA defaults some older guides still recommend. Skip -C if you like — it's only a label, not an identity check.

Copy the contents of the .pub file into your account's SSH key settings (GitHub: Settings → SSH and GPG keys; GitLab: Preferences → SSH Keys). The passphrase gets cached by your SSH agent, so you type it rarely. On macOS and most Linux desktops the agent starts automatically; if it doesn't, ssh-add after each reboot is enough for most people.

Common mistake: pasting the private key file instead of the .pub file, then wondering why the fingerprint looks wrong. The private key never leaves your machine.

Tokens for scripts and CI

Personal access tokens replace passwords for API calls and pipelines. Give each token the smallest scopes that work — a token that can only read public repos can't push malicious commits. Set an expiry date on every token; a token that dies quietly beats one that leaks loudly. Name tokens after their purpose ("ci-deploy-staging") so a leaked one is identifiable in audit logs.

Limit the blast radius

Prefer fine-grained tokens (GitHub) scoped to specific repositories and permissions, and use deploy keys for single repositories on servers. Deploy keys are read-only by default — leave them that way unless the server genuinely pushes. If a narrowly-scoped credential leaks, an attacker gets far less than with your full account, and revoking it doesn't break anything else.

Other developer accounts worth locking down

Package registries deserve the same protection as your Git host. npm, PyPI and Docker Hub all support 2FA, and npm requires it in some cases. A compromised registry account lets an attacker publish a tampered version of your package, which then lands on every machine that installs it. On npm, turn on 2FA under your account settings and choose "authorization and writes" so publishing itself demands a second factor. PyPI lets you require 2FA for uploads and supports trusted publishing so CI pipelines can push without long-lived passwords at all.

Cloud consoles and CI providers

AWS, Google Cloud, Azure and CI services like GitHub Actions secrets or GitLab CI variables often hold deployment credentials, database access and payment cards. Enable 2FA on the console account, then audit which CI jobs can read secrets. A single overly broad CI job can leak credentials into build logs, so scope variables to the projects that need them and rotate anything that has ever been printed in a log.

The root of trust

Two accounts matter more than the rest:

• Email — password resets for almost everything route here
• Password manager — holds the keys to every other account

If either falls, an attacker can often reset their way into everything else, 2FA or not. Protect both with the strongest second factor you own, ideally a hardware key or authenticator app rather than SMS, and never reuse their passwords anywhere else. Common mistake: securing the password manager but leaving the recovery email on SMS only.

Living with 2FA day to day

Once 2FA is on, a few habits keep it painless.

Guard your recovery codes. Store them in a password manager or print a copy and keep it somewhere safe. Never commit them to a repository — even a private one can leak through tokens, forks or a misconfigured setting. A good test: ask whether a colleague could find the codes by searching your repos. If yes, move them.

Register a backup second factor. Add a second TOTP app or a spare security key while everything still works. A backup you set up after losing your phone is a backup you don't have. Keep the spare key somewhere physically separate from your primary one — a drawer at work defeats a stolen bag.

Audit regularly. Every few months, review active sessions and remove devices you no longer use. Revoke stale SSH keys, personal access tokens and deploy keys — old credentials outlive the projects they were made for. A calendar reminder helps. When reviewing tokens, check scopes too: a token with full repo write access that only ever read public data is a liability, not a convenience.

Update 2FA when your situation changes. New phone? Re-enrol your TOTP app before wiping the old one. Leaving a team? Remove your keys from shared accounts. These transitions are where people get locked out — not the initial setup.

If you lose everything, contact platform support. Recovery can take days and involves proving you own the account, so treat that path as a last resort, not a plan.

Two minutes of setup now beats a week locked out later. Enable 2FA, save the codes, move on.