Every npm install your CI runs pulls code written by people you have never met. (Comforting, isn't it.) Most days that is fine. The day it stops being fine is the day one of those maintainers loses control of their email account and an attacker quietly publishes a new release of a package three layers deep in your dependency graph. Your lockfile asks no questions. Your scanner shrugs. The artifact is signed by the right key.
That is the failure mode npm just tried to make slower.
The actual change
On 2026-06-25, the GitHub Changelog announced a preventive safeguard for what npm calls "high-impact accounts," meaning the maintainers behind the registry's most widely used packages. When npm detects a sensitive account change on one of those accounts, specifically an email change or a 2FA recovery code use, it places the account into a 72-hour read-only state. An alert goes to the previous email address. No action is required to restore access; the lock lifts automatically when the 72 hours expire.
Inside the window, the maintainer can still install and download packages, view their organizations and teams, and browse account and package settings. What they cannot do is publish, manage tokens, change package visibility, or modify org and team membership. The point is the second list, not the first.
Three days. Automatic. No opt-in.
Why this lands on a CI/CD pipeline
Account takeover is the cheapest way to push malicious code through the supply chain because it skips every signature, every provenance check, and every scanner you bolted on. If the legitimate maintainer publishes the malicious version, the artifact is signed by the right key, attested by the right account, and resolved by your lockfile exactly the way an honest release would be. SBOM, provenance, scorecards: all green. The malware ships.
A 72-hour hold on publishing for the maintainers behind the most-installed packages narrows that exact window. An attacker who resets the email on a popular maintainer's account at 02:00 cannot push 1.4.7-malicious at 02:05. They have to wait three days, by which point the previous-email notification has either reached the maintainer or been ignored long enough to lose plausible deniability. It is a tax on the worst class of takeover.
And it is free. No flag to enable, no setting to forget. As a CI/CD owner you do not wire anything up; you inherit a slightly narrower attack window on your transitive dependency graph by sitting still.
So is this enough?
No. A 72-hour cool-down is a speed bump, and the attacker still controls the account at hour 73. The email-change alert can be missed (how often do you actually read mail from registries?). And "high-impact" is a list npm draws, not one your dependency tree votes on; if your build pulls a popular package three layers deep and that maintainer is not on npm's high-impact list, this change does nothing for you.
The bigger asterisk is the trigger. Email change and 2FA recovery code use are the documented signals. An attacker who phishes a session cookie or hijacks a still-valid token does not look like a "sensitive account change" to this filter. The hold is aimed at one specific play, reset-email-then-publish, and it is genuinely good at that. It is not aimed at every play.
For CI specifically, the dependency-pinning hygiene you already do is still the load-bearing layer. Lockfiles. Pinned versions. Integrity hashes. A holding pattern at the publisher is upstream insurance; it does not remove the case for npm ci over npm install, or for taking a second look at a popular dependency that suddenly bumps a major version on a Friday night.
How other registries draw the same line
The general shape (slow down the most sensitive operation on the most consequential accounts) is not unique to npm. PyPI's trusted publishing model leans the other way: shrink the surface where a long-lived credential can publish at all, and bind publishing to short-lived OIDC tokens issued by a known CI environment. RubyGems requires multifactor authentication on accounts owning gems above a download threshold; the bar applies all the time, regardless of attack signal. Maven Central gates publishing behind namespace ownership verification, which is slow by design but irrelevant once the account is in.
Each model picks a different point on the same curve. npm's new safeguard is aimed squarely at the gap between the moment a maintainer's password has just been changed and the moment that maintainer's downstream consumers know it has. That is a useful gap to close. It is also a small one.
What to do on Monday
If you maintain a widely installed npm package, expect to land inside the 72-hour window the next time you legitimately rotate your email or burn a recovery code. Plan the release calendar around it. Push the patch release first; update the email second.
If you only consume npm packages, this is mostly a free upgrade to your trust model. Use the time it buys: turn on whatever dependency-update bot you favour, look at how often new releases drop on packages you do not control, and decide which dependencies you would be comfortable pinning across a three-day quiet period. Many of them, you already are.
The attack class that lives in the gap between password reset and publish just got a 72-hour roof. It is not the fix. It is the floor.
