Protect npm publishing with account 2FA and a scoped release path
Secure the maintainer account, review package publishing access and use supported trusted publishing where appropriate.
In brief
Protecting npm packages involves both the maintainer account and the mechanism that publishes releases. Account 2FA cannot compensate for a broad reusable token exposed in a workflow.
Reviewing both paths reduces the chance that an account or automation compromise becomes a malicious release.
Protect the human maintainer
Use npm’s supported web setup, including security-key authentication where available. Keep a tested recovery route and remove accounts that no longer need maintainer access. Protect the associated email, since account recovery is part of the release boundary.
Restrict the automated publisher
Where npm supports your CI provider, configure its trusted-publisher identity exactly and follow the provider’s OIDC requirements. Restrict who can change the release workflow. If using a granular token, limit packages, permissions and lifetime; a build installing dependencies usually does not need publish permission.
Test a legitimate release route
Verify the account, intended package and workflow before release. Inspect package contents and provenance where applicable. Do not solve a failed publish by globally disabling 2FA or copying a maintainer’s token into a ticket. Investigate whether the failure is identity, permissions or the package’s policy.
Before you act
npm authentication rules evolve. Use the current account and publishing settings; do not follow an old tutorial that asks you to create retired classic tokens.
What to do next
- Enable supported 2FA from npm account security and preserve recovery information.
- Inspect the package’s Settings → Publishing access and its maintainers.
- For supported CI, configure trusted publishing with the exact repository/workflow identity, or a narrowly scoped current token when required.
