Remove their login first, then every token they created, then any CI credential they set up, then publish and admin rights. Finally review what they published recently. Tokens are the step teams forget, because a token keeps working after the account that created it is disabled, depending on how your mirror issues them.
Why the mirror needs its own step
A package mirror often sits outside the single sign-on system the rest of the company uses. It has local users, API tokens and service accounts. If offboarding only covers email and source control, a former developer may still hold a working token that reads internal packages or even publishes to them.
The checklist, in order
- Disable the personal account. If the mirror uses single sign-on, confirm that disabling the identity really ends access, including existing sessions.
- Revoke personal access tokens. List tokens by owner if your mirror supports it. If it does not, rotate shared tokens the person knew.
- Rotate credentials in CI that they created. A pipeline token created under their name may stop working when the account is disabled, which causes a surprise outage, or may continue working, which leaves a gap. Move such tokens to a service account first.
- Remove publish and admin roles. Check group memberships and per repository permissions, not just the global role.
- Check deploy keys and webhooks they added, such as those that trigger builds or notifications.
- Review recent publishes. Look at what they uploaded in the last few weeks and confirm each internal package version matches a reviewed commit.
- Update the access record with the date and the person who completed the work.
Order matters because of outages
If you revoke a token that a production build depends on, the next deploy fails at a bad moment. So prepare replacements before the leaver's last day. A short list helps:
| Item | Replacement before revocation |
|---|---|
| Token used by a CI job | Service account token, scoped read only |
| Token used to publish releases | Token owned by a team account, with a second approver |
| Personal token on laptop | None needed, laptop is returned |
What to review after they have gone
Open the mirror's audit log, if it keeps one, for the person's account in the final month. You are looking for unusual downloads of many internal packages, changes to permissions, new tokens created close to the leave date and uploads outside normal hours. A related post covers what to record in such a log: what an internal registry should log.
A mirror that has no audit log is a gap worth fixing before the next departure.
Make it routine
- Add the mirror to your standard leaver ticket template.
- Keep an inventory of who holds which tokens, with an owner for each.
- Review the user list every quarter and remove accounts nobody can explain.
- Prefer short lived tokens, so a missed revocation expires on its own.
Where Safeguard fits
Safeguard's agent identity and asset discovery features help you keep track of which identities and assets exist, which supports the same discipline of knowing who and what has access. A free scan is at gold.safeguard.sh/scan.
Quick check
Does disabling the account always kill its tokens?
Not always. It depends on how the mirror issues tokens. Test with a spare account before you need it.
What if the leaver was the only admin?
Create a second admin first, then rotate the admin credentials and store them in a shared secret store.
Last reviewed: 19 October 2026.
