GitHub 2FA in 2026: the mandate, passkeys, and what it protects

A GitHub account looks like a profile page with a contribution graph attached. For anyone maintaining a package, it is also a piece of infrastructure: one set of credentials stands between the world's build servers and whatever that account is trusted to publish, and the machines on the other end install the updates automatically. GitHub spent years suggesting two-factor authentication with banners and nudges. In 2023 it stopped suggesting.

This is a field guide to GitHub 2FA in late 2026: who the mandate covers, the four methods on offer, the setup path, and the distinction that confuses everyone — what two-factor authentication protects at sign-in versus what it has nothing to do with, like the personal access token your git push has been using all along. For how the six-digit codes themselves work, start with our TOTP primer; this post stays on GitHub's implementation.

GitHub's 2FA mandate

Announced in 2022, enforcement began in 2023 with the maintainers of the most depended-upon packages — npm first — then expanded outward: more maintainers of active code, then broader cohorts of contributing developers. As of this writing the rule covers maintainers of active code, and GitHub has been clear that the destination is 2FA for every developer who contributes. The thresholds have shifted between waves; treat GitHub's documentation as the source of truth for the current line.

The reason is supply chain, and the arithmetic is uncomfortable. Credential stuffing is cheap, password reuse is everywhere, and a compromised maintainer account can push an update that lands on millions of machines within hours. The mandate closes the cheapest attack path first.

It is not a cure for the whole disease. The xz-utils backdoor of 2024 ran through the floor below the floor: an attacker who spends years social-engineering their way into a maintainer's trust never needs to touch the password, and no 2FA setting would have slowed that down. What account-level 2FA does is make the fast, automated, cheap path expensive, so the patient con stays the exception, not the business model.

Four ways to prove it is you

GitHub accepts four second factors, in rough descending order of strength:

• Security keys and passkeys. FIDO2 and WebAuthn, the phishing-resistant tier. The credential is cryptographically bound to github.com at enrollment, so a look-alike login page cannot collect it the way it can relay a typed code — the attack our guide to 2FA bypasses walks through. If your account is load-bearing for your career, this is the tier worth a dedicated device; the hardware key guide covers the shopping.
• Authenticator app. Standard TOTP: scan a QR code once, then a six-digit code rotates every 30 seconds. Any compliant app works — "which authenticator app should I use with GitHub" has the boring answer that they all speak the same standard, so choose on backup and export features rather than badge.
• GitHub Mobile approvals. The official app can confirm sign-ins with a tap, where it is available in your region. Convenient if it is already installed; not a security plan, since it depends on the phone you were trying not to depend on.
• SMS. Still offered in some regions as of this writing, but visibly deprioritized, and fairly: texted codes are the easiest mainstream factor to intercept. Fine as a bridge, poor as a destination.

Enabling 2FA on GitHub

Menu labels drift, so read this as a map rather than a transcript: click your profile picture, Settings, then Password and authentication, then Enable two-factor authentication. GitHub walks you through registering a factor — the QR code for your authenticator app, with a text setup key alongside it — then offers you recovery codes.

The order of operations matters more than the clicks. Register a passkey or security key first if you have one; otherwise scan the QR and confirm one code. Then download the recovery codes before doing anything else. They are the escape hatch for the day the phone is at the bottom of a lake, and GitHub shows them exactly once, with emphasis. Save them somewhere that is not the phone; the medium matters less than the separation.

Sudo mode: the gate and the inner door

GitHub is one of the few consumer-scale services that visibly implements the difference between signing in and doing something dangerous.

Signing in — password plus second factor — gets you through the front gate. Certain actions inside the session, such as deleting a repository, changing security settings, or creating personal access tokens, trigger a re-authentication prompt before they run. GitHub calls the elevated state that follows sudo mode, a name borrowed from Unix: you are already in, but this drawer needs the keys again. The elevation lasts a limited window, not the whole session.

The two layers do different jobs. Sign-in 2FA keeps strangers out; sudo mode caps the damage of a borrowed session — a laptop left unlocked at a conference does not come with delete privileges. That layering is the practical heart of the 2FA versus MFA distinction, and GitHub illustrates it better than most banking sites manage.

Why git push never asks for a code

The most common confused search after enrollment is some version of "I turned on GitHub 2FA and git still authenticates with a token — did I do it wrong?" No. Everything is working — and understanding why separates feeling secure from being secure.

