Writing the Service Account Inventory Your Auditor Will Ask For

Every column exists to answer a specific reviewer question. If a column answers none, drop it; a wide sheet nobody updates is weaker evidence than a narrow one that is current.

The authentication method column deserves care because it decides what "rotation" even means. A long-lived API key sitting on a laptop is a different animal from a token issued on request. Google Cloud lets you create short-lived credentials for a service account directly, which removes the standing secret altogether (Google Cloud IAM). OpenShift bound service account tokens are audience and time-bound, so a token stolen from a pod has a narrow window (Red Hat). Kubernetes service accounts exist as objects in the API server and are namespaced, so they need inventorying per namespace, not per cluster (Kubernetes). When your sheet records "managed identity, one hour token", a rotation date of "not applicable, short-lived" is stronger evidence than a date nobody dares change.

On Windows the same distinction applies. Microsoft recommends group managed service accounts whenever possible, because they give one identity for services across a server farm, and it warns that service accounts should not sit in privileged groups, with each service having its own account for auditing purposes (Microsoft Learn). If the method column says gMSA, the rotation column can say "automatic, platform-managed", and the reviewer stops asking about password age.

One column stays out on purpose: the secret value. Record a secret's name, type, location and permission, never its value, or the inventory becomes the next breach (MavenHandle). The same discipline applies to application passwords, which belong only in the client's configuration file and never in screenshots, chat messages, tickets or repositories (UiChemy).

The most common failure in a service account inventory is a row where the owner is a team alias. Ask who would notice if the account were disabled on a Friday. If the answer is "the team", nobody has attested to it.

Google Cloud's guidance treats service accounts as resources with a naming and documentation convention, created single-purpose, and disabled before deletion when they appear unused (Google Cloud IAM best practices). Every one of those recommendations assumes a human can be found to confirm. Mapping each non-human identity back to a human owner is now an explicit product category, which tells you how routinely this is skipped (Entro). Non-human identities are reported to outnumber human users 17 to 1 in surveyed organizations, and most are created automatically by cloud platforms and orchestration tools rather than deliberately by a person (Veza). At that ratio, "ask around" is not an ownership method.

A decision rule that holds up: the owner must be a person who can answer three questions without research. What does this account do? What breaks if it stops? When was it last changed? If they cannot answer the third, the row is listed, not owned.

Naming conventions do real audit work here. A prefix that encodes environment, system and function (for example prod-billing-reporting-reader) lets a reviewer spot a misconfiguration by eye before reading the purpose column, and it prevents collisions where two accounts in different regions share a name.

An orphaned service account is one with no accountable owner on record; a stale one is an enabled non-human identity with no legitimate usage inside a defined window. The two overlap but are not identical, and an account can be quiet in the directory while still accepted by a third-party system through cached credentials (Windows Active Directory). This is the part of the sheet a reviewer tests hardest, because it is where the risk sits.

Three presentation rules make orphans actionable.

First, never delete the row and never leave the owner blank. Move orphans to a dedicated tab with the same columns plus four more: date discovered, checks performed before calling it orphaned, intended disposition, and the date the disposition was carried out. A blank owner in the main tab reads as an oversight rather than a finding.

Second, do not purge on a short inactivity window. An account running a quarterly job looks dead at 30 days and is very much alive at 90, so the detection window has to reflect workload cadence; 90 to 180 days is the range suggested depending on cadence (Windows Active Directory).

Third, give every orphan a dated decision rather than a status of "unknown". Keep the vocabulary small: retained with a named owner assigned, retained under exception, disabled pending deletion, or deleted. Disabling before deleting is the safer order because it is reversible and produces a clean record of what breaks (Google Cloud IAM best practices).

A worked example. Suppose discovery finds 40 accounts with no sign-in for 120 days. Do not disable all 40 on one day. Accounts with a readable purpose tied to a live system get an owner assigned and 30 days of observation. Accounts with no readable purpose get disabled, with the team owning the surrounding infrastructure notified. Accounts with a valid purpose but no available owner go to the exception register with a decision date. You end up with three lists a reviewer can sample. One list of 40 with a status column is evidence only that you noticed.

