# npm allows multiple trusted-publishing configurations per package > Maintainers can authorize several independent OIDC workflows, keep each staging-only by default, and wait for malware scanning before approval. Canonical URL: https://www.devobs.io/news/news-npm-multiple-trusted-publishers/ By: Lena Fischer Published: 2026-09-06T11:58:54.643Z Updated: 2026-09-06T11:58:54.643Z Event date: 2026-09-03 Section: Security npm made multiple trusted-publishing configurations per package generally available on September 3. A maintainer can now authorize separate OIDC identities for stable, prerelease, or staging workflows without preserving a long-lived token for the extra paths. GitHub's [announcement](https://github.blog/changelog/2026-09-03-multiple-trusted-publishing-configurations-for-npm/) says each configuration independently matches repository, workflow, and environment criteria. ## Several identities can share one package safely Configurations are additive: a publish is authorized when its OIDC token matches any one of them, and evaluation order is not guaranteed. That makes each entry a complete grant rather than a rule that narrows another rule. Maintainers should avoid overlapping criteria that make it unclear which workflow was intended to publish a version. Every trusted configuration can stage by default, while direct publishing must be enabled explicitly. Keeping workflows staging-only preserves the human, two-factor-authenticated promotion step introduced with staged publishing. It also separates compromise of a CI identity from immediate public release. ## Scanning joins the promotion state machine npm now disables approval of a staged package until publish-time malware scanning completes. The versions tab records whether a staged version was approved, rejected, or remains pending. That history can support incident review, but a completed scan is not a guarantee that a package is benign. Inventory current package publishers before adding configurations. Give stable and prerelease workflows distinct environments and branch or tag protections, then test that an unauthorized branch cannot obtain a matching token. Remove superseded grants instead of accumulating them indefinitely. Approvers should compare package contents, source commit, provenance, version, and expected workflow before promotion. Multiple OIDC routes solve a practical automation constraint; they also increase the authorization surface, so each route needs a named owner and periodic review. ## Source references -