npm’s roadmap: safer publishing, smoother workflows, and what’s next

[leobalter]

Hi everyone, Leo here, npm's PM.

I want to share what we’ve shipped since May, where we’re focusing for the rest of 2026, and what we’re considering for 2027. I also want your feedback: what would make npm safer while making it easier to publish and consume packages?

Our immediate priority is making safer publishing practical across the workflows maintainers actually use. That means improving the alternatives before removing direct publishing through granular access tokens that bypass two-factor authentication.

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.

We’ve heard requests for more Trusted Publishing providers, more flexible permissions, and better visibility into publishing. Those requests matter. Here’s how they fit together—and why we’re sequencing the work this way.

What’s changing, and what isn’t

Changing: bypass-2FA granular access tokens will no longer be able to publish a version directly. We announced this in July.

Not changing: token-based automation itself. Your CI can still run unattended. The publishing path becomes stage from automation, then approve with 2FA. Trusted Publishing workflows, scoped and private package publishing, and normal interactive npm publish with 2FA are unaffected.

A minimal migration looks like this—automation stages, a human releases:

# CI stages the version with a stage-only token
- run: npm stage publish
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_STAGE_ONLY_TOKEN }}
# The version is now staged, not published.
# A maintainer approves it from the package’s staged-versions view with 2FA.

If you use Trusted Publishing, you can continue to use npm publish to publish directly instead of relying on a stored token.

What we’ve shipped since May

These changes address different parts of the same problem: protecting maintainer accounts, reducing what compromised credentials can do, and giving consumers more control over what they install.

• Staged publishing and install-source controls. We made staged publishing generally available, separating the automated upload of a package from a maintainer’s approval to release it. We also added controls for installing dependencies from nonregistry sources. Staging works alongside Trusted Publishing: a workflow can use OIDC to stage a version, with a maintainer approving it through 2FA.
• Safer installation defaults in npm v12. After announcing the changes in June, we shipped those defaults in July, requiring explicit opt-in for dependency lifecycle scripts, Git dependencies, and remote-URL dependencies. These give you more control over code execution and dependency sources during installation.
• Publish-time malware scanning. Packages are scanned before becoming available to install, with findings potentially leading to manual review or blocking. We also introduced disclosure metadata for legitimate dual-use packages. Scanning is another layer of protection—not a guarantee that every malicious package will be detected.
• Stronger account protection. We introduced preventive holds for high-impact accounts, then extended recovery-code security holds to all accounts. A successful recovery-code sign-in triggers a 72-hour hold on publishing and other sensitive writes, while sign-in and package consumption remain available.
• Reduced permissions for bypass-2FA tokens. These tokens can no longer perform sensitive account, organization, and package-management operations, such as creating tokens or changing maintainers. Those operations now require interactive 2FA. This was a first step toward the January 2027 change above.
• More flexible Trusted Publishing and better staged-version visibility. Packages can now have multiple Trusted Publishing configurations, helping maintainers support separate release workflows without keeping a token for the exceptions. We also added staged-version history and made staged approval wait until scanning completes.

Our focus for the rest of 2026

We’re evolving granular access tokens around what automation actually needs: preparing releases, without giving a stored credential the authority to publish them. Automation handles preparation; a person authorizes publication. Possession of a CI token alone is no longer enough to release a version.

To make that transition workable, our current priorities are:

• Stage-only granular access tokens. Available today in preview mode, ahead of the formal GA announcement. These tokens can read packages and stage new versions, but cannot publish directly. This is the primary migration path if you can’t move to Trusted Publishing yet.
• New package creation through staged publishing. Automation should be able to create a package and stage its first version without requiring a separate manual first publish.
• Expanded opt-in Trusted Publishing permissions, including dist-tag operations, so more of your release workflow can work without a separate token.
• Publishing plans with batch approval, reducing approval friction when releasing multiple packages.
• A combined publishing activity view, bringing together packages awaiting staged approval and a history of publishing, approvals, and rejections—including direct publishes.

These are our priorities for the remainder of 2026, rather than individual delivery-date commitments. The goal is not just to remove a risky capability. It’s to make the safer path usable for maintainers releasing one package or coordinating many.

If you publish on a schedule, or release many packages at once, we especially want to hear from you. Nightly builds and large monorepo releases are the cases where “a maintainer approves with 2FA” adds the most friction. Batch approval and publishing plans are aimed squarely at this, and we’d rather find out now if we have the shape wrong.

Why additional Trusted Publishing providers come next

If your CI provider isn’t supported, that is a real workflow gap. Token management and rotation add work, and asking for a token-free integration is reasonable.

We’re prioritizing improvements that make staged publishing usable across CI/CD systems before taking on additional provider integrations. We want npm to work well for maintainers on any CI/CD system, which is exactly why we’re improving the provider-independent path first.

Staged publishing is not the same as native OIDC support: token-backed staging still requires credential management, and promotion adds an approval step. We’re not presenting it as complete parity. It is a broadly usable migration path while we work toward wider token-free support.

