npm trusted publishing now covers opt-in dist-tags
Small maintainers can remove one more long-lived token, but only for workflows that fit npm’s trusted publishing model.
Short answerUse it if trusted publishing already owns your release path; keep tokens if tag moves stay outside CI.
By JasonPublished Oct 1, 2026Last verified Oct 1, 20265 min read
Small npm package maintainers have had a slightly awkward security gap: trusted publishing could remove long-lived tokens from the publish path, but not from dist-tag changes. That matters because dist-tags are not cosmetic. They decide which version npm users get when they install a package by tag, such as latest, next, or beta. For a solo maintainer or tiny team, those tag moves often happen after a release, during a staged rollout, or when rolling back from a bad version. According to the GitHub Changelog, npm trusted publishing configurations can now be granted an opt-in permission to manage dist-tags through short-lived OIDC credentials. The practical question is not whether OIDC is more modern than a saved token. The decision is whether your release process is ready to make GitHub trusted publishing the authority for tag movement too. If your current setup already uses trusted publishing and only keeps a granular token for npm dist-tags, this update directly targets that leftover token. If your workflow relies on manual npm CLI tag operations outside the trusted publishing configuration, the benefit is narrower and the migration risk is mostly about who, or what, is allowed to move tags.
What changed
According to GitHub Changelog, npm trusted publishing configurations can now receive an opt-in permission called Allow npm dist-tag. When enabled, that configuration can manage npm dist-tags using short-lived OIDC credentials instead of a long-lived access token.
GitHub frames the gap clearly: trusted publishing already covered publishing and staging, but dist-tag operations still required maintainers to keep a granular token if they wanted to promote a version to `latest`, update `next` or `beta`, or adjust tags after a rollback.
Why indie maintainers should care
For a small package, dist-tags often carry more operational weight than they look like they do. A tag update can decide which version regular users install, which prerelease channel gets traffic, or whether a rollback actually reaches people.
The practical upside is credential reduction. If your package had otherwise moved to token-free trusted publishing, this change can remove the remaining token that existed only for tag management. That is a narrower claim than “npm releases are now token-free for everyone,” but it is still useful for maintainers trying to keep CI secrets small.
The safety detail that matters
GitHub says the new permission defaults to off for both new and existing trusted publishing configurations. That means existing configurations do not automatically gain dist-tag power.
The permission is also independent of direct publishing. A configuration used only for staging can still be granted dist-tag management. That is useful for release designs where staging and promotion are separate, but it also means maintainers should review which workflows are allowed to move tags.
One more operational detail: GitHub says a dist-tag operation is authorized if the incoming OIDC token matches any one trusted publishing configuration where the permission is enabled. In plain English, do not enable this on broad or experimental configurations unless those workflows should be able to move npm tags.
Decision frame
Choose GitHub trusted publishing for dist-tags if your release workflow already runs through trusted publishing and the only reason you still keep an npm token is tag movement.
Keep token-based dist-tag management for now if your tag changes are intentionally manual, happen outside the trusted publishing setup, or depend on a process you are not ready to encode in CI.
Use the opt-in setting carefully if you have separate staging, beta, and production workflows. The update supports those shapes, but it puts the burden on maintainers to grant the permission only where tag movement is intended.
Migration checklist
- Identify whether your package still keeps a granular npm access token only for dist-tags.
- Open the package’s trusted publishing settings.
- Enable Allow npm dist-tag only on configurations that should manage tags.
- Check whether staging-only configurations should also be able to move tags.
- Leave unrelated or experimental configurations without the permission.
- After migration, remove the leftover token if it no longer has another release purpose.
Bottom line
This update is most relevant to maintainers already using npm trusted publishing. It closes a specific release-workflow gap without automatically expanding permissions. For everyone else, it is a prompt to review release credentials, not a requirement to change process immediately.
Our read: this is a sensible cleanup for maintainers who already bought into npm trusted publishing, not a blanket reason to redesign every release flow today. The useful part is narrow and concrete: a workflow that previously needed a long-lived granular access token only for dist-tags can now move that capability behind an opt-in trusted publishing configuration. That reduces one persistent credential from the release path, while avoiding a silent permission expansion because GitHub says the setting defaults to off for both new and existing configurations.
The caution is also concrete. Dist-tags are release-control switches. Giving a CI configuration permission to update latest, next, or beta is different from merely uploading a build artifact. Maintainers should enable it only on configurations that are supposed to make those moves, especially because GitHub says an operation is authorized if the incoming OIDC token matches any one configuration with the permission enabled. For small packages, the right move is usually incremental: enable it for the release workflow that already owns publishing or staging, remove the leftover token, and leave manual or experimental workflows out.
Use it if trusted publishing already owns your release path; keep tokens if tag moves stay outside CI.
Based on GitHub Changelog’s announcement, this is a targeted security and workflow cleanup for maintainers already using npm trusted publishing. It does not force a migration, and it should not be enabled broadly without reviewing which workflows should control npm tags.
Maintainers whose tag changes are intentionally manual, whose release workflow is not built around trusted publishing, or who are not ready to decide which CI configurations may move npm tags.
Read next
Follow new articles
Email updates are not live yet, and we are not collecting addresses. To follow new articles, use the RSS feed.