npm Allows 10 Trusted Publishers—but Every OIDC Path Can Authorize a Release

On September 3, 2026, GitHub made multiple trusted-publishing configurations for npm generally available. The release announcement says the configurations are independent and additive: an OIDC token that matches any one entry can authorize the action that entry permits.

npm packages can now have as many as 10 trusted publishers, allowing stable, prerelease and staging automation to use separate identities. The npm configuration documentation confirms the limit and says configurations created after September 3 allow staged publishing by default, while direct publishing must be enabled separately.

Every configuration is a separate authorization path

The important security property is additive authorization. npm does not evaluate several publisher entries as layers of one policy: the entries do not restrict one another, and their evaluation order is not guaranteed. A narrowly scoped staging configuration therefore cannot neutralize an older entry that still permits direct publishing.

Each entry should be reviewed as though it were the only one that might match. Its repository or project, workflow or pipeline identity, optional environment restriction and allowed action together define what that release path can do.

The title’s consequence has one necessary boundary: a stage-only match may submit a package to the staging queue, but it cannot make the version public directly. An entry with direct-publish permission can authorize npm publish; an entry without it is limited to npm stage publish.

Map stable, prerelease and staging workflows separately

A practical least-privilege design gives each materially different release workflow its own publisher record. The following matrix is an editorial recommendation rather than an npm requirement:

• Stable releases: bind the production repository, the dedicated stable-release workflow and a protected production environment. Use stage-only access unless unattended direct publication is an explicit operational requirement.
• Prereleases: bind the beta or release-candidate workflow and its own environment. Keep this path stage-only so a compromised prerelease job cannot immediately place a version on the public registry.
• Staging and validation: bind only the workflow that creates artifacts for review and its non-production environment. Allow npm stage publish, not direct publication.

This separation makes the permission attached to each workflow visible. It also avoids a shared, broadly authorized configuration whose compromise would expose every release channel.

Provider fields differ, but the review question does not

GitHub Actions configurations identify an organization or user, repository and workflow filename, with an optional environment. GitLab CI/CD uses a namespace, project and top-level CI file, while CircleCI uses organization, project and pipeline-definition identifiers, a VCS origin and optional context restrictions. The supported environments are GitHub-hosted Actions runners, GitLab.com shared runners and CircleCI cloud; self-hosted runners are not currently supported.

Ten entries are capacity, not a target. Record the package, provider, repository or project, workflow identity, environment, allowed action and operational owner for every active configuration. Do not reserve slots by creating speculative authorization paths.

Existing connections cannot be edited in place: changing their fixed provider fields requires deleting the connection and creating another. That makes an inventory especially useful before production settings are changed, because a replacement briefly alters which identities can publish or stage the package.

Stage-only access keeps approval outside CI

Staged publishing places a human decision between a successful CI job and public availability. A maintainer must approve the staged version with two-factor authentication, and the September release keeps the approval control unavailable until publish-time malware scanning finishes. An independent September 4 developer brief also described the release as generally available and highlighted the staging-first permission model and malware-scan gate.

That boundary is appropriate for prerelease and validation workflows and for stable releases that do not require fully unattended publication. Direct publishing should be an exception attached only to the narrowly identified production configuration that needs it, rather than to a publisher shared across several jobs.

OIDC authentication covers npm publish and npm stage publish. Listing, viewing, approving or rejecting staged packages requires interactive authentication through the CLI or npmjs.com, preserving proof of maintainer presence for the decision that makes a staged version public.

Remove the token path after OIDC migration

Multiple publisher entries remove the earlier pressure to keep a long-lived write token for additional workflows, but they do not automatically disable traditional authentication. If a write-capable token remains usable, it provides another publishing path outside the repository, workflow and environment checks encoded in the OIDC configurations.

1. Inventory every workflow that can produce a stable, prerelease or staged version.
2. Create one narrowly matched publisher for each necessary path and leave it stage-only unless direct publishing is required.
3. Confirm that each intended workflow can perform its permitted action and that unrelated workflows fail to match.
4. Review older configurations for retained direct-publish permission.
5. Require two-factor authentication and disallow traditional tokens in the package’s publishing settings, then revoke obsolete automation credentials.

A read-only token may still be needed to install private dependencies; that does not justify retaining a write-capable publishing credential. The current release supports up to 10 additive configurations across the three hosted CI services, with staged publishing as the default for newly created entries. The remaining decision is local: which precisely identified production workflow, if any, genuinely needs to bypass the staged approval queue.

Also read:

• An AI Gateway Can Cap Costs—but Only if Every Request Goes Through It
• PixVerse Still Allows Seven Keyframes—but V6 Changes the Workflow
• IoMT Is Delivering Care Now—but Every New Connection Expands the Risk