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.

[twesterhuys]

@leobalter is there a tentative timeline or roadmap for Trusted Publishing from GHES?

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

[SerenModz21]

A few others and I are also in need of this.

More details can be found here: https://github.com/orgs/community/discussions/206745#discussioncomment-18293721

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

[gitcnd]

I do agree with 99% of your sentiment... but under-the-hood, this uses your TPM - which makes key-theft near-impossible for malware etc to pull off (TPM keys are locked in silicon)... it's just a pity that nothing else bothered to use TPM for the 10+ years we've all had them sitting idle. We (open source devs) kindof only have our selves to blame, so MS had to step up roll something out, coz nobody else seems to actually care about real security...

[ckcr4lyf]

Is that a strict requirement? I'd think some more sensitive orgs who need to protect their packages can opt for this if they want; let others use their TOTP if they want.

Anyway, the TPM thing is not enforced, I can technically patch the USB stack to mock it via custom ed25519 keys if I wanted to - I just think there is no good reason to enforce this. Managing passkeys across multiple devices without opting into some proprietary ecosystem is harder.

And if Google / Apple etc. make it possible to sync my passkeys across multiple devices, sounds like they have my passkey at least in transit?

[AlttiRi]

Bring back the ability to set up TOTP. "Passkeys" are crap.

[philipmw]

npmjs, before being so aggressive with the hardware 2FA rollout, please start supporting the keys that your users have.

I have a SoloKey 2. I use it with other sites without an issue. But with npmjs, it lets me register the key but then refuses to let me authenticate with it. Each time I try (across three devices), I get "Something went wrong." I had to use my recovery codes to log in.

The combination of having poor support for something you're trying to mandate is a bad look.

[ckcr4lyf]

Had the same thing happen wit hed25519 based keys, worked with P256. NPM should not have allowed me to register the ed25519 key if they can't authenticate with it...

[TimRoe]

Used trusted publishing, worked great. 10/10, much simpler/safer than tokens.

Organization migrated to GitHub Enterprise Cloud w/ data residency (GHEC, [org].ghe.com hosted). Trusted publishing no longer an option due to NPM's lack of optionality. Wasted time becoming less secure moving to granular tokens and waste time once a quarter creating new ones. Now NPM is going to break everything again while still not supporting trusted publishing for enterprise GitHub users.

How can you mandate changes to "improve security" when it's impossible to actually implement them for so many users/orgs? Appalling user experience NPM. Absurd if this goes through as planned without trusted publishing support for something as common for large orgs as GHEC by mid-October at the latest.

[ckcr4lyf]

Since npm / github / micro$oft don't want to do anything about it, I decided to take matters into my own hands. Registering a throwaway github + npm account as a PoC , I have a script that uses secp256r1 keys generated on my machine via OpenSSL, registers them in NPM as a passkey, and uses those via Github actions to publish automatically without the need for OIDC or crap.

So now my package can be published with "passkeys" from a remote machine without human intervention, or OIDC from a few proprietary providers.

This means that you could do this on any machine which the shim could run on, which stubs the passkey functions in Chromium w/ keys you provide.

As a bonus, the credentialId to register can be any 32 bytes you want, so you can have some fun with it:

Here's the repo if anyone wants to play around: https://github.com/nmpwaifu/gettodaysdate

[jedwards1211]

hahaha brilliant

[leobalter]

this is now fixed. Thanks for reporting it.

[postspectacular]

@leobalter would you maybe also be able to provide any official feedback (or an ETA for such) about the various serious concerns raised here by people in this whole discussion? And so far we've not heard any updates at all that some of these points are being taken into new consideration...

[ckcr4lyf]

Not sure what you mean "fixed" , its the passkey spec so it is working as intended. Seems to still be fine for me: https://github.com/nmpwaifu/gettodaysdate/actions/runs/33830456228

[to-goseki-katatan]

I agree applying 2FA to publish packages, but not agree to the PASSKEY.

[tiadrop]

Embrace ✅
Extend ✅
Extinguish ✅

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

You didn't resolve or address a single, solitary issue raised in the comments.

[ckohen]

This post makes no mention of managing dist-tags with 2FA bypass GAT. It may have unclearly been bundled in "package management".

This completely breaks our CI flow for publishing PRs as a tag and then removing that tag when it is no longer needed so it isn't prominently displayed in the registry. There has been no provided way to do this without a 2FA token, which defeats the purpose of this being in CI (so that any org member can do it). This needs to be added to trusted publishing at least, ASAP. Breaking completely reasonable workflows without a replacement is the type of thing that makes developers look for other platforms.

[leobalter]

Support for dist-tag in trusted publishers is coming soon this month!

[iangrunert]

Tuesday 9/29, or Wednesday 9/30? Excited to try it out!

[14ck]

We use Bitbucket Pipelines in house and are waiting for Atlassian and NPM to support trusted publishing from bitbucket cloud. Please take this into consideration.

[RaJharit77]

These changes make npm publishing much safer. I especially appreciate the staged publishing and batch approval approach, which should make secure publishing easier for larger and monorepo projects.

[UnknownOrange]

This is a blocker for me being able to publish on npm. I do not own a biometric device that can be used for 2 factor authentication and my workflow requires publishing from the command line.

[ckcr4lyf]

Shilling my project, but you can setup a passkey using custom keys you own, then script puppeteer to perform the auth. Here is a PoC: https://github.com/nmpwaifu/gettodaysdate

[postspectacular]

This "discussion" has been up for almost 3 months and not a single time has the NPM team here constructively responded to any of the serious concerns raised here. So I will reiterate my strong objection to these proposals once more:

These changes, however well intended, are plainly exclusionary practices and bad for what's left of open source culture!

