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.

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

[tats-u]

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.

How the hell can I publish a new package via GitHub Actions without them? Both of them should only apply to published packages, shouldn't they?

[Booyaka101]

For anyone auditing their own repos ahead of the January 2027 change: I put the check into a CLI, because the two questions that actually matter turned out not to be "do I publish with a token" but "is the recommended fix even available in this repo".

npx npm-script-lens publish --check

It reads .github/workflows/*.yml, .gitlab-ci.yml and .circleci/config.yml (no network, no YAML dependency), finds npm publish / npm stage publish / pnpm publish / yarn npm publish / np / semantic-release / changesets/action / JS-DevTools/npm-publish, and classifies each publish path as TRUSTED (an id-token grant and no token), STAGED, TOKEN, or UNKNOWN. It exits 1 only on TOKEN — UNKNOWN and repos with no publish step pass, so it is safe to drop into CI today.

The parts I hadn't seen covered anywhere, and which bit me first:

1. Version floors. Trusted publishing "requires npm CLI version 11.5.1 or later and Node version 22.14.0 or higher"; staged publishing requires npm 11.15.0 / Node 22.14.0. If your release job pins node-version: 20, migrating to OIDC fails at the first publish — so the tool reads your setup-node pin and engines.node and tells you which fix that pin blocks.
2. Runner eligibility — the point several people raise above. The docs support only GitHub-hosted runners, GitLab.com shared runners and CircleCI cloud: "Self-hosted runners are not currently supported but are planned for future releases." So for a runs-on: self-hosted publish job it marks trusted publishing UNAVAILABLE and routes you to the only path that survives there — npm stage publish plus a human npm stage approve <stage-id>. Same conclusion for Azure Pipelines/Bitbucket today: staging still works, since staging needs no bypass-2FA scope.
3. The npmjs.com side, pre-filled — org/user, repository, the workflow filename with its extension, the environment name if the job declares one, and the allowed actions, so you can fill the trusted-publisher form without guessing which of your workflow files npm wants named.

TOKEN paths also print the concrete patch (add permissions: / id-token: write, drop the NODE_AUTH_TOKEN env) anchored to the real line numbers, and there is a SARIF rule + an opt-in GitHub Action input if you want it as a gate rather than a report.

MIT, no telemetry, no account needed: https://github.com/Booyaka101/npm-script-lens — happy to add any provider or publish tool I've missed, and corrections welcome if I've read any of the requirements wrong.

[iminsoftware]

我觉得不够友好，太不方便了。现在只能用硬件设备采集。为什么不增加一个使用MFA有效时间的验证码来验证？目前这个

真的很不好用

[Booyaka101]

Following up on my comment above with a correction that matters for anyone auditing their readiness, whether or not you use my tool.

If your release job delegates to a local composite action:

# .github/workflows/release.yml
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: ./.github/actions/release
        with:
          npm-token: ${{ secrets.NPM_TOKEN }}

…then the npm publish and the NODE_AUTH_TOKEN live in .github/actions/release/action.yml — not in the workflow. Any audit that reads only .github/workflows/*.yml reports zero publish paths and hands you a clean bill of health. That includes a manual grep -r "npm publish" .github/workflows, and it included my own tool until this week. It is the worst failure mode for a deadline like this one: silence that reads as safety. The same blind spot applies to a job-level uses: ./.github/workflows/reusable-release.yml — the publish is one file over.

Worth a manual check even with no tooling involved (note .github/, not .github/workflows/):

grep -rlE "npm (publish|stage publish)|pnpm publish|yarn npm publish|semantic-release" .github/

Three things I learned fixing this that are useful regardless of what you audit with:

1. Composite actions cannot declare permissions. The id-token: write grant that makes trusted publishing work has to sit on the calling job. If you migrate a composite-action release to OIDC by adding permissions: to the action.yml, it silently does nothing.
2. The token usually arrives indirectly. The composite has env: NODE_AUTH_TOKEN: ${{ inputs.npm-token }}, and the caller passes with: npm-token: ${{ secrets.NPM_TOKEN }}. You have to resolve inputs.* back through the caller's with: map to tell a real long-lived token from an unresolvable input.
3. npmjs.com's trusted-publisher form wants the calling workflow's filename, not the composite's — the composite is not what the OIDC claim names.

Fixed in npm-script-lens 1.7.0: local composite actions and local reusable workflows are resolved from the working tree and scanned with the calling job's grant, findings anchor to the real action.yml line, and the call chain is printed. Third-party actions are never guessed at.

publish paths (1)
  TOKEN     .github/actions/release/action.yml:16  npm publish   [job release · ubuntu-latest]
            long-lived token: NODE_AUTH_TOKEN in the composite step env, fed by the caller's `with: npm-token` (line 19)
            via .github/workflows/release.yml:11 (job release, step "Release")

npx npm-script-lens publish --check — still exits 1 only on a confirmed long-lived-token path, so it stays safe to drop into CI today.

[slootjes]

Agreeing with others: add support for other major CI/CD providers before forcing other (more cumbersome) methods to your users. The bitbucket pipelines rfc is open for months without any feedback.

[postspectacular]

I agree with that, but since when did releasing via CI/CD platforms become a hard requirement for releasing open source software, even if for some/most people more convenient? We also need to retain viable options for other solutions, which can be automated and do not require manual intervention/approval for every single package/publish... the current proposal for the latter is just completely unworkable and feels like a non-option given to pretend there's an alternative to TP via MSFT approved providers. Ridiculous situation!

[sudocurse]

Before we tighten these restrictions, we want to make sure every legitimate workflow has a viable path forward... We're using this feedback to close the remaining gaps before enforcement,

Hey @leobalter any updates on these use cases being discussed here? Your original post leaves me confused about whether or not we should expect enforcement soon or not

[Zeouterlimits]

I think this needs to be delayed - we should have much more extensive OIDC support before proceeding.
Personally this would block us as we use TeamCity for CICD.

[yinzara]

I couldn't agree more. This is being forced on us far too quickly without support for many major CI/CD providers like BitBucket Pipelines or Google Cloud Build. This is simply not ok right now and needs to be rethought for a future time.

I will simply have to move off of npmjs.org completely and use Google Cloud Repositories and stop paying for NPMJS all together.

[gourab337]

Which mf came up with this stupid idea to remove 2FA bypass on GATs?!!!!

[iminsoftware]

反正这个验证很难用，不知道他们团队怎么想的，太糟心了

…

---Original--- From: "Gourab ***@***.***> Date: Thu, Aug 20, 2026 12:51 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [community/community] Upcoming changes to npm 2FA-bypass granular access tokens (GATs) (Discussion #201329) Which mf came up with this stupid idea to remove GATs?!!!! — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[domdomegg]

The path to automated OIDC publishing still doesn't seem to have been laid out fully, despite these complaints being raised in September 2025: https://github.com/orgs/community/discussions/161015#discussioncomment-14451893 (and again in December 2025: https://github.com/orgs/community/discussions/179562#discussioncomment-15221604)

The "Namespace-wide OIDC configuration" might mitigate this somewhat, but it sounds like you're imagining this as restricted to a scope (e.g. @scope/*), rather than allowing publishing to unscoped packages.

This will not work for users who have many unscoped packages.

In fairness, I think there may have been some confusion about the definition of "namespace", given it isn't actually very well defined in the NPM world. I expected "namespace" to mean the global single namespace of npm, but could see how this was interpreted as scope. Regardless, it would be good to have a solution that works for unscoped packages!

[domdomegg]

Slighly less important (than this) feedback regarding the communication of these updates:

We know some of today's workflows don't yet have a clean path off these tokens. [...]
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.

This seems like a particularly difficult position to put people in - to give people a deadline to migrate, but no path and no committment to having any kind of path ready?

"Before we tighten these restrictions, we want to make sure every legitimate workflow has a viable path forward."

This feels a little tone deaf to post (and not helped from the post being a bit AI-slop-ish) when the same concerns seem to come up on every one of these posts, and they don't seem to get addressed in future updates.

[sudocurse]

Agreed- those statements are actively contradictory and I don't think anyone genuinely reviewed this before posting

[ianling]

As supply chain attacks increase, I think it is increasingly important that npm discloses whether a package was published using some form of MFA, OIDC, or neither. OIDC alone will not prevent an attacker with access to git push or merge PRs in a repo. MFA will. Users of npm should be allowed to see and prevent installation of packages that were not published using MFA.

Supply chain attacks could be completely halted today if packages could not be published without MFA. In nearly 100% of cases, supply chain attacks on npm are able to succeed because only one authentication factor needs to be compromised in order to publish. As a user, I should at least have access to this basic information so I can make informed decisions about what packages I want to depend on.

[jedwards1211]

@leobalter

MAKE CIRCLECI MONOREPO TRUSTED PUBLISHING WORK BEFORE RESTRICTING 2FA-BYPASS

https://github.com/orgs/community/discussions/191807#discussioncomment-18167274
https://devactivity.com/insights/monorepo-publishing-woes-oidc-trusted-publishing-fails-for-nested-packages-impacting-engineering-productivity/

[ebndev]

Hi there,

Please note, contacting any member of GitHub Staff via unsolicited mentions or pings is strongly discouraged and may be considered a violation of our prohibition against harassment. Please review our Code of Conduct for more information.

Let's work together to keep GitHub Community a place where people feel safe to participate by being respectful of them and their time.

Any repeat and future violations may result in a temporary or indefinite block from the Community. Thanks for understanding.

[jedwards1211]

This rollout risks being disruptive because the DX of npm trusted publishing is not good enough yet. Don't be mad at me for being anxious and trying to be the squeaky wheel getting my voice heard. Npm just needs to do better. I'm a paying customer

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

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