Adding a trusted provider also requires more than recognizing an OIDC token. We need to evaluate the identity claims and security controls behind the publishing authorization. We want to make that integration process more repeatable, while maintaining a meaningful trust standard.

For that reason, we’re not planning additional provider integrations during the remainder of 2026, but we plan to expand support including new trusted publishing providers as part of our work for 2027.

What we’re considering for 2027

These are directions we’re evaluating, not a committed delivery schedule or an exhaustive list:

• More Trusted Publishing providers, expanding native, token-free publishing options.
• Finer-grained token permissions, such as read-only scopes, staged-package access that doesn’t grant read access to published private packages, or permissions limited to dist-tag operations, and more.
• Namespace-level OIDC configuration and scoped package creation, reducing repeated setup across existing and future packages.
• Richer package and dependency insights, making dependency trees and known vulnerabilities affecting particular versions easier to understand and audit.
• Additional opt-in Trusted Publishing controls, potentially restricting direct publishing to identity claims that demonstrate a human verification step in the workflow.
• Broader stage-only OIDC support, allowing additional CI providers and workflow origins to submit staged packages without automatically granting direct-publish access.

We’ll prioritize this work using security impact, community feedback, conversations with maintainers, and evidence about the workflows and providers people use to publish to npm.

Help shape what comes next

I’d like to hear from both publishers and package consumers:

1. Which items on this roadmap would help you most, and what’s missing?
2. Where would moving to Trusted Publishing or stage-only automation create friction for your release workflow? Tell us about your CI provider, release frequency, or multi-package setup where relevant.
3. What would make installing, updating, or evaluating npm packages both safer and easier for you?

Specifics help us a lot here: what you’re trying to do, and where the experience falls short. You don’t need to propose a solution. I’ll be reading this thread through the end of this semester and will follow up in January with what we heard and how it changed our plans.

Thanks for helping us make npm safer and better to use.

[ljharb]

The primary thing that is needed here, imo - which would have worked even in a world with full TOTP tokens, no staged publishing, no provenance, and no OIDC/trusted publishing - is the capability in a GitHub Actions workflow to pause, prompt a maintainer with predetermined form inputs, allow the maintainer to submit the form, and then resume with that input.

That generic capability would make it trivial for me to, for example, run npm pack, pause and prompt for an OTP code, and then resume and immediately npm publish --otp=$OTP packed.tgz - the perfect scenario: 2FA with proof of presence, publishing from a reproducible environment, with auditable build steps. Is this on the Actions team's roadmap? The feature would of course support a plethora of other use cases, and it would obviate the need for workflows to poll, or wait for webhooks, or rely on external servers to dispatch new workflows (which costs github lots of overhead spinning the old job down and the new one up).

[matthewp]

The other day I set up OIDC for a bunch of packages in an org and I probably entered my OTP 20-30 times to do so. If you're doing a single package I think you need to enter your OTP at least 3 times. You have to enter it to login. I have to login almost every time I use npm (the CLI). Then to see the Settings page you have to enter the OTP. To save a connection, another OTP. I might be missing one. Oh, to publish the initial version (which you must do before these pages exist, of course), OTP. So a minimum of 4 times to set up a new package.

I guess I have two wishes from this:

• Once I'm on the website I don't see why I need to re-enter the OTP for every little thing.
• For this particular flow, please allow the CLI to set up the OIDC stuff so an agent can do it, and preferrably give me a window of time so that I only need to enter the OTP once.

[leobalter]

You can already use the cli for it. npm trust allows you to add OIDC configurations for multiple packages.

[Tobbe]

I'd really like to see a fix for npm/cli#8547 on the roadmap for 2026.
Right now I'm planning to move off of npm because I can't create dist-tags. I'm looking at pkg.pr.new instead for one of my workflows that'd need dist-tag add/rm

[SerenModz21]

Following on from https://github.com/orgs/community/discussions/201329 and https://github.com/orgs/community/discussions/206745: support for dist-tags is being worked on and should be available soon.

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

source: https://github.com/orgs/community/discussions/201329#discussioncomment-18486892

[Tobbe]

I have a monorepo with 70+ packages. A publish that fails halfway leaves consumers that target @latest with a mixed-version install.

I currently work around this by giving all packages a throw-away dist-tag when I publish them. And then once all are published and verified I switch them all to the latest tag. It's stil not instant, but the gap where consumers can see different versions for @latest goes from hours to seconds with this approach. An npm-native way to do this would be amazing. A way that can be automated and run as part of CI.

[Tobbe]

For me, only allowing one trusted publisher per package, keyed by workflow file name, is forcing me to manage all my publishing (canary, RC, stable, cleanup) through one file. Some more flexibility here would be great, so I for example could have one workflow per type of release I want to make.

(And if you wonder what "cleanup" is, it's for cleaning up orphaned dist-tags from broken releases)

[SerenModz21]

In case you're not familiar with the recent news, https://github.blog/changelog/2026-09-03-multiple-trusted-publishing-configurations-for-npm/ gave us the option to have multiple trusted publishing configs. As for dist-tags, I have gone over that in my reply to your previous comment.

Note: I am not an employee, but rather another user like yourself.