npm Trusted Publishing Is Expiring: Check Your CI/CD Setup

npm package publishing has changed significantly over the last few years. Many teams have moved away from long-lived npm access tokens and started using trusted publishing through CI/CD platforms.

Trusted publishing is useful because it allows a supported CI/CD environment to publish an npm package without storing a long-lived publishing token in repository secrets.

However, npm is also changing how older trusted publishing configurations are handled. That means package maintainers should review their CI/CD pipelines instead of assuming that an existing setup will continue working forever.

If your project automatically publishes packages from GitHub Actions or another supported CI/CD environment, now is a good time to check how authentication is configured.

This article explains what npm trusted publishing is, why its lifecycle matters, what developers should check in their pipelines, and how to build a safer package publishing workflow.

What Is npm Trusted Publishing?

Trusted publishing allows an npm package to be published from a trusted CI/CD environment without requiring a traditional long-lived npm access token to be stored as a repository secret.

A traditional workflow often looks like this:

Developer
   |
   v
Git repository
   |
   v
CI/CD
   |
   v
NPM_TOKEN
   |
   v
npm registry

The publishing token is stored somewhere in the CI/CD system and is provided to npm during the publishing step.

With trusted publishing, the authentication model is different:

Developer
   |
   v
Git repository
   |
   v
Trusted CI/CD workflow
   |
   v
Short-lived identity
   |
   v
npm registry

The important difference is that the workflow does not need to depend on a permanent publishing token.

This reduces the risk associated with accidentally exposing a long-lived credential.

Why Long-Lived npm Tokens Are a Security Risk

Consider a CI/CD configuration like this:

- name: Publish package
  run: npm publish
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

The actual token is hidden from the workflow file, which is better than hardcoding it.

However, the token still exists as a long-lived credential.

If an attacker gains access to that credential, they may be able to publish packages under the associated account or organization, depending on the token's permissions.

There are several possible ways credentials can be exposed:

A compromised CI/CD environment
Incorrect repository permissions
Malicious workflow changes
Accidental secret disclosure
Developer machines
Logs or debugging output
Third-party CI/CD integrations

Trusted publishing attempts to reduce this dependency by establishing trust between npm and the publishing workflow.

What Does "Trusted Publishing Is Expiring" Mean?

The important point is that developers should not interpret the change as "npm publishing is going away."

It means that specific trusted-publishing configurations or authentication mechanisms may have a lifecycle and may need to be updated.

This matters because CI/CD pipelines often run without human interaction.

A developer may create a publishing workflow once and forget about it.

Months later, the project may still be relying on that workflow:

Git tag
   |
   v
CI/CD workflow
   |
   v
npm publish

If the authentication configuration becomes invalid, the build may continue to compile and test successfully but fail at the final publishing step.

That can be particularly disruptive when publishing is part of a release process.

How an npm Publishing Pipeline Usually Works

A typical package release workflow looks like this:

name: Release Package

on:
  push:
    tags:
      - "v*"

jobs:
  publish:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22
          registry-url: https://registry.npmjs.org

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

      - name: Publish
        run: npm publish

The final authentication configuration determines whether the last step can actually publish the package.

This is where maintainers should pay attention.

Check Your package.json

Start by inspecting the package metadata.

For example:

{
  "name": "example-library",
  "version": "1.4.0",
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "scripts": {
    "build": "tsc",
    "test": "vitest run"
  }
}

Make sure the package contains the expected metadata.

You should also verify:

Package name
Version
Entry points
Type declarations
Build output
Published files
Package visibility
Release scripts

Authentication problems can sometimes be confused with package configuration problems, so keeping these areas clear makes troubleshooting easier.

Check Your GitHub Actions Workflow

If you publish through GitHub Actions, inspect your workflow files.

Look under:

.github/workflows/

Search for:

npm publish

Also search for:

NODE_AUTH_TOKEN
NPM_TOKEN
npmrc
registry.npmjs.org

For example:

- name: Publish package
  run: npm publish
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

