Service accounts need an offboarding process too

Machine identities are no longer background plumbing. Service accounts, API keys, OAuth clients, CI/CD tokens, certificates, and managed identities now carry a large part of enterprise access.

CyberArk’s 2025 identity research put the ratio at 82 machine identities for every human identity. Whether the exact ratio inside a given company is lower or higher, the direction is obvious: cloud and automation create identities faster than most governance programs can review them.

The weak point is lifecycle management. Human identities usually have a joiner-mover-leaver process. Machine identities often do not. A project ends, a vendor integration changes, an engineer leaves, a pipeline is replaced, and the credential continues to exist because nothing triggered review.

You can see this quickly in Azure Entra ID app registrations, cloud IAM roles, secrets managers, and CI/CD variables. Look for unknown owners, stale last-used dates, long-lived secrets, broad permissions, and credentials created for one-time migrations.

Three controls move the needle:

Ownership as a requirement. Every service account should have a named human owner. No owner means the account is disabled, rotated, or moved into exception review.

Expiry by default. Long-lived credentials should be rare. Expiry and rotation force teams to prove the identity still has a business purpose.

Quarterly privilege reviews. Same idea as human privileged access reviews. If a service account has not used a permission in 90 days, remove it or document why it remains.

Attackers do not care whether access came from a person or a machine. The control surface is identity, and machine identity governance has to become as routine as user access review.