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.

[postspectacular]

I absolutely second this! 2FA-bypass tokens are the only way for me to keep on using my monorepo release workflow tool which is performing all versioning, changelog and interdependency updates and is used to regularly batch publish up to 200+ packages. I do not use CI for releases either and manual per-package approval would be an completely unfeasable burden! Please keep these tokens or define a mechanism which keeps equivalent functionality! I understand security is important, but these problems should be solved differently. It's unreasonable to ask force developers to figure out how to re-adapt their release tooling every few months toward ever tighter and increasingly hostile decision-making on NPM's end, without any choice in the matter...

[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.

[gkgoat1]

Agreed. I plan on having an OIDC aggregator: GitHub token (actions OIDC, etc.) goes in, app actions and AI go out. To publish to npm, and for other reasons, serving OIDC from there is independently useful--thus, allowing configuration of any OIDC would allow these sorts of microservices to thrive

[sudocurse]

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

We also have an operational need for this. We use time-limited team grants to let an engineer (e.g. on-call) join a scoped npm team just long enough to approve a staged publish, then auto-remove them when the grant expires. That's what lets us maintain least privilege — without a non-interactive path we'd have to either keep many engineers permanently in privileged npm teams (or otherwise deal with team management toil in some way) or store a shared admin credential in a vault. A non-interactive, OIDC-scoped mechanism for org/team membership would directly cover this.

[ruiaraujo]

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.

This is the main pain point right now for us right now. Any tentative timeline?

[leobalter]

I have this work as part of the enablement, we will share a timeline when a date becomes more precise.

[mrgrain]

Please ensure trusted publishing supports dist-tag otherwise we still need a token...
See npm/cli#8547

[svanherk]

@leobalter Could you perhaps comment on whether there is a timeline for the issue above? It's been a major blocker for numerous organizations in adopting OIDC Trusted Publishing. From what I've seen, there's been no official acknowledge from GitHub/npm that they're even aware of the issue, or working on a solution.

[leobalter]

I don't have a timeline to share yet, but we are considering all options and I appreciate it you're pointing this one out.

[joeyparrish]

npm/cli#8547 is a major gap.

[ckcr4lyf]

How do I enable 2FA? npm thinks I do not have 2FA and prompts me to register. But when I try to log in, it E-Mails me an OTP; sounds like I have 2FA?

If I try and go into "enable 2FA" , it says something about "Security key" - huh? What's the point of this? Forcing into a closed ecosystem? What the heck is Microsoft trying to do? Open source platform innit? Let me use my TOTP then.

No npm for me till it is fixed, "removing 2FA bypass" is a stupid title, when you don't actually have real 2FA, just a proprietary system to lock people into walled gardens. Disgusting.