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.

[tstackhouse]

I'd love to use my 2FA app. If I could set it up...

[waterkip]

I seriously object to removing 2FA release-tokens, I do not release by using CI, the step is manual on purpose.

Please keep a way to do manual releases. I do not want to release and do a button press on some website; that is completely missing the point.

[KTibow]

please switch to a standard 2FA method (an authenticator app or a hardware security key) now

As a ARM Linux user with no hardware security keys or other straightforward ways to make passkeys this is almost a ban from NPM because authenticator apps were previously removed and this statement is an AI hallucination that misses this. I will no longer be able to publish any packages, or will have to go through a convoluted process that adds a dependency on Google or Android, if this change goes through. You could fix this by adding an alternative 2FA method, like magic links or Verified Email, or by not requiring 2FA to set up new OIDC (similarly to how 2FA isn't required to make tokens that bypass 2FA), or by just... not going through with this change.

[gkgoat1]

This also breaks any CI outside of the current OIDC scopes, locking users to GitHub, GitLab, or CircleCI. Given the behavior of those on more niche platforms, this may lead to increased attacks on OIDC global keys. Passkeys are emulatable, but I know what the real, evil, intent of this change is (breaking third-party CI)--and that it puts OIDC keys as targets just so users' packages are published

And per a few comments, these include GHES and Bitbucket, so enterprises also end up joining in--GitHub, you're in danger

[M3NickP]

We use Bitbucket Pipelines in house and are waiting for Atlassian and NPM to support trusted publishing from bitbucket cloud. See the following: npm/rfcs#846 and https://jira.atlassian.com/browse/BCLOUD-23917

[twesterhuys]

This appears to leave GHES w/ self-hosted GHAR without a viable migration path for automated publishing.

We are currently publishing daily preview builds to npm from GHES self-hosted runners using a 2FA-bypass granular token. It sounds like that flow will stop working in January 2027 without an alternative.

Trusted Publishing would be the right replacement and we would be more than happy to move to it, but the docs still say self-hosted runners are unsupported and only “planned for future releases.” This was raised multiple times (for example see here or here) during the previous token restriction discussions, and support for more providers/runners was described as planned.

Can you clarify whether direct trusted publishing from GHES self-hosted runners will be supported before the January 2027 enforcement date? If not, will enforcement be delayed or will there be another non-interactive migration path? With stage-only publishing we won't be able to use npmjs for our daily preview builds.

[dtheasby-kaluza]

We rely on non-interactive tokens to automate management of organization membership and package access. Once bypass-2FA tokens lose that ability in Phase 1, we lose the ability to run either of these without a human manually completing the action every time.

This discussion covers the forthcoming solutions for publishing and package management but provides no reasonable solutions for organization management which is arriving in a much shorter timescale.

Is there (or will there be) a non-interactive, narrowly-scoped mechanism for managing org/team membership analogous to trusted publishing for packages e.g. something OIDC-based

Are SAML/SCIM integrations for user management on the roadmap? If so, would SCIM-driven provisioning/de-provisioning be the intended long-term replacement for bypass-2FA tokens in this use case, and is there a rough timeline?

[joostvdwsd]

Before pushing this I would suggest to really take a look at the current way of configuring OIDC. Currently you can only configure it after a package was published at least once. This is terrible when you only publish through a pipeline.

Basically you have to configure the pipeline first for a 1 time run with a token that can only prepublish and a prepublish step. Once you have that you can change the whole pipeline since only then the configuration appears.

Much better would be to at least offer OIDC config on a scope/organisation (this is difficult for non-scoped packages). So you can configure up front which identity provider and rules you trust.

Also having read statements above. When configuring OIDC, extend the matching config so people can basically configure any source.