npm has extended its recovery-code security hold to all accounts. After a successful recovery-code login, an account enters a 72-hour period during which package publishing and several sensitive account-management operations are unavailable.
The change is designed to slow account-takeover attempts involving a compromised recovery code and reduce the risk of malicious publishing. For maintainers, the operational impact is significant: a recovery-code login can interrupt releases, package administration, and organization management for up to three days, even though the account remains usable for many routine activities.
What changed for npm accounts
The hold applies when a user with two-factor access enabled uses a recovery code to sign in. npm says the policy now covers all accounts, extending protection that previously applied only to high-impact accounts. The hold begins after the recovery-code login and expires automatically 72 hours later.
There is no documented manual restoration step or support request required to end the hold. It cannot be lifted early, and using another recovery code while the hold is active does not extend the existing period.
According to npm’s account recovery documentation, the restriction is selective rather than a complete account lockout.
Operations blocked during the hold
During the 72-hour period, npm blocks actions that could materially change packages, credentials, account access, or organizational control. The documented restrictions include:
- Publishing and unpublishing packages
- Creating access tokens
- Changing package settings or package maintainers
- Changing organization or team membership
- Changing billing information or account settings
- Changing existing two-factor authentication methods
These restrictions mean that the hold can affect more than an individual release. A maintainer may be unable to unpublish a package, change who administers it, adjust organization membership, or create credentials for a new automation workflow until the period ends.
What remains available
npm continues to allow several ordinary account and package-consumption activities during the hold. Users can still log in, browse and view packages, download and install packages, and change their password. They can also add a new two-factor authentication method.
That distinction matters for teams responding to an account-recovery event. Developers can continue consuming dependencies, but the account may not be able to perform release or administration tasks. The hold therefore creates a publishing and account-management pause rather than a total loss of access to the npm registry.
Why release automation teams should care
Many release processes authenticate to npm through credentials used by command-line or continuous-integration environments. npm’s access-token documentation describes tokens as a way to authenticate API and CLI operations, including installation and publishing, and notes their use in CI environments.
However, npm’s supplied recovery documentation explicitly says that creating new access tokens is blocked during the hold. It does not establish whether an access token that was issued before the hold remains usable. Teams should not assume that an existing token bypasses the restriction, nor should they assume that it is definitely disabled; the behavior is undocumented in the cited material.
The same caution applies to OIDC-based trusted publishing. npm documents trusted publishing as an authentication method for CI/CD workflows that supports npm publish and npm stage publish. The available documentation does not say whether an active recovery hold blocks trusted publishing. As a result, maintainers should treat the interaction between the hold and OIDC publishing as an open operational question rather than relying on it as a documented workaround.
What maintainers and administrators should do
- Account for a possible 72-hour release pause. If a recovery code is used to regain access, plan for publishing and unpublishing to remain unavailable for the full hold period.
- Review recovery procedures. Identify who may use recovery codes and how the team will handle releases, package administration, and organization changes during the resulting restriction.
- Check workflows that create credentials. Since access-token creation is explicitly blocked, avoid scheduling a credential-creation task that depends on access to the affected account during the hold.
- Do not assume an authentication path bypasses the hold. The supplied documentation does not confirm how already-issued tokens or OIDC trusted publishing behave during the restriction.
- Contact npm Support if the block is unexpected. npm instructs users who did not use a recovery code but encounter the restriction to contact npm Support immediately, because the account may have been compromised.
Teams should also ensure that release planning distinguishes package consumption from package administration. Installing dependencies may continue normally, while publishing a release, changing maintainers, or updating organization membership may have to wait until the hold expires.
Important availability details
The policy is already described as applying to all npm accounts. It is triggered by using a recovery code to log in and lasts 72 hours after the hold begins. npm does not document a more precise server-side timestamp boundary in the supplied materials, so teams should avoid assuming a particular clock interpretation beyond the stated duration.
The documentation also does not provide support response times or an escalation commitment. If publishing is blocked without a recovery-code login, contacting Support is the documented next step, but the available sources do not promise how quickly the issue will be investigated.
For account security, the change preserves access to the account and package registry while temporarily limiting actions that could alter packages, credentials, or administrative control. Its practical effect is most important for maintainers with time-sensitive releases and teams whose recovery procedures depend on immediate publishing or account changes.
