How to Run an Access Review for Service Accounts: Scope, Evidence and Decisions

A service account has no manager to approve it, no leaver date to trigger removal and no user to complain when it is wrong, so a standard access review either skips it or asks someone to approve a name they do not recognise. This guide is the procedure for reviewing service accounts properly: what to put in scope, which usage evidence each platform gives you and how far to trust it, who should decide, and how to turn each decision into a safe change. It covers Active Directory, AWS, Google Cloud and Microsoft Entra ID (listed alphabetically) as the most common sources of usage evidence. It is for identity governance teams, platform owners and auditors. Campaign design for people is in the Access Reviews Guide, and the line-by-line evidence checklist is in the Access Review Checklist; this page goes deeper on the non-human part.

Key takeaways

• Scope is the hard part: include directory service accounts, cloud roles and service principals, workload identities, API keys and integration users, not only what the IGA tool can see. An account that is not in scope is approved by default.
• Review on evidence, not memory: every row should carry last authentication, permissions granted versus permissions used, credential age and owner. Reviewers who decide "probably still needed" without data keep dormant access alive.
• Know each evidence source's blind spots: AWS last accessed data excludes some activity, Google Cloud's unused account insight does not see domain-wide delegation, and Active Directory's replicated logon time can lag by days. Treat "unused" as a hypothesis to test, not a fact.
• The owner decides, the platform team executes: the accountable owner of the system the account serves certifies purpose and need; platform engineers carry out the change.
• Disable before delete: a reversible disable with a monitoring window catches the account that runs once a quarter, and then the deletion is safe.

When you need this

• Recurring control: CIS Controls v8.1 Safeguard 5.5 expects an inventory of service accounts with owner, review date and purpose, reviewed at least quarterly, and NIST SP 800-53 AC-2 requires accounts to be reviewed for compliance with account management requirements at an organisation-defined frequency.
• After an incident or near miss involving a non-human identity. In the Dropbox Sign Breach 2024, Dropbox reported that a compromised back-end service account, reached through an automated system configuration tool, could take a variety of actions in the production environment and was used to reach the customer database; a review that compares granted with needed access is how that breadth is found before an attacker finds it.
• Before a migration to managed identities, gMSA or workload identity federation, so that you do not migrate accounts nobody needs.
• Audit findings that the people review excluded service accounts, or that approvals had no evidence.

Before you start

Define what counts as a service account

• Inventory first: start from the Service Account Inventory Template. Every row needs a technical owner team and an accountable individual; the OWASP Non-Human Identities Top 10 (2025) lists Improper Offboarding (NHI1), Overprivileged NHI (NHI5) and Human Use of NHI (NHI10), and each of these is found through ownership and usage data.
• Decide frequency by risk (our recommendation): quarterly for privileged or internet-reachable accounts, half-yearly for the rest, and on any change of owner.
• The collector is itself a non-human identity: reading sign-in activity, last accessed data and insights across the estate needs broad read permissions. Give it its own scoped, read-only identity with an owner, and include it in the review.

Step-by-step

1. Freeze the scope. Extract every account in the types above as of a fixed date. Record the count per platform; the final report must reconcile to it.
2. Attach usage evidence to each row from the sources in the evidence table below: last authentication, last use of each permission where available, and the systems it connects to.
3. Attach permission evidence: roles, group memberships and API permissions, with privileged ones flagged (domain-level groups, owner or administrator roles, write access to production data).
4. Attach credential evidence: credential type (password, secret, certificate, key, federated), age, expiry, where it is stored and whether rotation is automated. See the Rotating a Windows or Linux Service Account Password guide.
5. Check for human use: interactive sign-ins or console sessions by a service account indicate a shared credential (NHI10). Flag them for the reviewer.
6. Route each row to its owner with a short form: purpose, the systems that depend on it, whether the permissions shown are needed, and a decision. Unowned rows go to the platform owner and are escalated, never auto-approved.
7. Collect decisions with reasons. "Keep" needs a stated purpose and, for privileged access, a reason for each privileged permission. Reject decisions with no reason.
8. Raise changes from each "reduce", "disable" or "replace" decision with an owner and a due date, and run them under change control.
9. Verify and close: re-extract after the due date and reconcile every decision to the platform state.

Usage evidence by platform

Decision matrix

Verify it worked

• Reconcile: every account in the frozen scope has a decision, and every decision has a closed change or an approved exception.
• Re-extract: disabled accounts are disabled, removed roles are gone, and no disabled account has authenticated since its disable date. Use by a revoked account after the decision is an incident to investigate.
• Sample: re-perform a sample of "keep" decisions with the evidence and confirm the reason holds.

Measures

• Share of service accounts in scope with a named owner (target 100 percent).
• Revocation or reduction rate per campaign, by owner team: a team that keeps everything every time needs a closer look.
• Accounts with no authentication in 90 days still enabled after the campaign.
• Median age of service account credentials, and share using managed identities or federation.
• Time from decision to verified change.

Rollback and common errors

• A disabled account breaks a quarterly or annual job: re-enable it (this is why you disabled rather than deleted), record the owner and schedule, and extend the review look-back for that class of account.
• A role reduction breaks an application: restore the previous role assignment from the change record, then reduce in smaller steps with the owner watching logs.
• Acting on "unused" from one source: each evidence source above misses some activity. For anything privileged or business-critical, confirm with a second source such as authentication logs before disabling.
• Reviewing accounts but not credentials: a kept account with a ten-year-old password is still a finding. Put credential age on the review form.
• Letting the IGA connector define scope: SaaS integration users, cloud keys and database accounts are missed. Reconcile scope against each platform's own listing.

Hardening afterwards

• Make ownership mandatory at creation: no owner tag, no account.
• Prefer credentials that do not need reviewing: managed identities, gMSA and workload identity federation remove long-lived secrets. See How to inventory Google Cloud service account keys and replace them with federation.
• Alert between reviews: interactive sign-in by a service account and new privileged role assignments; NIST SP 800-53 AC-2(12) calls for monitoring accounts for atypical usage.
• Find the most dangerous first: How to find service accounts with Domain Admin rights and How to find and retire Active Directory service accounts with SPNs.

Framework mapping

Practitioner checklist

• Define service account types in scope and freeze the population on a date.
• Give every account a technical owner team and an accountable individual.
• Attach last authentication, permissions granted versus used, and credential age to every row.
• Record each evidence source's limits on the review form.
• Send rows to system owners, not line managers, and require a reason for each keep.
• Disable before delete, with a monitoring window and a documented rollback.
• Reconcile decisions to platform state and investigate any use after revocation.
• Scope and review the collector identity itself.

Standards and references

• NIST: SP 800-53 Rev 5, Security and Privacy Controls (AC-2, AC-6, IA-5)
• OWASP: Non-Human Identities Top 10 (2025)
• AWS: Refine permissions using last accessed information
• Google Cloud: Find unused service accounts
• Microsoft Learn: List servicePrincipalSignInActivities
• Microsoft Learn: Last-Logon-Timestamp attribute

Related NHI Mgmt Group resources: Access Reviews Guide · Access Review Checklist · Service Account Security Guide · Service Account Inventory Template · Service Account Breaches Lessons Guide