GitHub 2FA setup
GitHub has required 2FA since 2023 and also supports WebAuthn/passkeys everywhere — but many devs still want a portable TOTP option for CI machines, VMs, and terminals. Here you go.
Fact-checked against GitHub's official documentation · last reviewed 9 November 2026 · how we review guides
Open the generator for GitHubStep by step
- 01
Open GitHub’s settings
Sign in at github.com, click your avatar → “Settings” → “Password and authentication” → “Enable two-factor authentication”.
- 02
Enter the wizard
GitHub’s wizard walks you straight into authenticator-app setup. Passkeys and security keys can only be added as alternative methods after 2FA is already configured — enroll TOTP first, then consider adding a passkey from “Settings” → “Password and authentication” afterwards.
- 03
View the secret key, not just the QR
GitHub shows a QR code. If you can’t scan it, click the “setup key” link below the QR and a Base32 string (letters A–Z, digits 2–7) appears.
- 04
Paste the key into the generator
Paste the key into 2facounter.com and a live code appears within seconds — the page works fully offline too. Or screenshot the QR and press Ctrl+V on the page — the scanner reads it right off the clipboard.
- 05
Verify in GitHub
Copy the live 6-digit code from the generator and enter it in GitHub’s confirm step to activate 2FA.
- 06
Download recovery codes — twice over
GitHub gives a one-time bundle of recovery codes. Download and store them encrypted. Put the Base32 key in your password manager too so the generator can resurrect access on any machine you trust.
GitHub specifics: what 2FA does and doesn’t touch
Pushes, CLI, and PATs are unaffected — by design
Git over HTTPS authenticates with Personal Access Tokens and credential helpers, and SSH keys are entirely independent — neither pauses for a TOTP code. What 2FA changes is your web sign-in and password re-confirmation steps (revoking tokens, approving OAuth apps). If a clone or CI job fails after enabling 2FA, the fix is a fresh PAT or SSH key, not the second factor itself.
Shared machines: paste once, leave nothing behind
On CI terminals and borrowed laptops, work in a private window: paste the key, read the code, close the window. Nothing lands in localStorage or browsing history. On your own machine the recent-keys list is a convenience — on anything shared, it’s leakage. Your vaulted Base32 key plus recovery codes is the plan that lives on your own hardware, not the shared one.
Passkeys vs. TOTP: choose per device
GitHub leads with passkeys, and on a personal machine that’s the right default — passkeys are phishing-resistant and cryptographically bound to the real domain. But a passkey lives in that device’s secure hardware and can’t be re-derived from a string. TOTP is the opposite trade: weaker against phishing, but portable to any browser that has your key. A strong setup uses both — passkey on daily devices, TOTP as the independent second basket, recovery codes as the third.
FAQ
Do I need a browser extension to generate GitHub 2FA codes?
No. Everything is a normal screen in front of you. Extensions that see all page content are a bigger risk than a standalone site.
Can I use the same GitHub key on my phone and the browser?
Yes — TOTP is deterministic: the same secret produces the same codes everywhere. Enroll both if you like, or generate a QR from this site to drop it into any phone app later.
Works for GitHub’s 2FA on shared/company machines?
Yes, but treat shared machines as untrusted. Clear the key field and your browser’s site data after use, or better: use a private window — paste the key just once, copy your codes, then close it and nothing is left behind.
Does 2FA affect pushes or API tokens?
Not for one thing — Git-over-HTTPS and the REST/GraphQL API authenticate with PATs and Git credentials, not TOTP codes, so pushes don’t pause for a code. What 2FA does touch: web sign-ins, and the password you want when revoking tokens or approving OAuth apps now comes with the code step too.