Transferring Package Ownership to an Organization

Many packages start life under a personal npm account: someone wrote a useful library, published it, and others started depending on it. When the package becomes important to a company or a community, personal ownership becomes a risk — publishing depends on one person's availability and account security, and access cannot be managed as a team. Moving the package into an npm organisation puts ownership behind teams, 2FA requirements and auditable access, and it is best done while the original maintainer is still available to hand over cleanly. This guide covers the difference between owners and organisations, how to move unscoped and scoped packages, how to set up team access afterwards, and the handover checks that keep the transfer safe.

Owners, maintainers and organisations

On the public registry, a package has a set of owners (also called maintainers) — accounts with full publish rights, including adding other owners. An organisation is an entity with members, teams and packages; packages owned by an organisation are managed through teams that are granted read-only or read-write access per package.

The broader lifecycle is covered in Package Deprecation and Lifecycle.

Moving an unscoped package into an organisation

Unscoped packages (tiny-date-fmt) can be moved into an organisation without changing their name, because the name does not contain a scope. An owner of the package who is also an owner or admin of the organisation can transfer it through the package's settings on the npm website (the option to move or transfer the package to an organisation). After the transfer, the organisation owns the package and access is granted through teams.

The exact labels in the website's settings change from time to time, so follow npm's current documentation for the button names; the underlying rule is stable — the person performing the transfer must control both the package and the destination organisation. If you are not an admin of the target organisation, the process is a handover between people: the current owner adds an organisation admin as an owner, the admin performs the transfer, and the original owner is then managed through team membership like everyone else.

Moving a user-scoped package

A package scoped to a user (@alice/date-fmt) cannot move into an organisation's scope without changing its name, because the scope is part of the name. You have two options:

• Keep the name, share ownership: add team members or an organisation admin as owners with npm owner add. The package stays under @alice, which works but keeps personal branding and does not give organisation-level team management.
• Rename into the organisation's scope: publish as @acme/date-fmt, and deprecate the old name with a pointer, as described in Renaming a Package Without Stranding Users.

Setting up team access after the transfer

Once the organisation owns the package, grant access through teams and remove individual ownership:

# Create teams that match responsibilities
npm team create acme:date-maintainers
npm team add acme:date-maintainers alice
npm team add acme:date-maintainers bob

# Give the team read-write access to the package
npm access grant read-write acme:date-maintainers tiny-date-fmt

# Review who has access
npm access list collaborators tiny-date-fmt
npm owner ls tiny-date-fmt

Then tighten security:

• Require 2FA for all organisation members, and set the package's publishing access to require 2FA — see Requiring 2FA for Package Maintainers.
• Move CI publishing to trusted publishing, configured on the package, so no personal or long-lived token is needed — see Publishing from CI with npm Trusted Publishing.
• Revoke the previous owner's tokens used for publishing this package, and remove any CI secrets that contained them.

Designing teams for package access

Teams are the unit of access once packages live in an organisation, so design them around how packages are maintained rather than around the org chart. A few patterns work well.

One team per group of packages with shared maintainers. acme:ui-maintainers gets read-write access to the design system packages; acme:sdk-maintainers to the SDKs. When someone joins or leaves a group, one team membership changes.

A small release team for automation-adjacent tasks. With trusted publishing, CI needs no team membership at all, but people who move dist-tags or deprecate versions by hand should be a deliberately small group.

Read-only teams for private packages. For organisations publishing private packages, consumers need read access; grant it to broad teams (acme:developers) with read-only permission, separately from the maintainer teams with write access.

A named admin set. Organisation owners can do everything, including deleting teams and transferring packages away. Keep the owner role to two or three people with hardware-key 2FA, and review it with the same care as production cloud administrators.

Record the mapping from packages to teams in the repository — for example in CODEOWNERS comments or a MAINTAINERS.md — so reviewers can see that registry access and repository ownership match. Mismatches, such as a team that can publish a package it cannot merge changes into, are worth fixing, because they create publishing paths that bypass code review.

Auditing access periodically

Access drifts as people move between teams. A quarterly script that lists owners and team access for every organisation package catches the drift:

for pkg in $(npm access list packages acme --json | jq -r 'keys[]'); do
  echo "== $pkg"
  npm owner ls "$pkg"
  npm access list collaborators "$pkg"
done

Look for individual owners that should have been removed after a transfer, teams with write access that no longer maintain the package, and packages with a single maintainer — each is either a cleanup task or a bus-factor risk.

Handover checks

Ownership transfers are also a known attack path: several supply-chain incidents began with a well-meaning maintainer handing a popular package to someone who later published malicious code. Whether you are giving a package away or receiving one, check:

1. Identity and intent of the recipient. For community handovers, prefer established maintainers or foundations; for company transfers, the organisation's admins.
2. Repository access matches registry access. The people who can publish should be the people who can merge to the release branch.
3. Publishing path. After the transfer, releases should come from the repository's CI with provenance, not from someone's laptop.
4. Communication. Announce the transfer in the repository and release notes, so users know who maintains the package and can decide whether to keep trusting it.

Worked example: a personal library becomes company infrastructure

An engineer's personal library, env-schema-lite, is used by forty internal services. The engineer is the only owner; publishing happens from their laptop with a classic token. The company creates an acme npm organisation (if it does not already have one), the engineer transfers the unscoped package to it through the package settings, and a platform team gets read-write access. The engineer is removed as an individual owner (they remain in the team), their old token is revoked, the package's publishing access is set to require 2FA and disallow tokens, and trusted publishing is configured for the repository's release workflow. The README is updated to name the platform team as maintainers. When the engineer changes teams a year later, removing them from the platform team is the only access change needed.

Prevention and guardrails

• Publish important packages from an organisation from the start.
• Manage access with teams, not individual owners.
• Remove old owners and tokens after every transfer.
• Announce ownership changes publicly.

Frequently Asked Questions

Does transferring a package change its name or versions? Not for unscoped packages. Name, versions, download history and dependents stay the same; only ownership and access management change.

Can a package have both individual owners and team access? Yes, but it defeats the purpose. Individual owners retain full rights outside team management. Remove them once teams are set up.

Is an npm organisation free? Organisations that publish only public packages are free. Private packages require a paid plan.

What if the only owner is unreachable? Without an owner's cooperation, a transfer is not possible through normal means. npm support has a dispute process for abandoned packages, but it is slow and not guaranteed. The lesson is preventive: every important package should have at least two owners or be owned by an organisation.

Do dependents need to change anything after a transfer? No. Consumers install by name, and the name does not change for unscoped transfers. They may want to check the new maintainers and provenance, which is why the announcement matters.

Related

• Package Deprecation and Lifecycle covers ownership as part of a package's life.
• Publishing Scoped Packages to npm sets up organisation scopes.
• Requiring 2FA for Package Maintainers secures the accounts that keep access.
• Renaming a Package Without Stranding Users handles moving user-scoped packages.

← Package Deprecation and Lifecycle