1. Trusted publishing is excluding any form of publishing with a custom publish tool/workflow which doesn't use a CI.
2. Staged publishing, the only cited alternative proposal, is completely unusable for publishing large numbers of packages, e.g. from a monorepo. At the very least this needs to be updated to allow batch approvals/publishing of staged packages, otherwise it's completely unfeasible!

These combined effects mean people publishing multiple/many packages in one release cycle (e.g. from a monorepo) won't be able to publish to NPM anymore and will have to find alternative hosting, which will incur further effort on the maintainer side & much reduced visibility/findability of our opensource work. Thank you very much NPM team! Not!

At the very least we're all deserving some actual feedback to these issues, not just an announcement that this is how it's gonna be from January and then absolute silence for months or snarky one-liner replies when people are trying share workarounds for this fiasco and some of the largest changes ever proposed to the NPM ecosystem!

[jattasNI]

The same npm PM who opened this discussion started a new one which provides a response to some of the feedback we've given here: npm’s roadmap: safer publishing, smoother workflows, and what’s next.

[waterkip]

Which means they told us all to go f ourselves:

If you publish with a bypass-2FA granular access token, this affects you.
Direct publishing with these tokens ends in January 2027. Your path forward is a stage-only token plus 2FA approval, or Trusted Publishing. Stage-only tokens are available today — read this post for more details.

They aren't responding here, which is huge red flag.

[gkgoat1]

Quick reminder, #201329 (reply in thread) .

This, as written, will not make NPM safer--it will encourage fake passkeys and communal global key breaches by dusgruntled users, and potentially lead to packages becoming malicious specifically to obtain OIDC global keys or hook passkey-manipulation functions ahead of the deadline solely to ensure they can still publish their legitimate functionality

[teidesu]

gat-s are already annoying to use because of the requirement to rotate them every 90 days. but whatever, its not that much work, just annoying.
but now you're planning to remove that whatsoever, making all publishes manually approved 🥴

so instead of just clicking one "Run release" button in my CI, i need to then wait for 10-15 minutes for the packages to publish and then manually approve them from "staged packages".
imagine approving every publish separately with monorepos? this is nightmare.

and the only solution you are suggesting is.. trusted publishing? at least make it work first, you can't even set it up for not-yet-created packages, let alone use it with non-github CIs (yes, they exist!). and again, imaging setting it up for 20 monorepo packages separately, lol. at least add org-wide trusted publishing settings

this all feels like just a vendor lock in under the security sauce, this brings nothing in terms of security, people will just continue using those GAT-s, but with "bypass 2fa" disabled, and compute the 2FA secret right in the CI.

like this genuinely makes me want to stop publishing to npm whatsoever and move to jsr. because at least their tokens are long-lived, and they actually listen to the community.

[waterkip]

Ok, so the change was expected in Jan 2027 but now I'm confronted with this:

29 verbose stack Error: This command requires you to be logged in to https://registry.npmjs.org/
29 verbose stack     at #publish (/usr/lib/node_modules/npm/lib/commands/publish.js:166:29)
29 verbose stack     at async Publish.exec (/usr/lib/node_modules/npm/lib/commands/publish.js:51:5)
29 verbose stack     at async Npm.exec (/usr/lib/node_modules/npm/lib/npm.js:193:9)
29 verbose stack     at async module.exports (/usr/lib/node_modules/npm/lib/cli/entry.js:67:5)
30 error code ENEEDAUTH
31 error need auth This command requires you to be logged in to https://registry.npmjs.org/
32 error need auth You need to authorize this machine using `npm adduser`
33 verbose cwd /mnt/code/opn/javascript/react-native/events/.build/5ca5db5dcb4fe5a7
34 verbose os Linux 7.2.6+deb14-amd64
35 verbose node v26.10.0
36 verbose npm  v11.19.1
37 verbose exit 1
38 verbose code 1
39 error A complete log of this run can be found in: /home/wesleys/.npm/_logs/2026-09-29T20_01_03_698Z-debug-0.log

So doing that:

$ npm adduser
npm notice Log in on https://registry.npmjs.org/
npm notice npm tokens that bypass 2FA are being restricted for account changes and direct publishing. Learn how to prepare: https://gh.io/npm-gat-bypass2fa-deprecation
Create your account at:
https://www.npmjs.com/login?next=/login/cli/xyz
Press ENTER to open in the browser...
Logged in on https://registry.npmjs.org/.

Then proceed with the release ceremony:

npm notice
npm notice Publishing to https://registry.npmjs.org/ with tag latest and public access
npm error code EOTP
npm error This operation requires a one-time password.
npm error Open this URL in your browser to authenticate:
npm error   https://www.npmjs.com/auth/cli/***
npm error
npm error After authenticating, your token can be retrieved from:
npm error   https://registry.npmjs.org/-/v1/done?authId=***
npm error A complete log of this run can be found in: /home/wesleys/.npm/_logs/2026-09-29T20_03_06_220Z-debug-0.log

But I cannot find any OTP like password. Nice, you are preventing me from publishing, roughly 3 months before the deadline.

I mean, the total disrespect was visible, but rolling out limitations before the deadline is beyond disrespectful.

And it gets worse, even with a GAT that does NOT bypass 2FA you are still greated with this error:

npm notice Publishing to https://registry.npmjs.org/ with tag latest and public access
npm error code EOTP
npm error This operation requires a one-time password.
npm error Open this URL in your browser to authenticate:
npm error   https://www.npmjs.com/auth/cli/***
npm error
npm error After authenticating, your token can be retrieved from:
npm error   https://registry.npmjs.org/-/v1/done?authId=***
npm error A complete log of this run can be found in: /home/wesleys/.npm/_logs/2026-09-29T20_27_01_412Z-debug-0.log

[taraxvoid]

The migration / expected happy-path is non-functional as of today, due to npm/cli#9969