npm Now Allows Multiple Trusted Publishing Configs Per Package — Why That Kills the Last Excuse for Tokens

GitHub announced on 2026-09-03 that an npm package can now have multiple trusted publishing configurations instead of exactly one. For open source maintainers this is a real unblock; for everyone consuming packages it is a quiet supply-chain win.

1. What trusted publishing is, in plain terms

The traditional way to publish to npm is to mint an npm token and paste it into your CI secrets. The problem is blunt: that token is a master key. Leak it and someone else publishes under your name. Several well-known package poisoning incidents started exactly there.

Trusted publishing swaps the long-lived secret for a short-lived proof of identity: at publish time the CI job presents an OIDC token, and npm checks it against pre-registered criteria — this repository, this workflow, this environment. No stored secret means no secret to steal.

2. What actually changed

Change 1: multiple configurations per package.

Each configuration carries its own repository, workflow and environment criteria, and per the announcement, “a publish or stage is authorized if the incoming OIDC token matches any one configuration.” Maintainers can add, list and remove them from package settings.

Small on paper, but it fixes genuinely common setups:

• A package published from both a primary repo and a fork or mirror
• Stable releases from one workflow, canary/nightly builds from another
• Migration periods where an old and a new CI system both need to publish
• Monorepos where different workflows own different packages

Previously any of these forced you back to tokens — trading security away for flexibility. That trade is gone.

Change 2: staged publishing is the default.

Staged publishing is the default for all configurations, and direct publishing requires opt-in per configuration. In other words: land in a review queue by default, publish straight through only as a deliberate exception.

Change 3: no approving while malware scanning runs.

Per GitHub: “the approval button is now disabled while a package is still being scanned and becomes available once the scan completes.” This closes a very human gap — maintainers clicking approve before the scanner finished. Now the button simply is not there yet.

Change 4: visible version history.

Maintainers can view detailed version history on npmjs.com, including approval status and staging information.

3. Who this affects

Open source maintainers: you can finally delete the tokens you kept only because you had more than one publishing path. Two things worth doing at the same time: revoke the old tokens, and leave direct publishing switched off so everything goes through staging.

Companies consuming packages: nothing to do, but the odds of an upstream dependency being poisoned drop slightly. Leaked maintainer CI tokens have been a top attack path in the npm ecosystem for years.

Everyone else writing code: no action.

4. Our take

The headline feature matters less than the shift it represents: it turns the secure path from inconvenient into workable.

Security controls rarely die by being broken. They die by being bypassed — when the safe route blocks a legitimate workflow, people revert to a token, and that token lives for five years. This change removes that excuse.

Combined with staged-by-default and scan-before-approve, npm is clearly steering the publish flow toward “safe by default, fast by exception.” For the JavaScript ecosystem that is worth more than most feature releases.

Source: GitHub Changelog, 2026-09-03, verified 2026-09-07. Follow npm’s own documentation for configuration steps. Our developer-tool plan records live on the GitHub Copilot tool page.