A service-account review should prove that every non-human identity has a current business purpose, named owner, known workload, limited permissions, visible credential lifecycle, and safe retirement path. Inventory the account and its dependencies first; do not rotate, disable, or delete it until the consumers and recovery plan are verified.
Build one record per identity
Record the service account or service principal name and immutable identifier, platform and tenant, environment, linked application or workload, business purpose, primary owner, backup owner, creation date, review date, and expected lifetime. Add every resource it can access and every person or system allowed to impersonate or manage it.
Google describes service accounts as non-human users and recommends managing them as resources attached to the workload they serve, using single-purpose accounts and identifying unused accounts (Google Cloud service-account guidance). A generic account shared across unrelated applications makes ownership, permissions, logs, and retirement harder to interpret.
Inventory credentials and authentication paths
For each account, list whether it uses a managed identity, workload identity federation, impersonation, certificate, client secret, or downloaded key. Record the credential identifier, storage reference, creator if available, creation date, expiration date, rotation owner, consumers, and last observed use. Never put the secret or private-key value in the review sheet.
Prefer an authentication method that avoids long-lived downloadable keys when the platform and workload support it. Google's key-management guidance says user-managed service account keys create leakage and privilege risks and recommends more secure alternatives where possible (Google Cloud key guidance). This is a migration decision, not a reason to delete a working key before its replacement is tested.
Verify ownership and review dates
Contact the named owner with the recorded workload, permissions, credentials, and recent-use evidence. Require an explicit keep, change, or retire decision and assign a due date. If the owner has left or cannot explain the account, locate the resource owner and incident contact before changing access. Mark unknown ownership as a risk that needs resolution.
Microsoft's service-account governance guidance recommends documenting an owner, business purpose, risk, review period, anticipated lifetime, credential type and lifetime, and a process for missed reviews (Microsoft Entra guidance). It advises disabling rather than deleting an account while a late review or dependency check is completed.
Review permissions and use evidence
Compare granted permissions with actual workload actions and current design. Flag broad administrative roles, organization-wide access, unused scopes, cross-environment access, and people who can create keys or impersonate the account. Reduce access only through a tested change with rollback.
Use audit logs, authentication metrics, deployment configuration, and application owners to confirm last use. A lack of recent login evidence may indicate an unused identity, but it can also describe a monthly job, disaster-recovery path, or seasonal task. Check the expected schedule before declaring the account dormant.
Handle expiration without an outage
For credentials with an expiration date, alert the owner early enough to create and validate a replacement. Introduce the new credential or identity, update one consumer at a time when possible, confirm successful authentication and business output, then revoke the old credential. Do not simply extend expiration indefinitely.
Google notes that downloaded service account keys have no default expiry unless configured and warns that expiration can cause production outages if lifecycle management is weak. Microsoft recommends avoiding service-principal credentials that never expire. The practical control is an owned rotation process with monitoring, not an isolated date field.
Retire safely
For an account approved for retirement, stop new dependencies, identify every consumer, disable the account or credential, and observe through at least one expected execution window. Confirm alerts and downstream results, then delete only after the rollback period and retention requirements are satisfied. Preserve the approval, disable time, dependency evidence, and final deletion record.
Completion check
The review is complete when each account has an accountable owner and backup, a linked workload and purpose, reviewed permissions, credential and expiry evidence, recent-use interpretation, rotation and alert owners, and a documented keep, change, or disable-before-delete decision.
Sources
- Best practices for using service accounts securely — Google Cloud Documentation
- Best practices for managing service account keys — Google Cloud Documentation
- Governing Microsoft Entra service accounts — Microsoft Learn