Two-factor authentication protects the web sign-in: the browser session where you review code, edit settings, and publish releases. Git operations do not pass through the web sign-in. Git over HTTPS authenticates with a personal access token — GitHub removed password authentication for git back in 2021, before the mandate began — and the modern fine-grained PATs can be scoped to specific repositories and permissions with an expiry date. Git over SSH uses your SSH keys. Neither path knows your TOTP codes exist, and neither needs to.

The honest trade-off: a PAT and an SSH key are bearer credentials — whoever holds one holds the access, with no second factor at use time. So the discipline that matters after enabling 2FA is token hygiene — least scope, real expiry dates, revocation on suspicion — not expecting your second factor to reach the transport. What the mandate hardened is the control plane: the settings, the releases page, the publish buttons.

Org-level enforcement

The other half is organizational. GitHub organizations can require 2FA for all their members, and the enforcement is mechanical rather than aspirational: members who do not enable it within the notice period are removed from the organization. For a company, this is the rare compliance checkbox that does something — an org owner can enforce the policy and audit enrollment from the admin side.

If you received a notice that your organization requires two-factor authentication, that is what happened: a policy got enabled, and a clock started.

The siblings: GitLab, npm, Bitbucket, Docker Hub

GitHub did not invent the mandate and is not alone in pushing it.

GitLab 2FA covers the same ground with a similar shape: a TOTP authenticator app plus WebAuthn devices, with enforcement available at the group level, so one subtree of an organization can be locked down without a company-wide decree — GitLab's documentation has the current specifics. npm is where the enforcement waves began, because npm is where the blast radius was largest: npm 2FA is required for maintainers of high-traffic packages, and any account can require 2FA to publish new versions, which upgrades "I have 2FA at login" into "I cannot ship without it" — the stronger claim. npm's documentation describes the settings.

Bitbucket and the rest of the Atlassian stack are covered in our SaaS 2FA roundup. Docker Hub supports TOTP and has been nudging its own high-impact publishers the same direction; verify the current policy before relying on that.

Verifying an enrollment in ten seconds

If an org deadline is pushing you through enrollment, the fastest sanity check is to generate a code with it and use it. The guest generator on our homepage was built partly for this: paste the otpauth link or the base32 secret, and the live codes appear instantly, computed entirely in the browser — zero network requests, nothing stored. A ten-second answer to "did I enroll this correctly," no extra phone app required. When the entries need to outlive the deadline, the vault keeps work and personal TOTP entries in separate folders, each secret encrypted in the browser before it leaves the tab.

The mandate, reduced to essentials, is GitHub saying in public what maintainers always knew privately: a password is not an access-control system for infrastructure. Five minutes — one QR scan, one recovery-codes file saved somewhere dry — settles your end of the bargain.

Frequently asked questions

Is 2FA mandatory on GitHub?

For maintainers of active, high-impact code, yes — enforced in expanding waves since 2023, and organizations can require it for their members regardless. If you maintain a package others depend on, assume you are in scope. GitHub notifies affected accounts in advance rather than locking them out cold, and its documentation carries the current thresholds.

Can I use any authenticator app with GitHub?

Yes. GitHub's app option is standard TOTP, the same open standard used by banks and game platforms, so any authenticator that scans a QR code will work. Choose the app on backup and export support rather than brand — the app is interchangeable, the enrolled secret is what matters.

Does enabling 2FA change how git push works?

No. Git over HTTPS authenticates with personal access tokens, and git over SSH uses your SSH keys; both are separate credential systems that never see your second factor. What 2FA protects is the web session — settings, releases, package publishing — while tokens and keys govern the transport.

What is sudo mode on GitHub?

A re-authentication checkpoint that triggers for sensitive actions — deleting repositories, changing security settings, creating tokens — even after you are signed in. Sign-in 2FA is the front gate; sudo mode is the lock on the dangerous drawer, and an unlocked laptop inherits only the outer room.

Do GitLab and npm require 2FA too?

npm requires it for maintainers of high-traffic packages and lets any account require 2FA to publish. GitLab does not mandate it platform-wide as of this writing, but it supports TOTP and WebAuthn, and groups can enforce enrollment for their members. The direction across every code host is the same: toward required.