npm Can Now Trust Multiple CI Publishing Paths per Package—So You Can Retire More Long-Lived Tokens

Short answer: npm’s trusted publishing is no longer limited to one OIDC configuration per package. As of September 3, 2026, a package can have multiple independent trusted-publisher configurations, which makes it much easier to run separate stable, prerelease, staging, repository, or CI-provider release paths without keeping a long-lived npm write token around for the exceptions.

The safest default is not to give every workflow direct npm publish permission. npm now recommends configuring trusted publishers for staged publishing where practical, so CI can prepare a release but a maintainer still has to approve it with 2FA before it becomes public.

Feature check — September 5, 2026: npm’s current documentation says a package can have up to 10 trusted publishers. Trusted publishing currently supports GitHub Actions on GitHub-hosted runners, GitLab.com shared runners, and CircleCI cloud. Self-hosted runners are not currently supported. Trusted publishing requires npm CLI 11.5.1+ and Node 22.14.0+; staged publishing requires npm CLI 11.15.0+ and Node 22.14.0+.

What changed this week

Previously, npm allowed only one trusted-publishing configuration for a package. That was enough for a simple release pipeline, but awkward for projects with different release paths.

For example:

main branch       → stable release
next branch       → prerelease
manual workflow   → emergency release
security workflow → staged patch

If only one of those could use OIDC, maintainers often had to redesign workflows around the restriction or retain a reusable npm token for the paths that did not fit.

npm now lets each package have multiple additive configurations. Each configuration can define its own:

• CI provider;
• repository;
• workflow;
• environment criteria;
• permission to stage;
• optional permission to publish directly.

A publish or stage is accepted when the incoming OIDC identity matches any one configured publisher.

The important security implication is straightforward: more legitimate release paths can now use short-lived OIDC credentials instead of a stored write credential.

OIDC vs a traditional npm token

A traditional automation token is a secret that exists before the job starts and remains usable until it expires or is revoked. It has to be stored somewhere CI can retrieve it.

Trusted publishing works differently. The CI platform presents a short-lived, cryptographically signed OpenID Connect identity token describing the workflow that is running. npm checks that identity against the package’s trusted-publisher configuration and authorizes that specific publish operation.

This does not mean tokens disappear from every npm workflow. A project may still need a read-only token to install private dependencies, because trusted publishing authenticates the publish operation rather than ordinary npm install, npm view, or other registry commands.

The strongest use case: separate stable and prerelease workflows

Imagine a package with two release workflows:

.github/workflows/release.yml
.github/workflows/prerelease.yml

Previously, if the package’s one OIDC publisher was tied to release.yml, the prerelease path needed a workaround or another credential.

Now the package can trust both independently.

A clean design could be:

The benefit is not merely convenience. It removes pressure to create one overly broad workflow simply because npm used to allow one identity relationship.

Multiple configurations are additive, not a priority list

There is a subtle rule worth designing around: npm says trusted-publisher configurations do not restrict one another, and evaluation order is not guaranteed.

Do not build logic like:

try publisher A
if that does not match, publisher B becomes less privileged

That is not how the authorization model works.

Instead, think of the package configuration as a set of independently valid doors:

workflow A matches → allowed according to A's permissions
workflow B matches → allowed according to B's permissions
workflow C matches → allowed according to C's permissions

Every configured door therefore needs to be safe on its own. Adding a tightly protected stable workflow does not neutralize a second configuration that is too broad.

Stage by default when a bad publish would be expensive

Trusted publishing removes a long-lived credential, but it does not make the workflow itself trustworthy.

If a release workflow is compromised, a direct-publish permission can still let the compromised workflow push a malicious package version while its OIDC identity is valid.

That is why staged publishing is an important second layer.

With staged publishing:

CI builds package
      ↓
`npm stage publish`
      ↓
package waits in staging
      ↓
malware scan completes
      ↓
maintainer reviews
      ↓
2FA approval
      ↓
version becomes public

npm’s September update also changed the staged queue so the Approve button remains disabled while npm’s publish-time malware scan is still running. Maintainers can see staged history and whether versions were approved, rejected, or are still staged.

For a widely depended-on package, that human checkpoint is often a reasonable trade: release automation still does the repetitive work, but a compromised CI job cannot immediately turn its output into a public version.

When direct OIDC publishing is reasonable

Staging is not automatically right for every project.

Direct trusted publishing can make sense when:

• releases are frequent and low-risk;
• rollback/deprecation procedures are mature;
• the workflow has strong branch and environment protection;
• the package has a small blast radius;
• the team intentionally accepts fully automated publication;
• another control reviews the exact artifact before the publish job starts.

The useful question is not “Is OIDC secure?” It is:

If this exact workflow is compromised for one run, should it be able to make a package version public without a human checkpoint?

If the answer is no, use OIDC plus staged publishing rather than falling back to a permanent token.

A practical migration from NPM_TOKEN