If you find this pattern, the workflow is using a token-based authentication approach.

That does not automatically mean it is wrong, but it is something that should be reviewed.

Check Whether Your Workflow Uses Trusted Publishing

A trusted publishing workflow generally depends on the identity of the CI/CD workflow rather than a permanently stored npm token.

For GitHub Actions, this also means workflow permissions matter.

A workflow may need appropriate permissions for its identity:

permissions:
  contents: read
  id-token: write

The exact configuration should match npm's currently supported trusted publishing requirements.

The important concept is that the workflow needs permission to obtain an identity assertion that npm can verify.

Why id-token Permission Matters

OpenID Connect, commonly called OIDC, allows a CI/CD platform to obtain a short-lived identity token.

A simplified flow looks like this:

GitHub Actions
      |
      | Request identity token
      v
GitHub OIDC
      |
      | Signed identity
      v
npm Registry
      |
      | Verify trusted workflow
      v
Package Publishing

The identity token is not intended to function like a permanent npm password.

It represents the CI/CD workload that is attempting to publish the package.

This is one of the key security advantages of workload identity.

Compare Token-Based Publishing and Trusted Publishing

Area	npm Token	Trusted Publishing
Long-lived credential	Usually yes	No long-lived npm publishing token required
CI/CD secret storage	Required	Reduced dependency
Credential rotation	Required	Reduced
OIDC identity	Not required	Used
Initial setup	Simple	Requires configuration
Security model	Credential-based	Workload identity-based
Pipeline maintenance	Token management	Trust configuration
Best fit	Legacy or supported token workflows	Modern CI/CD publishing

The exact capabilities depend on the CI/CD provider and npm's supported configuration.

Why Existing Pipelines Can Suddenly Break

CI/CD workflows are often treated as infrastructure, but they are still software.

They depend on external systems such as:

npm
GitHub Actions
Node.js
npm CLI
Authentication services
Package registries

If one part changes its authentication requirements, an old workflow may stop working.

For example:

Source code
    |
    v
Build succeeds
    |
    v
Tests succeed
    |
    v
Package created
    |
    v
Authentication fails
    |
    v
npm publish fails

This is why package publishing should be tested before an important release.

How to Test Your Publishing Workflow Safely

Do not wait for a production release to discover that authentication has expired or changed.

A safer approach is to test the workflow using a controlled package or release process.

Before testing, verify:

The workflow uses the intended Node.js version.
The npm CLI is available.
The package builds correctly.
Tests pass.
Authentication is configured correctly.
The workflow has the required permissions.
The package version is correct.
The publishing environment is the intended one.

You should avoid testing by repeatedly publishing versions to a production package unless that is part of your release process.

A Better CI/CD Structure

A production publishing pipeline should separate validation from publishing.

For example:

name: Package Release

on:
  push:
    tags:
      - "v*"

permissions:
  contents: read
  id-token: write

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

      - name: Check package
        run: npm pack --dry-run

The publishing stage can then be protected separately.

This separation is useful because a failed test should never reach the publishing step.

Do Not Put npm Tokens in Source Code

This should never appear in a repository:

const npmToken = "secret-token-value";

It is also a bad idea to put the token into a committed configuration file:

_authToken=secret-token-value

Even if the repository is private, credentials should not be treated as ordinary source configuration.

If an npm token has already been committed, rotate or revoke it and then clean up the repository appropriately.

Common Mistakes

Keeping an Old Publishing Token Forever

A token that has worked for years can become a security liability.

Review old credentials and remove ones that are no longer required.

Updating the Workflow but Not Its Permissions

OIDC-based workflows depend on workflow permissions.

A missing permission can cause authentication to fail even when the rest of the pipeline is correct.

Testing Only the Build

A successful build does not mean that the package can be published.

Publishing authentication should be tested separately.

Assuming Secrets and OIDC Are the Same

A repository secret and an OIDC identity token represent different authentication models.

Do not blindly copy a token-based workflow and expect it to become trusted publishing.

