An automated npm workflow can prepare a new package version without being allowed to release it. GitHub’s stage-only granular access tokens make that distinction enforceable: automation submits a version with npm stage publish, and a package maintainer reviews and approves the release with two-factor authentication. Direct npm publish attempts using the token are rejected, even when it is configured to bypass 2FA. GitHub’s announcement describes an opt-in change.
npm has split the work of submitting a version from the power to release it. A stored automation credential can start the process; the maintainer must finish it. That separation limits what a stolen credential can do, while leaving other package write permissions intact. Whether the arrangement improves everyday security depends partly on the review work maintainers perform at that boundary.
A narrower credential, with substantial authority left
The token loses one power: publishing a new version directly. It keeps other ways to change a package. npm’s documentation describes two publishing permissions for granular tokens with package and scope write access: Read and write (publish and stage) allows direct publication; Read and write (stage only) requires staging for maintainer review and promotion. An attempt to publish a new version directly with the latter fails with E_STAGE_REQUIRED. npm access-token documentation
The same documentation says stage-only tokens can still move dist-tags and deprecate package versions. A token that cannot release a new version can still change dist-tags and deprecation status. npm explicitly cautions that stage-only is not a general-purpose security boundary and that the credential requires the same care as other tokens.
Steal a stage-only credential, and direct publication of a new package version is still out of reach. An attacker could still misuse its other write permissions. Teams need to protect the credential even after removing its power to publish directly.
Publishing credentials are already a target. Palo Alto Networks’ Unit 42 reports credential-harvesting payloads that target npm tokens and GitHub personal access tokens, and describes stolen credentials being used to infect and republish legitimate packages. Stage-only tokens target that route to unauthorized publication, though Unit 42’s analysis offers no measure of their effectiveness. Unit 42’s npm threat analysis
The registry decides where automation stops
GitHub’s npm roadmap says bypass-2FA granular access tokens will lose the ability to publish versions directly, while token-based automation can continue to run unattended. Its proposed publishing path is automation staging a version followed by approval with 2FA. npm’s publishing roadmap
npm sets the publishing rules; the package maintainer gives the final approval. Under that path, the automation operator’s possession of a token is insufficient to complete a release.
A team can delegate release work to its workflows only as far as the registry allows. Maintainers retain release authority, but must also supply the attention and availability needed to exercise it. An unattended staging job and an unattended release are different operational promises.
Teams have also asked for more Trusted Publishing providers, more flexible permissions and better publishing visibility, according to the roadmap. Those requests matter because the registry’s supported paths determine how much flexibility teams have when adapting their automation. How widely those needs are felt, and what they cost teams, remains unclear.
The strongest objection is the work of approval
The staging job can run unattended. The release still needs a maintainer to review and promote it. The question is whether the added review produces enough value to justify the release coordination it requires.
Earlier npm security changes drew complaints about the work of adapting automation. In a November 2025 discussion, participants criticized token rotation and communication. One commenter warned that recurring rotation requirements could encourage broader credential access or attempts to give CI systems access to authentication factors. GitHub’s announcement in that thread said it had adjusted its timeline in response to feedback. The revised security timeline discussion
The work lands with maintainers. Requiring their approval does not ensure they have the time or information to review a release well. Approval answers who authorized the release. It cannot, by itself, tell users how closely anyone examined the package.
The token’s restriction is clear; the return on maintainers’ time is harder to judge. Without before-and-after incident data and measurements of review work, the net operational result remains an open question: how much security does the added coordination buy?
Human approval is one publishing path
Trusted Publishing is an important alternative in GitHub’s roadmap. It says those workflows can continue using npm publish directly without relying on a stored token. Normal interactive publishing with 2FA is also unaffected. Manual approval of staged versions is therefore one publishing path, rather than a requirement for every npm release. npm’s publishing roadmap
GitGuardian’s security analysis describes Trusted Publishing as using short-lived identity assertions through OpenID Connect, with the registry verifying the claim. Its recommendation is to replace long-lived automation secrets with these exchanges where possible. Which path fits a team still depends on its workflow; GitGuardian’s recommendation offers no comparison of outcomes across the alternatives. GitGuardian’s publishing-security analysis
Stage-only leaves a stored token in the workflow, limits its publishing power and requires maintainer authorization. Trusted Publishing addresses the reliance on that stored credential. Treating them as interchangeable would obscure which dependency each changes.
The rollout language is less settled. The community roadmap describes stage-only tokens as available in preview ahead of a formal general-availability announcement, while the changelog says the permission can now be selected. Teams can select the permission, but its release designation remains unclear across those announcements. GitHub’s announcement, the community roadmap
The test now is what happens at the approval step: can maintainers give staged releases meaningful scrutiny at a sustainable cost? Stage-only tokens establish who must authorize publication. Evidence of fewer unauthorized releases, alongside the time and attention required for approval, would show whether that redistribution of authority delivers the broader security benefit its design makes possible.
