Identity
Part of Cloud identity and access
Removing dormant credentials from cloud environments
Find cloud credentials that appear unused, check dependencies, disable and observe them, then delete confirmed dormant credentials.
Treat a cloud credential with little or no observed use as a candidate for review. Identify its owner and consumers, check the activity signal's limits, disable it where supported, then observe the relevant workload before deleting it.
Find candidates and owners
Include long-lived access keys, service-account keys and other provider-managed credentials that can be inventoried. Record the credential identifier, identity, type, owner, known consumers, creation date and available use data.
Check deployment configuration and approved secret stores for references without copying secret values into the review record. Review employee sign-in access through its identity system as well; disabling one credential differs from disabling an entire account.
AWS IAM credential reports show IAM users and the status of specified passwords, access keys and MFA devices. The report omits service-specific credentials and some key types, so it is not a complete credential inventory. Use the provider's relevant listing methods for credentials outside its coverage.
Key Cloud Credential Management Practices
- AWS IAM Report Coverage
- Shows passwords, access keys, MFA devices – but excludes service-specific credentials.
- Google Cloud Service Account Keys
- Best practices for creation and deletion available at Google Cloud IAM docs.
- Service Account Key Best Practices
- Follow guidelines for managing keys and avoiding long-lived secrets.
Check the evidence behind dormancy
Compare credential-specific use data with job schedules, release records, recovery procedures and the owner's account of the workload. Document what the available use signal covers and omits, and record any evidence gaps.
| Finding | Decision |
|---|---|
| Confirmed current consumer | Retain for now; record the owner and consider a safer replacement |
| No current consumer and owner agrees | Plan disablement and an observation period |
| Owner or dependency unknown | Investigate and set a decision date |
| Suspected exposure | Escalate through the incident process promptly |
Disable, observe and delete
For planned retirement, choose an observation period that covers the credential's relevant use pattern. Record the owner, credential identifier, rollback authority and workload signals to inspect. Disable the credential where the platform permits, then check scheduled jobs, authentication failures and the business action it supports. A quiet hour says little about a monthly process.
Where the platform supports it, disable the credential before deletion and observe the effect. Confirm which object changes: disabling an entire identity can affect every workload using it, not just the credential under review.
After the owner confirms retirement, delete the credential in the provider, update current configuration and remove remaining copies through the normal change process. Record the result and any other active credentials for the same identity.
A suspected compromise needs prompt incident handling rather than this observation sequence. Deleting or disabling credentials during that response can remove access for workloads that depend on them, and the incident owner must account for that effect.
Close the record
Keep the evidence considered, owner decision, dates of disablement and deletion, observed workload result and any exception. If a credential remains, record why it is needed, how it is protected and when it will be reviewed again.