Forgetting Organization-Level Controls

Organizations may have additional policies around Actions, environments, permissions, and publishing.

The repository workflow should be reviewed together with those controls.

Troubleshooting npm Publishing Failures

If a package release suddenly starts failing, check the error stage first.

Build Failure

Run:

npm ci
npm test
npm run build

Fix application or package problems before troubleshooting authentication.

Authentication Failure

Check:

Workflow permissions
npm trusted publishing configuration
Package ownership
Repository identity
CI/CD provider
npm CLI version
Publishing environment

Registry Configuration Failure

Check:

npm config get registry

The registry should point to the intended npm registry.

You can also inspect the effective configuration without exposing credentials.

Package Permission Failure

A successful authentication does not necessarily mean the workflow has permission to publish a specific package.

Verify package ownership and organization permissions.

Best Practices for npm CI/CD Publishing

Use Workload Identity Where Supported

When trusted publishing is available and appropriate, it reduces the need for long-lived publishing credentials.

Keep Publishing Workflows Small

A publishing workflow should be easy to understand.

Avoid unnecessary scripts and third-party actions between the build and publishing stages.

Pin Important Dependencies

For security-sensitive workflows, review the Actions and tooling used by the pipeline.

A publishing workflow is itself part of your software supply chain.

Protect Release Triggers

If publishing happens when a Git tag is pushed, protect who can create or modify release tags.

Review Workflow Changes

Changes to publishing workflows should receive appropriate code review.

A workflow file can have access to sensitive permissions, so treat it like production infrastructure.

Monitor Failed Releases

A failed publishing job should produce enough diagnostic information to identify whether the problem is:

Build
Test
Package
Authentication
Permission
Registry
Configuration

Do not print credentials while troubleshooting.

Advantages

Trusted publishing has several important benefits.

Reduced Long-Lived Credentials

There is less dependency on permanent npm publishing tokens.

Better CI/CD Security

The publishing identity can be tied to the workload and workflow instead of a reusable secret.

Lower Credential Management Overhead

Teams have fewer publishing tokens to create, store, rotate, and revoke.

Better Supply Chain Security

A controlled publishing identity makes it easier to reason about which workflow is authorized to release a package.

Disadvantages

Trusted publishing is not automatically simpler in every environment.

Initial Configuration Can Be More Complex

Teams need to understand the relationship between npm, the CI/CD provider, and workload identity.

Provider Support Matters

The available functionality depends on the CI/CD platform and the authentication mechanisms supported by npm.

Existing Pipelines May Need Changes

Older token-based workflows may need to be reviewed or migrated.

Permissions Still Matter

Trusted publishing does not remove the need for secure repository and workflow permissions.

An attacker who can modify the trusted workflow may potentially gain the same publishing capability as the legitimate workflow.

Production Checklist

Before your next npm package release, check the following:

The publishing workflow is still supported.
The npm CLI version is appropriate.
Trusted publishing configuration is current where applicable.
Old npm tokens have been reviewed.
Workflow permissions are correct.
OIDC permissions are configured when required.
Package ownership is correct.
Build and tests run before publishing.
Release tags are protected.
Publishing workflow changes are reviewed.
No credentials are stored in source code.
Failed publishing jobs are monitored.
A recovery process exists if a bad package is released.

Summary

npm publishing is becoming more closely connected to modern CI/CD identity and supply chain security practices. Trusted publishing reduces the need to keep long-lived npm publishing tokens inside CI/CD systems, but it also means that package maintainers need to pay attention to changes in authentication requirements.

If your project automatically publishes packages, do not wait until the next release fails. Review the workflow, check its permissions, inspect the authentication method, and verify that the package can still be published using the intended CI/CD identity.

The safest npm publishing workflow is not simply one that succeeds. It should also clearly define who can publish, from where publishing is allowed, how the workflow authenticates, and what checks must pass before a release reaches consumers.

Regularly reviewing these controls helps prevent authentication surprises and reduces the risk of a compromised publishing credential becoming a software supply chain problem.