GitHub Locks 2FA On for Good This September

If you got a terse email from GitHub this week, here's the gist: after September 2, 2026 at 00:00 UTC, accounts in the mandatory 2FA enrollment group will no longer be able to disable two-factor authentication. At all. Anyone who switches it off before then gets their GitHub.com access restricted on that date until they turn it back on. GitHub says the email and a dismissible banner are the only notice you'll get — there's no dedicated blog post for this one, which is telling in itself.

The Hacker News reaction was a shrug in places — "wasn't 2FA already mandatory?" — and that's a fair question with an interesting answer. Yes, since March 2023 GitHub has required 2FA for anyone who contributes code: package publishers, release authors, org owners, contributors to high-importance repos. But "mandatory" has always been soft-mandatory. You got a 45-day window, then a grace period, then a nag wall. And crucially, you could still disable 2FA after enrolling — you'd just eventually get funneled back into the enrollment flow. Plenty of people lived in that loop for three years.

September 2 ends the loop. This is GitHub converting a policy into an invariant: for enrolled accounts, 2FA stops being a setting and becomes a property of the account. That's a meaningful architectural statement, not a routine compliance nudge.

Why GitHub is welding the door shut now

The timing isn't random. The 2025 npm supply-chain attacks — the chalk/debug phishing compromise and the self-replicating Shai-Hulud worm that followed it — reset the industry's understanding of where the risk actually lives. Those attacks mostly didn't defeat 2FA at login. They stole or abused tokens: long-lived credentials that quietly bypass every interactive protection you've configured. GitHub's response in September 2025 was to mandate 2FA and short-lived tokens for npm publishing; the account-level lock-in is the same campaign reaching the platform itself.

You can see the whole strategy in one place if you read this month's GitHub changelog alongside the 2FA email. Three deadlines now stack up:

• Early August 2026: granular access tokens configured to bypass 2FA stop bypassing it for sensitive operations — token creation and deletion, email and password changes, 2FA configuration, package access management, org membership.
• September 2, 2026: 2FA becomes permanently un-disableable for enrolled accounts.
• Around January 2027: bypass-2FA tokens lose direct npm publishing entirely, demoted to reading private packages and staging publishes that a human must approve with 2FA.

Add npm v12's new install-time defaults — lifecycle scripts, git dependencies, and remote URL deps all blocked unless you pass --allow-scripts, --allow-git, or --allow-remote — and the direction is unmistakable. GitHub is moving from "authenticate the human once" to "require a human in the loop for anything that can poison the supply chain." The 2FA lock-in is the foundation that makes the rest coherent: human-approval gates are worthless if the human's second factor can be quietly switched off.

What to actually do before September 2

For individual maintainers with a TOTP app or passkey already set up, this changes nothing day-to-day. The work is at the edges, and some of it has real teeth.

Audit your service accounts now. GitHub's docs are explicit that unattended and shared accounts selected for enrollment must comply too. If you have a bot account whose credentials live in a CI secret and whose 2FA seed lives nowhere, September 2 is when that account's configuration freezes into whatever state it's in. Get the TOTP secret into your secrets manager, or better, ask whether that bot should be a GitHub App instead — Apps authenticate with keys, sidestep the 2FA question entirely, and don't burn a seat.

Treat recovery codes as production credentials. Once 2FA can't be disabled, losing all your factors means account recovery through GitHub support — a process with no SLA that maintainers have described as painful for years. Download the recovery codes, store them where your team can find them, and verify they're current if you set up 2FA back in 2023.

Get off SMS. SMS still technically satisfies the mandate, but GitHub itself flags its weakness against SIM-swapping, and every attack we've watched since 2023 says the same thing. A passkey plus a TOTP app as backup is the sane configuration, and passkeys also kill the phishing vector that started the chalk compromise.

Fix your publish pipelines before January, not September. If your CI publishes npm packages with a long-lived bypass token, the September deadline is a non-event but the January one is a breaking change. npm's trusted publishing via OIDC is the intended replacement — no stored token, credentials minted per-run. Migrating now means one planned change instead of a 2 a.m. incident when publishes start failing.

The verdict

It's hard to argue with the substance. Every serious registry — PyPI mandated 2FA for all uploads in 2024, RubyGems for top packages before that — has arrived at the same place, and GitHub's version is more flexible than most because passkeys, TOTP, and hardware keys all count without requiring a phone. The legitimate grievance isn't the mandate; it's the recovery story. GitHub is making lockout permanent for enrolled accounts while account recovery remains a support ticket into the void. That's the part that deserves pressure, and it's conspicuously absent from the announcement.

One caveat worth stating plainly: the September 2 date comes from GitHub's own email to affected users, as quoted verbatim across the web — GitHub chose not to publish it as a blog post, so there's no secondary announcement to point at. But the email's language matches the docs and the changelog trajectory precisely, and the pattern matches how GitHub ran the 2023–2024 rollout: quiet emails, hard dates, no ceremony.

If you're a maintainer, the real deadline calendar is August, September, January. Put all three on it.