Service Accounts Outnumber Staff 82 to 1. Nobody Owns Them.

In assessments, one question reliably stops a room:

“Who owns service account SA-prod-04?”

Silence. Then someone offers “maybe infrastructure?” Nobody writes their name down. The account keeps its administrative rights, and it will still have them next year.

Why inventories rot

Spreadsheets go stale before they are finished. A point-in-time list is out of date before the project that produced it closes, because accounts are created faster than reviews run.

Discovery without consequence decays. Tooling that emails a report to a distribution list produces awareness, not governance. Nothing in that loop deletes an account.

Ownership reconstructed is ownership refused. When you work out who owns something after the fact, the creator has left, the purpose is undocumented, and nobody will accept accountability for deleting it. So it survives — with whatever rights it was born with.

Discovery-first versus ownership-first

What it actually takes

The trap is trying to govern all of them at once. With one security engineer, this order works.

1. 1

   Scope to what can reach production

   3–5 days

   Not every machine account matters equally. Start with those holding write access to production, payment paths, or systems with regulated data. This is usually a tenth of the population and most of the risk.

2. 2

   Assign an owner to each one, by name

   2–3 weeks

   A person, not a team mailbox. Teams reorganize; people can be asked a question. Expect this to be the slow part, because it is the part that requires conversations rather than tooling.

3. 3

   Make an owner mandatory at creation

   1–2 weeks

   Enforce it wherever accounts are actually created — the cloud console, the secrets manager, the pipeline. This is the step that stops the problem regenerating, and skipping it means repeating steps one and two next year.

4. 4

   Attach an expiry to every credential

   2–4 weeks

   Default lifetimes with automatic rotation. An account that must live forever becomes a documented exception with a named approver, rather than the norm.

5. 5

   Put owner departure into the leaver process

   1 week

   When someone leaves, their machine accounts should surface for reassignment alongside their own access. Without this the model decays quietly, one resignation at a time.

Why this reaches compliance, not just security

Access certification generally assumes a human reviewer confirming a human’s access. Machine accounts fall outside that, which is precisely why they persist — and increasingly why they are sampled.

For SOC 2, an auditor asking how access is reviewed will not accept a scope that silently excludes the majority of credentials. Under HIPAA, a service account reaching patient records is subject to the same access control standard as a clinician. In banking, an unowned account with production rights is a segregation-of-duties question waiting to be asked.

The useful framing is not “we should inventory our service accounts.” It is: every credential has an owner, a purpose and an expiry, or it does not get created.

Where vaultIAM fits

Machine identity is one of the ten categories we score, and it carries heavy weight outside banking because that population is where under-resourced teams are furthest behind.

We enumerate machine accounts read-only through each platform’s own admin interface, identify which can reach production and regulated data, and give you the ownership gaps ranked by what closing each one actually reduces.