npm holds all accounts for 72 hours after a recovery code sign in

On 9 September 2026 GitHub announced that npm now places a 72 hour security hold on any account after a successful sign in with a recovery code. Before this, the protection applied only to high impact accounts. The announcement does not reference a specific incident.

What changed

From the GitHub changelog entries:

• After a recovery code sign in, publishing and other security sensitive writes, including creating access tokens, are paused for 72 hours. Signing in, browsing and installing still work.
• The hold lifts automatically. If you are blocked and did not use a recovery code, the changelog says to contact npm Support immediately.
• On 25 June 2026 npm added a related protection for high impact accounts: when such an account changes its email or uses a 2FA recovery code, it becomes read only for 72 hours and an alert goes to the previous email address. Aikido notes npm has not restated the threshold for high impact, but its 2FA policy defined it as packages with over 1 million weekly downloads or 500 dependents.

The stated motivation in the June entry is a takeover pattern: a compromised account changes its email, mints a new token and publishes malicious versions.

Confirmed, reported and unknown

Confirmed by GitHub's changelog: the hold, its length, what it pauses and the scope. Reported by Aikido: the likely threshold and how the June feature relates.

Unknown: how many takeovers this would have stopped, and whether attackers who obtain a recovery code can wait out 72 hours. Nothing in the entries claims otherwise.

What to do now

1. Store npm 2FA recovery codes in a password manager that the whole publishing team does not share. Treat a recovery code as equal to a password.
2. Add the previous email address of publishing accounts to a monitored mailbox, since alerts go there.
3. Plan for the hold. If a maintainer legitimately uses a recovery code, a release will pause for 72 hours.
4. Move releases to trusted publishing with short lived credentials, so a stolen account cannot mint a long lived token.
5. Review who can publish your packages and remove accounts that no longer need to.

How this could have been avoided

Past maintainer takeovers vary, so these controls are tied only to the pattern GitHub names:

• Recovery codes held offline or in a separate vault reduce the chance of one being used by someone else.
• A mailbox on the account that alerts on email and credential changes gives defenders the 72 hours.
• Publishing from CI with OIDC means a takeover of a personal account does not by itself publish.
• Requiring phishing resistant 2FA on publishing accounts makes the first step harder.

Try it yourself

See what to check on a package's provenance with the attestation demo.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GitHub changelog: npm extends recovery-code security holds to all accounts
• GitHub changelog: npm adds preventive account protection for high-impact accounts
• Aikido: npm now freezes high-impact accounts after risky account changes