Pull last used data for people, keys, tokens and roles every quarter, flag anything idle past a threshold you set, disable it, wait for complaints, then delete. AWS recommends regularly reviewing and removing unused users, roles, permissions, policies and credentials, using last accessed information. Do this routinely and offboarding gets much smaller.
Why a standing sweep beats a leaver rush
At offboarding time you are searching under pressure for what one person held. A standing sweep inverts that. You continuously shrink the pile of credentials, so any single departure touches fewer things.
It also finds the credentials that nobody owns, which a people based checklist never will.
Where last used data exists
AWS provides last accessed information for users, roles, permissions, policies and credentials, and says to use access key last used data to update and remove keys safely. GitHub shows tokens and their permissions to organization owners, and the People page shows which members have 2FA. Other tools have similar views. Check each system you run.
The sweep, step by step
- List systems that issue credentials: cloud, source host, CI, registries, monitoring, SaaS admin consoles.
- For each, export identities and credentials with created date, last used date and owner.
- Pick a threshold. Many teams start at 90 days idle, then tighten. Choose a number you can act on.
- Flag everything past the threshold, and everything with no owner.
- Ask owners to confirm or claim within a week. Silence counts as no.
- Disable, do not delete. Deactivate keys and suspend accounts.
- Wait one more cycle or a short fixed period.
- Delete what stayed quiet. Record the batch in a log.
- For anything kept, set an owner and a review date.
What to count as a credential
| Type | Examples |
|---|---|
| Human accounts | SSO users, local admin accounts, shared mailboxes |
| Programmatic keys | Cloud access keys, API keys |
| Tokens | Personal access tokens, registry tokens |
| Keys | SSH keys, deploy keys, signing keys |
| Roles | Cloud roles that nobody assumes |
| Integrations | OAuth apps and webhooks |
Deploy keys deserve a mention. GitHub's documentation says they belong to the repository, usually have no passphrase and do not expire, so a last used view may not be available. Review those by owner and age instead.
Handling false positives
Some credentials are legitimately used rarely, such as a disaster recovery key. Mark them with a reason and a longer review interval. Do not exempt them silently, or the exemption list becomes the new hiding place.
Report the result
Track three numbers over time: credentials found idle, credentials without an owner, and credentials removed. If the first two are falling, the process works. These figures are also tidy evidence for an access review.
Quick check
What idle threshold should we use?
There is no universal number. Start with one you can act on, such as 90 days, and tighten as the process matures.
Should we delete or disable first?
Disable first. It is reversible, and it shows you which hidden dependencies exist before you delete.
Safeguard's asset discovery and compliance evidence automation can help you inventory identities and keep review evidence together. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