Do not delete the existing credential first. Migrate in an order that leaves a working release path while you verify OIDC.

1. Inventory every publishing route

Search for the obvious secret and the less obvious variants:

rg -n "NPM_TOKEN|NODE_AUTH_TOKEN|npm publish|npm stage publish" .github .gitlab-ci.yml package.json .npmrc

Also check CI secret stores and organization-level reusable workflows.

Write down which jobs actually publish, which only install private dependencies, and which are no longer used.

2. Create a trusted publisher for each real release path

On npmjs.com, open the package settings and add the CI/repository/workflow identity for the release path.

npm currently supports up to 10 configurations per package, enough for several deliberately separate workflows without turning one publisher into a catch-all.

For GitHub Actions, the configuration can include:

• organization or user;
• repository;
• workflow filename;
• optional GitHub environment;
• allowed publishing actions.

The workflow filename must identify a workflow under .github/workflows/.

3. Give the workflow OIDC permission

For GitHub Actions, the publishing job needs the appropriate OIDC token permission, commonly:

permissions:
  contents: read
  id-token: write

Do not use write-all merely to make OIDC work. Grant the permissions the release job actually needs.

4. Test staging before direct publication

For a high-impact package, make the first migration target:

npm stage publish

Then inspect and approve the staged artifact using npm’s staged-publishing flow with 2FA.

That proves three separate things:

1. npm recognizes the workflow’s OIDC identity;
2. the release job builds the intended artifact;
3. maintainers can complete the approval path.

5. Restrict token publishing only after OIDC works

npm recommends enabling trusted publishers first, verifying them, and then changing package publishing access to require 2FA and disallow traditional tokens where appropriate.

After the new path is proven, revoke automation tokens that are no longer needed.

This order prevents a security migration from becoming an emergency release outage.

Do not delete every npm token blindly

Trusted publishing covers publication, not every registry operation.

A release workflow that installs private packages may still need authentication before it reaches the publish step. npm recommends using a read-only granular token for private dependency installation while letting OIDC handle publication.

Conceptually:

read-only token → npm ci for private dependencies
OIDC            → npm publish / npm stage publish

That separation is much better than using one write-capable secret for both jobs.

The read path gets only the permission it needs; the publish path gets a fresh workflow-bound credential when it needs it.

Watch the runner limitation

As of September 5, trusted publishing supports:

• GitHub Actions on GitHub-hosted runners;
• GitLab.com shared runners;
• CircleCI cloud.

npm says self-hosted runner support is planned but is not currently available.

This is one of the main reasons some teams cannot remove publishing tokens yet. If your release process has to run on a self-hosted runner because of private networking, signing hardware, compliance controls, or a custom build environment, do not claim the token migration is complete until npm supports that path or the release architecture changes.

Provenance is a useful bonus, not the reason to skip review

For eligible public packages published from public repositories through trusted publishing on GitHub Actions or GitLab CI/CD, npm automatically generates provenance attestations.

That gives consumers cryptographic information about where and how the package was built.

Current caveats matter:

• CircleCI trusted publishing does not currently generate npm provenance;
• private repositories do not get automatic provenance even if the package is public;
• provenance says where the artifact came from—it does not prove that the source or workflow was bug-free or uncompromised.

Treat provenance as an additional supply-chain signal, not as a substitute for protected branches, dependency review, staged approval, or incident response.

A release-security decision matrix

Use the cost of a bad publish to choose the control, not the fashion of the tooling.

The central design principle is separation: separate release paths, separate permissions, separate read and write credentials, and add a human gate where the blast radius justifies it.

One warning for existing configurations

npm’s current documentation says trusted-publisher configurations created before May 20, 2026 retain their prior direct-publish behavior. Configurations created before the September 3 multiple-publisher update also keep their existing behavior rather than silently changing permissions.

New configurations created after September 3 are set up with staged publishing available by default, while direct publishing is an explicit choice.

That is a good reason to audit old publishers rather than assuming the newest safer default retroactively changed them.

Conclusion

Multiple trusted publishers remove one of the strongest practical reasons npm maintainers still had for keeping a long-lived write token: one package can now authorize several legitimate CI release paths independently.

Use that flexibility to make workflows narrower, not broader. Give stable, prerelease, staging, and migration paths their own identities. Prefer staged publication when a compromised workflow should not be able to publish immediately. Keep read-only tokens only where private dependency installation still requires them, and revoke old write tokens after OIDC has been proven end to end.

The useful end state is not simply “we use OIDC.” It is:

no unnecessary long-lived publish secret, no catch-all publishing workflow, and no direct path to the registry that is more powerful than it needs to be.

Sources

Checked September 5, 2026:

• GitHub Changelog — Multiple trusted publishing configurations for npm
• npm Docs — Trusted publishing for npm packages
• npm Docs — Staged publishing for npm packages
• npm Docs — Using private packages in a CI/CD workflow
• npm Docs — About access tokens