A release workflow that depends on a long-lived npm token configured to bypass 2FA now has an expiry path. npm is reducing what those tokens can do, beginning with sensitive account operations and later direct publication.

The useful question is not whether the release sounds modern. It is whether the changed default or capability affects the way your project installs, compiles, resolves modules, or runs in production.

Quick answer

Inventory every npm token, remove 2FA-bypass assumptions from account management, and migrate automated releases to trusted publishing with OIDC or to staged publishing with explicit human approval.

# GitHub Actions should request OIDC instead of storing an npm token
permissions:
  id-token: write
  contents: read

what changed

The announced plan removes bypass capability for sensitive account actions in early August 2026. Around January 2027, these tokens are expected to lose direct publishing and be limited to reading private packages or staging a release.

This is a version-specific change. Pin the tool or runtime while migrating so a teammate and CI do not test a different contract by accident.

where teams will notice it

Teams with forgotten release bots may discover the problem only during an urgent patch. The migration also changes incident response because there is no long-lived publish secret to rotate.

A small smoke test is more useful than assuming the changelog covers your architecture. Reproduce the workflow from a clean checkout with the same command production uses.

a safe migration

  1. List organization and automation tokens.
  2. Map each token to its workflow and owner.
  3. Configure a trusted publisher for supported CI.
  4. Test a prerelease package before removing the old token.

Change one resolution or security boundary at a time. That keeps failures attributable and makes rollback straightforward.

the mistake to avoid

Do not delete the old credential before proving the new publisher, package scope, environment protection, and provenance settings work together.

Avoid broad compatibility switches unless they are temporary, documented, and assigned a removal date. A migration that merely hides the warning will return as a harder TypeScript, Node, or npm upgrade later.

how to verify the result

Publish a prerelease from the protected workflow and inspect its provenance. Confirm the repository, workflow identity, commit, and package are the ones you intended.

Record the tool version and verification command in the pull request. That gives reviewers evidence and gives the next upgrade a known baseline.

rollout note

Ship the change in a small pull request that records the old behavior, the new behavior, and the rollback command. For an application, test the production image rather than only the developer machine. For a library, install the packed tarball in a tiny consumer project. Keep the previous lockfile or compiler configuration available until CI, deployment, and one real workflow have all passed.

That evidence makes the upgrade reviewable. It also prevents a later failure from being blamed vaguely on the entire major release when one setting or experimental flag was responsible.

official reference

Check the linked documentation again before upgrading production. Current-release features and announced security timelines can change in later patch releases.