npm Extends 72-Hour Recovery-Code Security Hold to All Accounts

What shipped

npm now places a 72-hour security hold on any account that signs in with a recovery code — not just the high-impact accounts the policy covered before. Shipped September 9, 2026, no opt-in, no setting to disable.

What changed

During the 72-hour window, publishing and security-sensitive writes are paused — that includes creating new access tokens, which is the move an attacker actually needs to automate a supply-chain attack. You can still sign in, browse, and install packages. The hold expires automatically; no support ticket, no manual unlock.

The asymmetry matters: installs keep flowing, so consumers see zero disruption while a compromised publish path is frozen. The cost lands entirely on the account holder — a maintainer who legitimately lost their 2FA device and used a recovery code is now locked out of npm publish for three days.

Why a builder cares

Check your recovery story before you need it. If a release is scheduled and you burn a recovery code that day, your publish is dead for 72 hours — with no manual override. Two mitigations worth setting up now: a current 2FA device (so recovery is never the path), and a CI token issued before any recovery event, since token creation is also frozen during the hold.

Zoom out and this is the third npm/registry security tightening in about a week on this blog alone: multiple trusted-publishing configurations for npm on September 3, and GitHub's ruleset blocking PRs with exposed secrets on September 9. npm is quietly hardening the entire account-to-publish pipeline. The tradeoff they've made is explicit: maintainers eat a 3-day freeze so attackers get a 3-day window that expires uselessly. Given how recent account-takeover publish attacks have been, that's the right side of the trade — but it means "emergency publish" and "recovery code" can no longer coexist in the same 72 hours.