Key takeaway: Human accounts have joiners-movers-leavers processes. Service accounts typically have none, so they accumulate permanently with permissions nobody reviews.
Why They Accumulate
Every integration, CI pipeline, monitoring agent and scheduled job needs an identity. Creating one takes minutes and requires no approval in most environments.
Nothing removes them. The project ends, the integration is replaced, the team reorganises — and the account persists with valid credentials and whatever permissions it accumulated. Ratios of ten to fifty non-human identities per employee are common, and most organisations cannot enumerate them.
The Properties That Make Them Attractive
| Characteristic | Human account | Service account |
|---|---|---|
| MFA | Usually enforced | Rarely possible |
| Credential rotation | Policy-driven | Often never |
| Anomalous use is noticeable | Yes | Rarely monitored |
| Offboarding | Defined process | Usually none |
| Permission scope | Role-based | Frequently over-broad |
| Named owner | Yes | Often unknown |
The combination is exactly what an attacker wants: a credential that does not expire, has no second factor, holds significant privilege, and whose use is not monitored because nobody knows what normal looks like.
The ownership gap is what blocks remediation. When a security team finds a service account with excessive permissions and no recent activity, the safe action is disabling it — and nobody will approve that without knowing what breaks. So it stays.
Establishing Control
Require an owner at creation. A service account without a named human owner and a stated purpose should not be creatable. This is the single change that makes everything else possible.
Eliminate long-lived credentials where the platform allows. Workload identity federation lets a CI job or a workload exchange a platform-issued token for short-lived credentials. A leaked fifteen-minute token is an incident that resolves itself.
Set expiry on what remains. Credentials that must be static should carry an expiry date that forces rotation. Rotation that depends on someone remembering does not happen.
Report on activity. An account unused for ninety days is a candidate for removal. An account whose usage pattern changes sharply is a candidate for investigation.
Reducing Permissions Safely
Service accounts are usually over-permissioned for the same reason human roles are — someone widened them during an incident and never narrowed them.
The advantage with service accounts is that their behaviour is far more predictable than a human’s. A pipeline does the same handful of operations every run, which means access logs over ninety days provide a nearly complete picture of what it needs.
Generating a policy from that record produces something tight and low-risk to apply, with the caveat that infrequent paths — quarterly jobs, disaster recovery — need explicit consideration.
The Bottom Line
Require a named owner and purpose for every service account at creation, replace static credentials with short-lived federated tokens wherever the platform supports it, expire what remains, and report on dormant accounts so removal becomes routine rather than risky.
