When an employee who maintains a company-backed open source project leaves, transfer ownership of the repository, remove or reassign their access, rotate shared credentials, and tell the community who now speaks for the project. Do it on their last day, not months later when something breaks.
Why this matters
Projects often depend on one or two people who hold admin rights, publishing credentials and community trust. The Open Source Guides suggest moving a project from a personal account into an organization and adding at least one backup admin, so access does not depend on one person. If the maintainer leaves without that, the company may be unable to release, archive or even answer reports.
Before they leave: the offboarding checklist
| Step | Detail |
|---|---|
| Confirm who owns the repository | An organization, not a personal account |
| Name successors | At least two people with admin and release rights |
| Move credentials | Registry tokens, signing keys and CI secrets owned by the company, rotated after departure |
| Review access | Remove their access if they no longer work on the project, or document why not |
| Transfer knowledge | Release steps, security contacts, open vulnerability reports |
| Update the project docs | Maintainers list, security contact, governance file |
| Announce | A short note in the repository and any community channel |
For a full access checklist, see remove a maintainer access offboarding checklist.
If they stay as a volunteer
Some leavers want to keep contributing. That is fine, but it changes the relationship. Clarify in writing:
- They contribute as an individual, not on behalf of the company.
- They no longer hold company credentials or publishing rights unless the project community grants them.
- They follow the same review rules as any outside contributor.
The Guides note that paid contributors are not treated specially, and each contribution is judged on technical merit. The same applies to a former employee.
Security specifics
- Open vulnerability reports. Hand them to a named person and record the disclosure deadline.
- Two-factor devices. If their phone held the second factor for a shared account, replace it. See maintainer account recovery codes and backups.
- Package registry ownership. Add a company-owned maintainer before they leave. See transfer npm package ownership to a new maintainer.
- Signing keys. If one person held a release signing key, generate a new one and publish the change.
Governance fixes that prevent the problem
- Require two maintainers with admin rights on every company project.
- Keep release credentials in a company secrets store, not a personal account.
- Put a bus factor review on the quarterly calendar. See how to calculate bus factor.
- Document the release process so any maintainer can follow it.
If nobody can take over
Be honest. Archive the repository or transfer it to a trusted steward, and announce it. See archive, transfer or delete a retiring repo. An abandoned project with live credentials is a supply chain risk for everyone who depends on it.
Where Safeguard fits
Safeguard's asset discovery and agent identity capabilities help a company see which accounts and automated actors hold access to its systems, and policies and gates help enforce review on changes. A free scan is available at gold.safeguard.sh/scan.
Quick check
Should a departing maintainer keep admin rights?
Generally no, unless the community grants them on its own terms. Company-owned access should follow employment.
How many admins should a company project have?
At least two, so one departure never locks you out.
Sources
Last reviewed: 19 October 2026.
