Service Accounts, Machine Identity and Secret Sprawl

Ask an organisation how many employees it has and you get an exact number. Ask how many service accounts, API keys, workload identities and CI tokens it has, and you get a shrug. Machine identities outnumber human ones by a large multiple in most environments — and unlike humans, they never resign, never trigger an offboarding, and often hold far more privilege than any single person. This is the identity perimeter that grew while everyone was busy rolling out MFA for people.

A service account is an identity for software: a process, a script, a pipeline, a microservice authenticating to another. The problem is not that they exist — machines must authenticate — it is how their credentials are handled. A human secret is unlocked by a biometric and rotated on a schedule. A machine secret is frequently a long-lived static string sitting in a config file, an environment variable, a Kubernetes secret, or worst of all, hard-coded in a repository. It rarely rotates, and often no one alive knows which running system depends on it, so no one dares change it. The fear of breaking an unknown consumer is what keeps a five-year-old key alive — and that same fear is why the key is never scoped down either.

Secret sprawl, defined

Secret sprawl is the natural end state: the same credential copied across a dozen locations, of unknown age and ownership, with no inventory of where it lives or what it can do. It is why secret-scanning tools reliably find live keys in public and private repositories — not because developers are careless in the moment, but because a static secret, once created, tends to be pasted wherever it is convenient and then forgotten. Each copy is an independent point of exposure, and the credential's blast radius is whatever the account was over-permissioned to do.

Getting off static secrets

• Prefer identity over secrets. Where the platform allows it, use workload identity federation — a workload proves what it is and receives a short-lived token, with no long-lived credential to leak. This is the single biggest reduction in machine-credential risk available.
• If you must hold a secret, broker and rotate it. Store secrets in a managed vault that issues short-lived, dynamic credentials on demand rather than distributing a static string that never changes.
• Scope machine identities as tightly as humans, or tighter. A pipeline that deploys one service does not need account-wide admin. Over-permissioned automation is the most common lateral-movement highway.
• Scan continuously for exposed secrets. Secret detection in repositories, images and logs is table stakes — and a hit means rotate, not just delete the commit, because the value is already out.
• Give every machine identity an owner and an expiry. An orphaned service account with no owner is a permanent, unwatched credential — exactly the thing to inventory and retire.

The account that outlives its purpose

The machine-identity equivalent of the leaver problem is the account whose original job is long gone but whose credential still works. A migration finished; the integration was retired; the vendor was replaced — and the service account lingers, valid and privileged, because nothing forced its removal. Humans have HR to trigger offboarding. Machines have nothing unless you build it. Every machine identity needs a lifecycle too: created deliberately, owned explicitly, reviewed periodically, and revoked when its purpose ends.

You cannot rotate, scope or retire a machine identity you have never counted — and the ones that matter most are precisely the ones no inventory contains. Machine identity is the clearest case of the rule the whole field runs on: you can't defend what you haven't discovered.