Upcoming changes to npm 2FA-bypass granular access tokens (GATs)

[leobalter]

Alongside the npm v12 release, we're beginning to phase out the most sensitive uses of npm granular access tokens (GATs) that are configured to bypass 2FA. This post explains what's changing, when, and how to migrate. Ask questions in the comments — we'll keep this thread updated as migration guides land.

Scope: This is about npm granular access tokens only. It does not affect GitHub personal access tokens, GitHub App tokens, or GITHUB_TOKEN in Actions.

Why we're doing this

A leaked 2FA-bypass token today can be used to take over an account — change the email, generate recovery codes, mint new tokens, add a maintainer — and publish malicious versions, all with no human present. These tokens are the single largest credential-based attack surface on the registry. A 2FA-bypass token shouldn't be a way to skip 2FA for managing your account or publishing.

Change 1 — 2FA-bypass tokens can no longer perform account/org/package management (early August 2026)

Once this rolls out, a 2FA-bypass token will not be able to perform sensitive management actions. These will require an interactive 2FA challenge instead. Affected operations include:

• Creating or deleting tokens
• Generating recovery codes and changing your password, email, profile, or 2FA configuration
• Changing package access, maintainers, or trusted publishing configuration
• Managing organization and team membership and their package grants

How to prepare: Stop using 2FA-bypass tokens for these operations. Perform them interactively (web or CLI) with a 2FA challenge.

Change 2 — 2FA-bypass tokens can no longer publish directly (targeting January 2027)

After Change 1, 2FA-bypass tokens will also lose direct publish. Their publishing surface is reduced to reading private packages and staging a publish — a staged package only becomes public after a human 2FA approval.

How to prepare: Move automated publishing to one of:

• Trusted publishing (OIDC) — short-lived, no stored token, for supported CI providers.
• Staged publishing — CI stages the publish, a maintainer approves with 2FA.

What's coming to make migration easier

We know some of today's workflows don't yet have a clean path off these tokens. Over the coming months we're shipping a series of improvements aimed squarely at closing those gaps. A preview of what's on the roadmap:

• Multiple OIDC configs per package — a single package can be trusted from more than one workflow (e.g. a stable release and a prerelease flow), with each config independent of the others.
• Namespace-wide OIDC configuration — configure trusted publishing once for an entire @scope/* namespace, including a dynamic option and support for creating brand-new scoped packages directly from a trusted workflow.
• Batch selection for staged publishes — approve a whole set of staged packages under a single 2FA challenge instead of one challenge per package (initially up to one version per package), which makes large and mono-repo releases far less tedious.
• Stage-only OIDC for arbitrary providers — set up OIDC to stage packages from providers we don't natively certify (AWS, Jenkins, Azure, and others) without copy-pasting a GAT. Direct publishing stays disabled for these, but a maintainer can approve the staged version.

…and more. We'll announce each of these as it ships and post migration guides here. We don't have firm dates for these yet, so please don't build your migration timeline around them — the enforcement dates above are what to plan against.

A note on recovery codes

Recovery codes are a last-resort account-recovery mechanism, not a routine second factor. If you're using recovery codes as your day-to-day 2FA — including for publishing — please switch to a standard 2FA method (an authenticator app or a hardware security key) now. Routinely using recovery codes weakens your account's protection, and recovery-code use can already place high-impact accounts into a temporary read-only state (preventive account protection).

Help us find the gaps

Our goal is to fully retire direct publishing and account management via 2FA-bypass tokens. Before we tighten these restrictions, we want to make sure every legitimate workflow has a viable path forward.

If your current setup depends on a 2FA-bypass token, tell us what would block you from migrating to trusted publishing or staged publishing. We're especially interested in cases that might not yet be covered by the changes above. e.g.: a publishing pattern (mono-repo, release orchestration, tooling integration) that becomes impractical without a token

We're using this feedback to close the remaining gaps before enforcement, so anything you flag now shapes what we build.