The history of npm publish authentication is mostly a history of long-lived tokens leaking from places they should not have been, and Trusted Publishing is npm's response to that history. The model is straightforward: instead of generating an npm publish token, copying it into a CI secret, and trusting that the secret never leaks, the CI runner authenticates to npm with an OIDC token that the registry exchanges for a short-lived publish credential bound to that specific workflow run. The credential exists for the duration of the publish, the runner cannot exfiltrate anything reusable, and a leak of the OIDC token outside the runner is rejected by npm because the audience and issuer claims do not match.
The headline benefit is that there is no longer a long-lived secret in your repository or in your CI provider that can be stolen and used to publish malicious versions of your package. The headline cost is that you have to wire Trusted Publishing into your workflows correctly, which means making sure the workflow identity is bound tightly enough to be useful and loosely enough that legitimate publishes still work. As of 2026, the rough edges are mostly around fallback paths for environments that cannot use OIDC and around the surface area of what counts as the same workflow when you reorganize your repository.
What is Trusted Publishing actually doing under the hood?
When a CI workflow runs npm publish with Trusted Publishing configured, the npm CLI requests an OIDC token from the CI provider's token endpoint. On GitHub Actions, this is the same id-token: write permission that provenance uses, and the token is a signed JWT whose claims include the repository, the workflow file path, the branch, the run ID, and an audience claim that the CLI sets to npm's registry endpoint. The CLI sends this token to npm's authentication service, which validates the JWT signature against the CI provider's public keys, checks that the issuer is on npm's allowlist, and checks that the workflow identity matches a Trusted Publisher configuration for the target package.
The Trusted Publisher configuration is what binds a package on npm to a specific CI workflow. It is set up through the package settings on npmjs.com, and it specifies the issuer, the repository, the workflow file path, and optionally a branch or environment constraint. A publish from any workflow that does not match the configured identity is rejected at the registry, even if the OIDC token itself is valid for some other purpose. This is the structural difference from token-based publishing: the registry knows which workflow is authorized to publish a given package, and the proof of identity is regenerated for every publish from primitives that cannot be exfiltrated as a reusable secret.
If validation succeeds, npm returns a short-lived publish credential that the CLI uses for the actual publish call. The credential is scoped to the package being published, expires within minutes, and cannot be used to publish other packages or perform other registry operations. The publish proceeds normally from there, and if --provenance is also set, the same OIDC token gets reused for the sigstore attestation flow, which means Trusted Publishing and provenance share the same identity primitive end to end.
How do you actually migrate a package from token-based publishing to Trusted Publishing?
The migration has a few moving parts but each one is mechanical. The first step is to configure Trusted Publishing on the package itself by visiting the package settings on npmjs.com, navigating to the publishing access section, and adding a Trusted Publisher entry that specifies your CI provider, the repository owner and name, the workflow file path, and any branch or environment constraints you want to enforce. The workflow file path is specified relative to the repository root, and it has to match the file that actually runs the publish; if you split your release workflow across multiple files, each one needs its own Trusted Publisher entry.
The second step is to update the workflow itself. The publish job needs id-token: write permission, the actions/setup-node step needs to configure the registry URL, and the publish step needs to call npm publish without an explicit NODE_AUTH_TOKEN. The CLI detects that Trusted Publishing is available and uses the OIDC flow automatically. If you were previously passing NODE_AUTH_TOKEN from a secret, you can leave the secret in place during the cutover and remove it once you have verified that publishes are working through OIDC; the CLI prefers the OIDC flow when both are available.
The third step is to clean up. The long-lived npm token that was previously stored as a GitHub secret should be revoked from your npm account once the new flow is verified, and the secret should be removed from the repository to prevent future workflows from accidentally falling back to it. This is the step that actually closes the attack surface; leaving the old token in place defeats the whole point of the migration. The recommended practice in 2026 is to enforce at the npm account level that the only publish path is Trusted Publishing, which makes any future token leakage immediately useless against the affected packages.
For packages with multiple maintainers, the Trusted Publishing configuration is per-package, and only an account with appropriate package permissions can set it up. Coordinating the cutover across a team requires the same kind of release-coordination that any auth change does, and the failure mode if the configuration is wrong is that the publish fails loudly rather than that it succeeds with the wrong identity, which is the right direction for a failure mode to point.
What does Trusted Publishing not protect against?
The threat model that Trusted Publishing addresses cleanly is theft or leakage of long-lived publish credentials. That covers a wide range of incidents, including PATs accidentally committed to public repositories, secrets exfiltrated from CI logs through poorly written third-party actions, and tokens harvested from compromised developer laptops. After the migration, none of these scenarios produce a usable publish credential because the credential does not exist outside the runner that minted it.
What it does not protect against is compromise of the CI workflow itself. If an attacker can modify the publish workflow to publish a malicious package, the OIDC token will still be issued, the registry will still accept the publish, and the package will still ship with provenance pointing to the workflow run that produced it. This was the structural lesson of the tj-actions/changed-files incident: a Trusted Publishing configuration that binds a package to a workflow gives the workflow significant power, and any change to the workflow's contents or to the actions it depends on can carry that power into the hands of an attacker.
The practical mitigation is to treat the publish workflow as production code, with branch protection on the file path, required reviews on changes to the workflow YAML, and pinning of third-party actions to specific commit SHAs rather than to floating tags. The Trusted Publishing configuration should also specify a branch constraint where possible, so that a publish only succeeds from the protected branch and not from a feature branch that an attacker might be able to push to. None of these protections are unique to Trusted Publishing, but they become more important once the workflow is the only thing standing between the attacker and a successful malicious publish.
The other limit is that Trusted Publishing only works in environments where OIDC is available and where npm has built an integration. GitHub Actions and GitLab CI are well-supported in 2026; self-hosted CI systems, Buildkite agents, and on-premises Jenkins installations either are not supported or require additional plumbing to expose an OIDC issuer that npm trusts. For these environments, the migration path is either to add a thin GitHub Actions or GitLab CI wrapper that does the publish step after the main CI builds the artifact, or to wait for the broader OIDC ecosystem to fill in the gaps.
How does Trusted Publishing interact with provenance and signature verification?
The three features compose cleanly because they share the same OIDC identity primitive. Trusted Publishing uses the OIDC token to authenticate the publisher, provenance uses the same OIDC token to mint a sigstore signing certificate for the in-toto attestation, and signature verification on the consumer side validates both the registry signature and the sigstore attestation against the same workflow identity. A consumer who runs npm audit signatures against a package that uses all three sees a verification result that ties the published tarball to a specific workflow run that was specifically authorized to publish that package.
The combined model is what makes serious supply chain assurance possible for npm in 2026. Trusted Publishing eliminates the steal-the-token attack class, provenance gives downstream consumers a verifiable record of which workflow run produced the artifact, and signature verification ensures that the artifact has not been tampered with between the publisher and the consumer. None of the three alone closes the full loop, but together they leave only the workflow-compromise vector as the remaining structural risk, and that vector is at least visible to careful consumers through provenance metadata.
For maintainers, the recommendation in 2026 is to enable all three at once. The configuration overhead is modest, the migration is reversible until the old tokens are revoked, and the resulting publish workflow is significantly more defensible than the token-based equivalent. Packages that have not made the move are increasingly visible as a risk signal in their own right, and the gap is likely to narrow further as the tooling continues to mature.
How Safeguard Helps
Safeguard tracks Trusted Publishing configuration and OIDC-bound provenance for every npm package in your dependency graph and treats the combined state as a first-class trust signal alongside CVE data and license data. Griffin AI flags packages whose publisher identity changes, whose Trusted Publishing configuration regresses to token-based auth, or whose workflow binding moves to a less-protected branch, so a quiet downgrade in a dependency's supply chain posture surfaces as an event rather than as a silent regression. Reachability analysis tells you which packages with weaker publish hygiene are actually exercised by your application versus which ones are inert, so prioritization for vendor conversations reflects real exposure. TPRM workflows let you require Trusted Publishing for vendor-supplied packages and track the rollout across your dependency tree. Policy gates can require Trusted Publishing and provenance for packages on your critical-dependency list, blocking installs of any version that does not meet the bar.