When a maintainer leaves, remove their repository role first, then check every other place access can hide: package registries, CI secrets, deploy keys, domain and DNS accounts, shared mailboxes and chat. Rotate anything they could read. Do it on good terms and on a schedule, not only after a falling out.
Start with the repository
Remove the person as a collaborator or from the team. Remember what Write allows: workflows, Actions secrets and variables, packages and releases. Anything a Write user could read or change should be treated as known to them afterwards.
If they were Admin, also look at webhooks and deploy keys. Admin can manage both, and these keep working after the person is gone.
Rotate what they could see
A role change does not erase what someone has already seen. Rotate:
- Repository and environment secrets they could use or read through a workflow
- Deploy keys and tokens they created
- Any signing key they held
- Shared credentials for services such as a docs host or analytics
If you are unsure whether they ever had access to a secret, rotate it. It is cheaper than guessing.
Registry and publishing
- Remove them as owner or maintainer on each registry where the package is published.
- Revoke their personal access tokens for publishing.
- Check trusted publisher settings, if you use them, for any link to their personal repository or account.
If publishing already runs from CI with short-lived credentials, this step is much shorter. The reasons are in npm maintainer account security.
The less obvious places
Walk this list:
- Domain registrar and DNS accounts
- Documentation or website hosting
- Security contact mailbox or alias
- Chat server and mailing list moderator rights
- Funding accounts and payout details
- Calendar invites for release calls
A security alias that still forwards to a former maintainer is a quiet way for reports to leak. Update it.
Keep it friendly and fast
Offboarding is routine, not an accusation. Say so. Thank them, record the date and the reason in your governance notes, and list what was removed. A written record helps you answer questions later, from users or auditors.
When it is not friendly
If you suspect an account was taken over, skip the polite order. Remove access, rotate secrets, and review recent commits, releases and workflow changes. The maintainer runbook for a compromised package covers the next steps.
Quick check
Is removing the GitHub role enough?
No. Registries, secrets, deploy keys, DNS and shared accounts each keep their own access lists.
Should I rotate secrets for every departure?
Rotate any secret the person could read or use. For a Triage-only helper there may be none.
Sources
Last reviewed: 19 October 2026.
