npm now freezes publishing for 72 hours after any recovery-code sign-in, on every account

npm extended a 72-hour publishing freeze to every account that signs in with a recovery code, GitHub said in a changelog post on September 9. The hold used to apply only to high-impact accounts, meaning maintainers of widely used packages. It now covers everyone with an npm login.

What the hold does

For 72 hours after a successful recovery-code sign-in, npm pauses publishing and other security-sensitive writes, including creating access tokens. The account owner can still sign in, browse packages, and install them; the block sits on writes that could push code out to the world. The hold expires automatically, so there is nothing to file with npm support to lift it.

Why the scope changed

Recovery codes are the fallback path when a maintainer loses their normal second factor. They exist so an account is not locked out forever. The same property that makes them useful in a recovery makes them the softest point of an account takeover, because an attacker who obtains them can log in without touching the phone or hardware key that backs the account. Slowing publishing for three days after any recovery-code login is a way of buying time for a real owner to notice a stolen sign-in before a malicious release goes public.

GitHub frames the change as "further slowing account-takeover attempts and reducing the risk of malicious publishing from a compromised recovery code". That shape is the one npm has been hit with all summer: an attacker gets into a maintainer account, publishes a malicious version, and downstream teams pull it before anyone knows the login was stolen. A three-day publishing pause on a login that a real owner would use only occasionally forces the attacker's window into the same alerting timeline as the account owner's inbox.

What it means for a maintainer with one account

Any solo maintainer who has ever leaned on a recovery code because a laptop died, a phone was reset, or an authenticator app was migrated will now see a three-day publishing freeze the next time they use that fallback. If a critical patch has to ship inside that window, the account can sign in and read, but not publish. Support has no lever to shorten the hold.

The practical adjustment is small but real: keep a working second factor on the account, so recovery codes stay a rare fallback. And if a patch is time-sensitive, do the second-factor swap early, so the fallback path is not the one you reach for while a fix is waiting in a branch.

npm's guidance for the reverse case is worth naming: if you were blocked from publishing and did not use a recovery code, that means the hold is on your account without your action, and you should contact npm support right away, since the 72-hour timer will not lift it any faster.

Source

GitHub changelog: npm extends recovery-code security holds to all accounts