On 30 September, GitHub and npm removed a small but important obstacle to token-free package publishing. npm trusted publishing configurations can now receive an opt-in permission to manage distribution tags such as latest, next and beta using short-lived OpenID Connect credentials.
The feature will not dominate technology headlines. It should nevertheless prompt an immediate review in organisations that publish JavaScript packages. Until now, teams could use trusted publishing for the release itself, yet still need a long-lived npm access token to promote a staged version, move a prerelease channel or perform a rollback by changing a tag. One residual secret was enough to preserve a material attack path.
The real change is the trust model
Traditional release automation starts with a stored credential. A person creates an npm token, places it in a CI secret store and relies on process controls to keep it valid, scoped and rotated. The workflow presents that bearer token to npm. Anyone who steals it can use it until it expires or is revoked, subject to its permissions.
Trusted publishing reverses the relationship. The package owner pre-authorises a specific workflow identity. During a run, the CI platform obtains a short-lived OIDC identity token containing verifiable claims about the repository and workflow. npm evaluates those claims against the trusted publishing configuration and grants only the permitted operation. There is no standing npm secret for the workflow to exfiltrate.
This distinction matters because modern build systems execute a mixture of first-party scripts, third-party actions and package lifecycle hooks. A secret stored correctly can still be exposed to an incorrectly trusted step. Short-lived, workload-bound identity reduces both the useful lifetime of stolen credentials and the number of places in which credential hygiene must be perfect.
Why dist-tags are a production control
Engineering leaders should resist treating dist-tags as repository housekeeping. For many consumers, installing a package without an explicit version resolves through latest. Moving that pointer can therefore change what enters downstream builds without publishing any new artefact. Tags also support promotion workflows, prerelease channels and rapid rollback to a known version.
That makes tag mutation a distinct production capability. The new permission is deliberately off by default for new and existing trusted publishing configurations. It is also independent of publishing permission, so a staging-only workflow may manage tags without gaining authority to publish a new version. This separation is the most valuable part of the change. It allows release design to express who may create an immutable artefact and who may expose that artefact to consumers.
A better release architecture
For a critical package, split the pipeline into explicit trust domains:
- Build and verify: run tests, static analysis and dependency checks in an environment with no publishing authority.
- Publish or stage: create the versioned package through a tightly scoped trusted publishing configuration. Require protected-branch or environment controls before this job can run.
- Promote: move
next,betaorlatestthrough a separate workflow with the new dist-tag permission. For high-impact packages, attach approval and change-management policy here. - Recover: maintain a tested path for moving a tag back to a previously published version. A rollback procedure that still depends on a maintainer finding a personal token during an incident is not operationally credible.
This structure produces clearer audit evidence than an all-powerful release job. It also limits the blast radius of workflow compromise. A promotion workflow should not need to execute arbitrary build tooling, while a build workflow should not be able to redirect consumers to a different release.
What leaders should ask this week
First, inventory every npm token used by CI, including tokens hidden in organisation-level secrets, legacy release bots and manual rollback instructions. Classify each by operation rather than by team ownership: publish, stage, tag, deprecate or administer.
Second, identify packages where trusted publishing is already enabled but a token remains solely for npm dist-tag. These are the fastest migrations. Enable the permission only on the configuration that performs promotion or rollback, validate the workflow in a low-risk package, then revoke the redundant token. Do not leave the token in place as a convenient fallback, because that preserves the original risk.
Third, review workflow identity as carefully as cloud identity. Pin third-party actions, restrict who can modify workflow files, protect the branches and environments referenced by the trust policy, and ensure that approval controls cannot be bypassed through an unreviewed workflow change. OIDC removes stored credentials; it does not make a weakly governed pipeline trustworthy.
Finally, give platform engineering a measurable objective: reduce standing release credentials. Useful measures include the number of long-lived npm tokens, their maximum age, the proportion of packages using trusted publishing and the proportion with separate publish and promotion authorities. These metrics describe exposure more directly than a generic statement that supply-chain security is a priority.
Small platform changes can enable large risk reductions
The strategic lesson is broader than npm. Security programmes often stall on the last operational exception. Teams adopt short-lived identity for most of a workflow, then retain one durable credential because a necessary administrative action is unsupported. That exception gradually becomes permanent and poorly understood.
npm has now closed one such gap. The appropriate response is not applause for another CI feature. It is to redesign the release path, remove the secret and prove that promotion and recovery still work. The organisations that benefit will be those that convert a platform capability into a smaller, clearer and more defensible authority model.
Source note: GitHub announced the opt-in npm dist-tag permission on 30 September 2026. Implementation guidance is available in the npm trusted publishing documentation.