How npm's Staged Publishing Mirrors Accounting's Dual-Approval Controls

When Your Package Manager Starts Acting Like an Auditor

If you've spent any time in accounting, you know the drill: no single person gets to move money without a second pair of eyes. The person who writes the check isn't the person who signs it. That's segregation of duties, and it's been a cornerstone of financial control for centuries. So when npm announced its new staged publishing feature—which inserts a human approval step before a software package goes live—I couldn't help but see the parallel.

npm, the default package manager for Node.js, now lets maintainers push a version to a staging queue. It sits there, visible on npmjs.com and in the CLI, until a human with two-factor authentication (2FA) explicitly approves it. Only then does it become available for anyone to install. It's a small change in workflow, but a big shift in mindset: publishing is no longer a single, irreversible act. It's a process with checkpoints.

For accounting teams that build or maintain internal tools, this isn't just a developer convenience. It's a control mechanism that mirrors what you already do with financial transactions. And if you're responsible for software that handles ledgers, invoices, or payroll, understanding this pattern matters.

Segregation of Duties, Translated into Code

In accounting, segregation of duties means breaking a process into steps so no one person can both commit and conceal an error or fraud. The classic example: the person who approves a purchase order shouldn't also be the one who approves the payment. In the npm world, the developer who writes the code and runs the build isn't necessarily the one who approves the final release. With staged publishing, the CI system can upload the tarball, but a human—ideally a different one—must approve it.

The new npm CLI commands make this explicit:

• npm stage publish — submit the version to the stage queue
• npm stage list — see what's waiting for approval
• npm stage view <stage-id> — inspect the tarball before approving
• npm stage approve <stage-id> — promote it to the registry, with a 2FA prompt
• npm stage reject <stage-id> — discard it

That approve step is the equivalent of a second signature on a check. The 2FA requirement is like requiring a manager's PIN. And the ability to inspect the tarball before approving? That's your review of the supporting documentation before you sign off.

Audit Trails in the Registry

Every stage action—publish, list, view, approve, reject—leaves a trace. In accounting, an audit trail is non-negotiable. You need to know who did what, when, and why. The staged queue provides that. If a package is rejected, there's a record. If a version sits in staging for days, you can see it. This isn't a full audit log, but it's a start—and for teams that already use provenance attestations, it's a natural extension.

npm's staged publishing also works with OIDC-based trusted publishing. That's a way for CI systems to authenticate without long-lived tokens. For accounting teams, think of it as replacing a shared password with a time-limited, scoped credential. The GitHub recommendation is to configure trusted publishing so that it can only stage, not directly publish. That means even if your CI is compromised, the attacker can't push a malicious version to the registry without a human approving it. That's a control that would make any auditor smile.

Why This Matters for Accounting Software

If your firm develops or maintains accounting software—whether it's a custom internal tool or a commercial product—you're already in the business of trust. Your code handles sensitive financial data. A bug or a backdoor in a dependency could be catastrophic. Staged publishing doesn't solve all supply chain risks, but it does close a specific gap: the one where a compromised CI pipeline silently publishes a bad release.

Consider the recent Shai-Hulud worm attack on npm packages. It exploited weak tokens and automated publishing to spread malware. Staged publishing would have stopped it cold, because the worm couldn't approve its own releases. Security researcher Adnan Khan put it bluntly: everyone publishing to npm should enable this now. For accounting software, that's not just good advice—it's a fiduciary responsibility.

Not a Silver Bullet, but a Real Control

Some in the developer community have called staged publishing a band-aid. One Hacker News user worried it might actually harm long-term security by giving a false sense of safety. Another countered that it's a major improvement over trusted publishing, because it blocks a whole class of attacks. Both points have merit. It's not a cure-all. But it's a concrete, usable control that changes the risk profile.

For accounting professionals, this is familiar territory. You don't eliminate fraud with a single control; you layer them. Segregation of duties, dual approvals, reconciliations, audits—each one reduces risk. Staged publishing is another layer. It doesn't replace code review or dependency scanning. It adds a human checkpoint at the moment of release.

What the Toolchain Shift Means for Your Team

Adopting staged publishing isn't just a developer decision. It has implications for your release process, your CI configuration, and your internal policies. Here's a mental checklist for accounting teams:

• Separate the roles. Who writes the code? Who runs the build? Who approves the release? Make sure it's not the same person.
• Document the process. Write down when staging is required, who can approve, and what happens if a release is rejected.
• Test the workflow. Run a staged release on a non-critical package first. Make sure your CI can handle the new commands.
• Review your token policies. Fine-grained tokens that can bypass 2FA should be limited to staging, not full publish.
• Consider other package managers. pnpm 11.3 has a pnpm stage command with the same subcommands. Yarn has an equivalent. If you're using a different manager, check what's available.

The npm CLI requires version 11.15.0 or later, and Node.js 22.14.0 or above. Your packages must already exist in the registry. That's a technical prerequisite, but the human prerequisite is just as important: you need a culture that accepts review as part of the job.

Default to Safety

One of the most interesting parts of the npm announcement is what's coming next. In npm v12, the default for --allow-git will change to none. That's a shift toward safer defaults. The same philosophy should apply to your accounting software: default to controls that protect the integrity of the financial data.

If you're using GitHub Actions for CI, the recommendation is to combine staged publishing with OIDC-based trusted publishing. You can limit the workflow to only stage, and then have a separate approval step. That's a clean pattern: automation does the heavy lifting, but a human makes the final call. It's like having a robot prepare the journal entry, but a CPA reviews it before it posts.

The Bottom Line

Staged publishing in npm is a small feature with a big conceptual message: publishing is not a single event, it's a process with checkpoints. For accounting teams, that's not a novel idea—it's how you've always worked. The challenge is to bring that same rigor to your software development pipeline.

So the next time you're setting up a release workflow, think about your accounting controls. Who's the second set of eyes? Where's the audit trail? What happens if something goes wrong? If you can answer those questions, you're not just a developer or an accountant—you're someone who understands that trust is the most valuable asset in both fields.