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

[pushkarupadhyay587-a11y]

good

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

[naugtur]

A page/guide in the docs showcasing what the optimal workflow for a workspace with many packages should look like according to NPM would be helpful. You could steer people to using npm trust at scale or explain what the expected way to set up a new package is (until staging a new package ships) and keep updating the page as it improves.

[theoephraim]

FYI - I made a helpful tool for this - https://fledgling.varlock.dev
It lets you create new placeholder packages, set up trusted publishing, and sync trusted publishing settings to many packages within a monorepo. It uses npm trust under the hood, but gives you nicer DX to do things declaratively, especially in a monorepo.

[naugtur]

I'm not sure this is what npm terms of service would encourage.

Claims package names on npm — one command, from any directory, no repo or package.json needed. Got a name for that idea? Grab it before someone else does.

Otherwise pretty cool, although I wouldn't run someone else's code while logged in to npm cli.

[theoephraim]

Yeah the point is definitely more about the trusted publishing - but it has been very useful to claim a name quickly when starting a project. Hopefully only to be used responsibly :)

Fair enough - it has been working great for me and for the varlock monorepo. When I add a new package or change the trusted settings, I just run one command and its done.

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

@SerenModz21 Thanks for sharing, that's great news!

[SerenModz21]

OIDC support for dist-tags has now been released: https://github.blog/changelog/2026-09-30-opt-in-dist-tag-permissions-for-npm-trusted-publishing/

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

[RaJharit77]

I completely agree. The temporary dist-tag approach is a clever workaround, but this feels like something npm should support natively.

For large monorepos, being able to publish and promote multiple packages as a single coordinated release would prevent consumers from seeing mixed versions if something fails during the process. A CI-friendly workflow for this would be extremely valuable.

[CyberNativeAI]

For your temporary-tag → latest workflow, the September 30 npm update removes one specific blocker: trusted publishers can now manage dist-tags. It requires npm 11.21.0+ on the v11 line or 12.2.0+ on v12, and an explicit “Allow npm dist-tag” setting on the intended trusted-publisher configuration. It is off by default and independent of direct publishing.

Sources: announcement and npm’s tag-operation documentation.

That addresses tag authorization; it does not establish an atomic release across your packages. The roadmap treats batch approval and publishing plans separately. For your existing release process, a useful inventory is one row per package: intended version, candidate tag, publish/scan status, current latest, and the workflow allowed to promote it. That separates “all candidates are ready” from “all latest pointers have moved” when diagnosing a partial release.

This is a source-based reading, not a tested migration or security assurance. CyberNative AI is an AI-run company; this reply was prepared with AI. We are not speaking for npm or GitHub.

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

[RaJharit77]

The staged publishing approach makes sense, especially for security. For large monorepos, though, approving packages one by one could become painful. Batch approval and publishing plans would be really useful to make the transition practical.

[theoephraim]

I want to use staged publishing - but I won’t do it until we get batched approval. It’s too tedious without, and it can result in a period where some new packages are published and others are not

[idubinskiy]

I don't know what GitHub's or npm's definition of "broadly usable" is, but so far it's looked like continuing to degrade the experience for anyone (including paying customers) not using one of three blessed CI providers while ignoring concerns for months and then downplaying the impact when finally hinting at addressing them at an undetermined time that may be sometime next year but may leave us waiting until the 2030s.

Asking for specifics on CI providers and other details here also feels disingenuous considering the dozens of comments on preceding posts around these changes that have provided those kinds of answers over and over.

[JoviDeCroock]

My feedback is over at https://github.com/orgs/community/discussions/207561 - mainly I've been seeing a lot of issues with regards to the malware scanning. It's been ineffective at catching the vulnerabilities since it launched as well as it's been hampering publishes for hours sometimes which I've also heard from multiple people now.

I'd love if we could plug external validators like aikido.dev, socket, ... into the staged publishing thing and enable that external party to report approval alongside maintainer approval. This would allow us to setup secure pipelines where multiple maintainer approval, ... is required.

[naugtur]

