Make a list of every account that can publish your software or packages: package registries, container registries, app stores and source control organisations. For each, record the company owned email, at least two admins, MFA status and whether publishing uses long-lived tokens. Fix personal accounts and single points of failure before a buyer finds them.
Why this gets asked
If your product is published to a registry under an engineer's personal account, the company does not control its own distribution. If that person leaves or is compromised, so is your release channel. Acquirers look for it because it is easy to miss and expensive to fix after close.
The inventory
| Account | Check |
|---|---|
| Source control organisation | Owners list, MFA required, outside collaborators reviewed |
| Package registry (npm, PyPI, crates, Maven and so on) | Owned by an organisation, not a person; two maintainers |
| Container registry | Company account, push access limited |
| App stores | Company developer account, not personal |
| Domain and DNS | Company registrar account, MFA, expiry dates |
| CI and cloud providers | Admin list and break glass access |
| Signing keys and certificates | Where stored, who can use, expiry |
Replace long-lived tokens
npm's documentation on trusted publishing says it allows publishing from CI/CD workflows using OpenID Connect, eliminating the need for long-lived npm tokens, which can be compromised, exposed in logs or need manual rotation. It lists GitHub Actions on GitHub hosted runners, GitLab CI/CD on GitLab.com shared runners and CircleCI cloud as supported providers, and notes that self hosted runners are not currently supported. It requires a recent npm CLI and Node version, so check the page for current numbers.
Other registries have comparable options. If you cannot adopt them yet, shorten token lifetime, scope tokens to one package and store them in a secrets manager, not in a developer's shell profile.
Steps
- Ask each engineer to list accounts they use to publish or administer anything for the company.
- Cross check against the registry pages for your package names.
- Move any package from a personal account to an organisation, following the registry's process.
- Add a second admin to each account. Use a shared role mailbox for recovery, not one person's phone.
- Turn on MFA requirements at organisation level.
- Replace or scope publishing tokens and record rotation dates.
- Store the register in the data room with a date, without secrets.
Name squatting and look-alikes
Check that you own the obvious variants of your package names on the registries you use, and that your source control organisation name is not available to others under a near miss spelling. This is a cheap hygiene step and rarely takes more than an hour.
What not to share
The register should list accounts, owners and controls, never credentials or recovery codes. If a buyer needs to verify, show them in a screen share.
Red flags
Personal email addresses as registry owners. A single admin. Tokens in CI variables that never rotate. Accounts for abandoned products still able to publish.
Quick check
Is a shared password a way to give two people access?
No. Use separate named accounts with an organisation role, so access can be revoked per person.
Does OIDC publishing remove the need for MFA?
No. Keep MFA on human accounts. OIDC removes a stored secret from the pipeline.
Safeguard's asset discovery and compliance evidence automation can help keep a register like this current. A free scan covers dependencies in a repository.
Sources
Last reviewed: 19 October 2026.