An exception is a documented departure from your own standard, and it belongs in the inventory rather than a separate document. A reviewer reading a row that breaks the rules needs to see, in place, that the break was approved, by whom and until when. If the approval lives in a ticket thread, you will spend a day collecting it.

The exception fields that work: type (long-lived credential, shared credential, privilege beyond need, undocumented purpose), one-sentence justification, approver, approval date, expiry date and the compensating control. Expiry is the field teams forget. An exception without an expiry is a permanent waiver with a nicer name.

AI agent credentials are the fastest-growing category in that register, and they break the usual assumptions twice. The first is that the credential often belongs to a person's tool rather than to a system. When a developer connects an AI coding tool to internal systems through MCP servers, the resulting API keys are often generated directly from each service, stored locally and invisible to centralized identity infrastructure, so disabling the person's SSO account does not revoke them (Scalekit). The contractor version is worse: there is often no laptop to collect and the contract can end with a day's notice (Scalekit).

The second is that an agent acts on behalf of someone, so two identities need recording. A workable set of rules: give every agent its own identity separate from the user it serves, exchange the user's token for a new narrower one rather than passing it through, log both identities and the decision for every action, check authorization on every tool call, require out-of-band approval for irreversible or external actions, and make revocation instant and cascading, tested before you need it (WorkOS). Each rule assumes a place where "every agent" is listed. Your inventory can be that place: add an agent flag and a delegation column naming the human the agent acts for.

Token-based methods add a layer a password-based sheet misses. Provider documentation describes introspection and revocation endpoints, automatic rotation on expiry, and a default token lifetime that can be configured at creation (authentik). Teams often want shorter token lifetimes for service accounts than for human users and find that realm-wide settings apply to both, which is a constraint worth recording on the row rather than rediscovering at review (Stack Overflow).

Cadence is where an inventory becomes a control. Pick tiers by blast radius and exposure, write the tier into the sheet, and derive the next review due date from it so nobody has to remember.

Two adjustments matter in practice. An ownerless account moves to tier 1 regardless of its permissions, because the risk is the missing sponsor, not the size of the grant. And an account whose last-used date is older than two review cycles is a removal candidate rather than a renewal candidate, since renewal without evidence is the rubber-stamping auditors look for.

Rotation is a separate clock from review, and conflating them is a common mistake. Rotation shortens the life of a credential; review confirms the identity is still needed. Rotation at scale is genuinely hard: manual processes, fear of downtime and growing complexity all get in the way (Doppler). Automate where the platform allows it (managed identities, group managed service accounts, short-lived tokens) and record a rotation date only for the residue that needs a manual change. That residue is the honest exception list.

An inventory is stale the moment it is finished unless something writes to it continuously. The cheapest sustainable pattern is to generate the skeleton from systems of record, then add the human columns by attestation.

source systems                ->  skeleton rows
  identity provider           ->  identifier, owner, team, creation date
  cloud IAM / AD / K8s        ->  system, authentication method, privilege
  secret manager              ->  rotation date, secret location
  logs / activity export      ->  last used date, source of that date

human attestation             ->  purpose, review dates, exception status
quarterly for tier 1,        ->  next review due recalculated
semiannual for tier 2,
annual for tier 3

The last-used column should name its source, because a reviewer will ask whether it came from authentication logs, application logs or someone's memory. Writing "app logs, 03:00 UTC export" beside a timestamp turns a claim into evidence, the same way a confirmation letter turns a balance into evidence (GBQ).

Sample rather than read everything. Ten tier-1 rows with their purpose sentences and activity timestamps tell a reviewer more about your process than a full read of 900 rows. The PCAOB is moving toward risk-based, technology-aware procedures rather than one uniform approach (Rehmann), and your tiering is that idea applied to identities.

Treat the inventory as a living deliverable with a named maintainer, not a project. The tell is whether it has been updated since the last person left. A departing employee's API keys that were never in any registry are the classic gap, and the only defense is an offboarding line item that removes the person from the owner column and reassigns their rows (Scalekit). When a reviewer asks how you know the list is complete, the answer is a discovery method, a reconciliation date and a count of what discovery found that the sheet did not have.