npm has added an optional permission to trusted publishing: the ability to move a dist-tag such as latest or next using short-lived OIDC credentials, instead of a classic access token. The announcement, published on GitHub’s blog on September 30, 2026, closes a remaining gap for projects that had already switched to a token-free publishing flow.
The gap that remained in trusted publishing
Trusted publishing has for months allowed publishing an npm package from a CI system, such as GitHub Actions, relying on OIDC credentials issued on the fly rather than a token stored as a secret. But promoting an already published version to a dist-tag, a routine operation such as moving a version from beta to latest, stayed outside that mechanism’s scope. Maintainers who had eliminated their long-lived publishing tokens still had to keep one around for that single task.
What the new permission allows
Every npm trusted publishing configuration now ships with an “Allow npm dist-tag” option, disabled by default. Once enabled for a given package, the OIDC credentials issued during a deployment can publish a version, manage its dist-tags, or both, independently of each other: a configuration scoped to staging only could, for instance, be granted dist-tag management rights alone.
How to enable it
Activation happens in the trusted publisher configuration on npmjs.com, and is then reflected in the CI workflow, which needs no additional token:
permissions:
id-token: write
contents: read
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
registry-url: https://registry.npmjs.org
- run: npm publish --provenance
- run: npm dist-tag add [email protected] latest
| Operation | Before | After |
|---|---|---|
| Publishing a version | OIDC (trusted publishing) | OIDC (trusted publishing) |
| Promoting a dist-tag | Classic access token | OIDC, on explicit authorization |
| Long-lived token to store | Yes, for dist-tags | None |
Scope and limits
The permission stays independent from the direct publishing right: a configuration scoped to staging could be granted dist-tag management only, never the ability to publish a new version. Token-based flows also keep working unchanged for teams that have not migrated yet. A reasonable compatibility choice, but one that leaves closing this gap entirely up to maintainers: nothing pushes them to turn it on.
Every npm trusted publishing configuration now ships with an “Allow npm dist-tag” permission, disabled by default, covering version-promotion operations previously reserved for classic tokens.
What this changes for maintainers
For maintainers of widely used packages, the attack surface shrinks a little further: a stolen or poorly revoked publishing token is a classic supply-chain compromise scenario, documented repeatedly over the past few years across the JavaScript ecosystem. Teams tracking how JavaScript package managers are evolving will recognize a principle already applied on the web-hosting side, where reducing the number of stored secrets remains one of the simplest hardening levers available.
Key takeaways
npm extends trusted publishing to dist-tag management via OIDC, an opt-in option that removes the last long-lived token needed in an otherwise token-free publishing flow.
This is the kind of improvement that will never make a general news feed’s front page, yet matters more, over time, than many flashier announcements. A publishing token left lying around in a repository’s secrets is a classic finding in security audits, and the fact that it still has to be switched on manually rather than being the default shows that supply-chain security moves at the pace of adoption, not at the pace of available technology. — Simon Janvier
Further reading: the official announcement on GitHub’s blog, “Opt-in dist-tag permissions for npm trusted publishing”.
