ReleaseOrigin

G Current decision guide

Will your npm release path survive the targeted January 2027 token change?

Evidence checked September 4, 2026

The change in one sentence

GitHub and npm say bypass-2FA granular access tokens are expected to lose direct-publishing ability around January 2027. They recommend moving automated releases to Trusted Publishing through OIDC or to staged publishing with a human 2FA approval step.

“Around January 2027” is a stated target, not a guaranteed enforcement date. Recheck the official notice before changing a production release.

Read the GitHub/npm notice ↗

Four honest outcomes

  1. Direct OIDC. A supported hosted CI path can exchange its short-lived identity for npm publishing authorization. The package owner configures the trust relationship.
  2. Staged publishing. CI stages the package, then an authorized maintainer reviews and approves it with 2FA before it becomes public.
  3. Verification-only. The visible path already appears compatible, but the owner still needs a dated settings and release check.
  4. No-fit. The public path is missing, too broad, private, or depends on an unsupported environment. A safe handoff should stop before promising a patch.

Choose the path

GitHub-hosted ActionsEvaluate direct OIDC first; staged publishing remains an owner-approved alternative.
GitLab.com shared runnerEvaluate the documented GitLab OIDC route and exact npm audience.
CircleCI cloudEvaluate Trusted Publishing, but do not use missing provenance metadata as a migration verdict.
Self-hosted or other CIDo not assume direct OIDC support. Evaluate staged publishing or stop for owner review.
Manual local publishKeep interactive 2FA in the decision; do not force an automated path that the team does not want.

Check npm’s current Trusted Publishing providers and prerequisites ↗

Evidence to collect before editing

  • The exact npm package and its package-declared public repository.
  • The production release workflow, trigger, runner, Node/npm versions, and actual publish command.
  • Only the names of token environment variables—not token values.
  • Whether a human approval step is required or acceptable.
  • The owner who can review the patch and configure npm’s trusted-publisher settings.

Attestation metadata can help connect a release to source and build information. Its presence is not proof that code is safe, and its absence does not prove that a release is broken, insecure, or using a token.

What remains owner-only

Only an authorized maintainer should configure npm account or package settings, remove a token, merge the workflow change, trigger the release, approve a staged package, or publish. Never paste a token, password, private key, or private-repository content into a public checker or inquiry form.

Read npm’s direct and staged publishing overview ↗

Want the last mile handled?

ReleaseOrigin’s $149 founding Release-Path Rescue turns one visible, bounded path into a dated decision, a PR-ready patch when compatible, exact owner-only settings, static checks, a rehearsal and retry sequence, post-release verification, and rollback notes. Delivery targets 24 hours after fit, public inputs, and payment are confirmed.

Request a fit review