• +1 to plugging in my own validators, including a bridge to things like pagerduty or discord, while we're at it.
• Scanning delay is understandable, but it currently gets in the way of publishing:

The current publishing experience has an unpredictable factor of not knowing when to go approve staged packages. It is difficult especially for a monorepo with multiple packages with dependency relationships between them.
Having the ability to stage a group of packages where a group can be indicated at staging time and approval is for the whole group to be published in reverse dependency order after all packages are successfully scanned would be great.

If computing the reverse dependency order is considered too complex for this feature, the group id could contain a sorting indicator:

group-id:order-by

npm stage publish --group=release1.2.3:03
npm stage publish --group=release1.2.3:01
npm stage publish --group=release1.2.3:02
npm stage publish --group=release1.2.3:zzz_dead_last

With that, UI would offer a button to approve all of release1.2.3 in one click and then proceed to release in the alphabetical order of the order-by

That being said, I'm pretty sure npm cli already contains all the code necessary to figure out what a reverse dependency order would be.

• Nitpick: the email notifications all start with "Successfully" which pushes the most important information off to the right. Would be fine if it was at the end of the subject line.

[UnknownOrange]

I'd like to see a freeze on changes outside of critical security updates until a better QA proccess is put into place.

My npm package deployment pipeline broke after changes made last year. I'm not wasting my time repeatedly fixing my deployment workflow to keep up with breaking changes.

[coreybutler]

I know publishing needs to be the top priority, but there are some tooling aspects I hope are considered as well.

In nvm-windows v2, we've put effort into local toolchain security and E2E guarantees (i.e. assure you're running the intended npm version and not evil-agent dressed up as npm). This includes a code-signed npm shim, i.e. npm.exe on PATH to directly invoke npm-cli.js. This has worked very well so far, but brought up questions around npm ABI design/guarantees.

For example, some ASP.NET core tools explicitly look for npm.cmd. Some organizations have npm compatibility issues with PowerShell ConstrainedLanguage mode, which struggles with the existence of npx.ps1. So far, I've explained to users the only ABI guarantee is that a npm executable will be on PATH, but file type is not guaranteed.

There needs to be some guidance steering people away from using hard-coded npm entry points. I have thoughts on the shape of this (happy to offer my feedback if there is a desire for it), but just having some kind of official statement from npm would go a long ways for those of us trying to securely integrate with npm tooling.

[theoephraim]

I know y'all are stretched thin, so to me the best thing you can do is prioritize features which enable more automation and for external tooling to fill in the gaps.

For me, the biggest issue is how staged approvals work. I want to build my own tooling (or use 3rd party tools) with malware scanning, multi-party approval logic, and batched approvals (this one is very important!). I'm ok with owning the security around this - but we need a new capability for an API key which can only do approvals, and to disable approval for the package any other way.

I've laid it out here in this discussion - would love some kind of response.

[jedwards1211]

What would make trusted publishing easier is better error messages. Npm doesn't even log OIDC failures by default. A good PM cares about the error experience as well as behavior in successful conditions, and specifies what the error experience should be before it becomes an oversight

[naugtur]

Rejections from the scan should be informative. The package disappearing from the staged list with no email notification is making the false positives harder to deal with than necessary.

I was babysitting a publish and at one point one of the packages waiting for a scan disappeared from the staged list with no notification or information why. I'm assuming it didn't pass the scan this time (README was the only change)
Adding dual-use setup helped instantly. The next version was swiftly scanned. People who are not on top of the latest news will not figure it out without a notification pointing them to documentation about dual-use though.

[jedwards1211]

An audit log within npmjs.com (behind login) of why seemingly valid OIDC tokens are rejected would sure help, there's no telling for 404 responses

[ibrahimchiha-rev]

@leobalter to answer your question about release workflow friction: we currently use TeamCity in our organization and we only recently started releasing packages to the public registry. We're looking into automating it and the work is underway. The provider situation is the annoying part: no trusted publishing for TeamCity means either long-lived tokens we'd have to migrate off later, or staging + approval in the loop.

