How to rotate npm access tokens

Create a new granular access token with the same packages, scopes, organizations, permission and IP ranges as the old one, give it to your CI and build machines, confirm that installs or publishes work, then revoke the old token. An npm account can hold up to 1000 granular tokens, so the two overlap for as long as you need (npm docs). One thing differs from most providers: revocation isn't always instant. npm warns that in some cases it can take up to an hour before a revoked token stops working (revoking tokens).

Crunu doesn't create or revoke npm tokens and doesn't talk to the registry. It shows which npm values a departing person received, stores the replacement as a new environment version, and hands it to npm at run time.

npm tokens after the 2025 changes

If your notes about npm tokens are older than late 2025, they are out of date:

• Classic tokens are gone. npm permanently revoked every existing classic token on December 9, 2025 (GitHub Changelog). Only granular access tokens remain.
• Local publishing uses sessions. npm login now returns a session token that expires after two hours.
• Write tokens are short-lived. New write-enabled granular tokens default to seven days and can't exceed 90 (GitHub Changelog).
• Direct publishing with a token is ending. npm says publishing new package versions directly with a granular token will be removed in January 2027, and since August 2026 tokens that bypass two-factor authentication can't perform account identity or governance actions. For CI/CD, npm points to trusted publishing, or to a read-and-write token limited to staging releases.

So a reissue of a publishing token is often the moment to stop using one at all.

Settings to copy from the old token

A granular token can cover up to 50 organizations and up to 50 packages, scopes or a mix of both. Access is read-only or read and write, and write access to packages is either publish-and-stage or stage-only. Access to an organization doesn't let the token publish its packages, a token never has more permission than its user, and it can be limited to IP ranges in CIDR notation. The full token appears only once; afterwards npm shows only its first and last four characters.

Reissue without downtime

npm token create --name=web-app-ci --expires=30 --scopes=@kiteline \
  --packages-and-scopes-permission=read-only --cidr=198.51.100.0/24
crunu run --env web-app/staging -- npm ci
npm token list --json
npm token revoke TOKEN_ID

npm token revoke takes the full token or an ID long enough to be unique. It doesn't accept the shortened token printed by the normal npm token list output, which is why the list above uses --json (npm-token). The .npmrc substitution rule is described in the npmrc reference.

When to reissue an npm token

• A departure. Their own tokens belong to their npm account, and a session from npm login on their laptop expires within two hours by itself. What you reissue are the tokens they could read: the CI token for private packages, a publishing token, a bot account's token. In Crunu, removing the person yields a reissue checklist of those values by name.
• A leak. Revoke immediately and assume the token may work for up to another hour. Check the versions of your packages published in that window.
• Expiry. With a 90-day ceiling for write access, reissuing publishing tokens is routine whether anyone leaves or not, and the steps above are the routine.

What to rotate when a developer leaves covers the order of work for a whole departure, and the offboarding checklist builds the list for your stack. The registry side, creating and revoking, is always done with npm; Crunu keeps the new value and the record of when it changed.