Worth noting JetBrains shipped an OIDC JWT plugin for TeamCity in September (TeamCity 2025.11+) that seems to cover the CI side of trusted publishing: short-lived audience-scoped JWTs, JWKS, configurable issuer for servers not exposed to the internet (source). Might make TeamCity a lower-effort candidate for the 2027 provider expansion than a from-scratch integration.

[TimRoe]

Once again, similarly to the previous thread, noting it's ridiculous that NPM--a product owned by GitHub--doesn't even support trusted publishing for GitHub orgs with data residency ([org].ghe.com hosted) while forcing through these changes.

If you publish on a schedule, or release many packages at once, we especially want to hear from you.

My team publishes multiple packages on a regular ~weekly cadence. We used trusted publishing--until our org forced through migrating to GH w/ data residency which required reworks back to granular tokens and added wasteful overhead managing tokens. Now, in January, you're going to waste more of our resources trying to coerce people to trusted publishing that's literally impossible for us to implement or we'd already be using it. Our org pays NPM/GH over $100,000/mo; it feels ridiculous we need to keep wasting engineering time just to be able to have seamlessly functioning CI for publishing NPM packages.

Is the auth even any different for .ghe.com instances vs standard GH? Are you going to waste more of our engineering time breaking our publishing flows again than it'd take one NPM engineer to add an additional field to route the same formed request to [org].ghe.com instead of github.com?

It's not helpful to plan to get around to it some ambiguous time in 2027 after already breaking things more again before, when it is finally added, needing to invest engineering time to update publishing flows again. It's poor product management to force a transition when it's literally impossible for so many end users to adopt the preferred behavior.

[tmccombs]

I have a flow where CI automatically publishes every week if there are changes. Requiring a human to approve the publish every time with 2FA would be extremely inconvenient and wasteful of time. It also means needing to grant access to the npm package to more people, so they can approve the published versions, which seems like it actually decreases security. The migration path that requires this for CI that doesn't use the currently supported trusted publishes is not "boradly usable".

And "trusted publishing" is problematic, not just because we don't use one of the currently supported CI providers, but because we use self-hosted CI inside a private network. Adding additional cloud providers isn't enough. You also need to have some way to support a custom, self-hosted CI system that doesn't have a publicly accessible Identity Provider.

[leobalter]

We are adding more providers and plan to continue add more.

I understand staged publishing creates a step but this step is ultimately important to avoid malware attacks and increase the security of how packages are published to the registry.

[tmccombs]

Adding more providers doesn't fully solve the problem. There will always be more CI systems that aren't included.

[SerenModz21]

Perhaps npm deprecate could also gain OIDC support?

@favware/npm-deprecate, an example I used in the dist-tags discussion, actually only calls the deprecate command. I had remembered it wrong.

What are your thoughts, @leobalter?

[leobalter]

This is very good! Both deprecate and unpublish are in my radar as they are also used following publish commands, just not as much as dist-tag.

I want these to become part of a larger story of a larger set of fine grained permissions set for both trusted connections and GAT. I want this work to be part of the first half of 2027.

The best workaround for now to allow npm deprecate would be adding a new GAT that has no publish access, it's the new "read and write (stage only)" token.

[mrgrain]

I love the idea of staged publishing, not only for larger monorepos but also to plug-in my own tooling and verify the staged package before hitting release.

I am aware that staged publishing is currently build primarily as a tool to allow use of tokens without 2FA. However I think there's also a pretty good use case to use OIDC permissions (trusted publishing) to publish staged packages. Imagine the following scenario:

• Use OIDC to stage all packages of a monorepo as a group
• Run custom validation tooling over all packages
• Have a separate workflow or approval gated job on GitHub to publish the staged group

Worst case, publishing staged packages using OIDC does not lower the security bar compared to publishing with OIDC right away.

[tats-u]

When you stage a package that does not yet exist, npm publishes a placeholder version of the package with the version 0.0.0-stage. This placeholder version is publicly available, but the staged version and its contents are not publicly available until a maintainer approves the staged package. After approval, the staged version is published to the package page.

The placeholder version should be automatically unpublished when the staged version is published, disallowed to be downloaded (throw an error when tried to be downloaded), or able to be unpublished any time.