in one lineA service account is any credential used by an application, script, or integration rather than a person; most go unreviewed.
the numbers
- 82:1machine identities per human one, nearly half privilegedCyberArk Identity Security Landscape, 2025
- 241 daysdays to identify and contain the average breachIBM Cost of a Data Breach, 2025
- 82%of intrusions are malware-free; attackers simply log inCrowdStrike Global Threat Report, 2026
1what it is
Service accounts are credentials used by software rather than people. An application authenticating to a database. An integration pulling data from an API. A scheduled script running overnight. An automation connecting two SaaS tools.
Each of these needs credentials to operate. Those credentials live somewhere, they have a permission level, and they were created by someone. In many environments, that's where the documentation ends.
Service accounts go by several names depending on the platform: service principals in Azure, service accounts in Google Workspace, technical users in various SaaS platforms. The unifying characteristic is that no human logs in using them interactively. They run in the background, and they're often invisible to any access review that focuses on human users.
2why it accumulates
Service accounts are created to solve immediate problems. A developer sets one up to connect two systems. An IT admin creates one for a monitoring tool. A contractor provisions one for an integration during a project.
At creation, the permissions are set to whatever is needed to make the thing work. Broad permissions are common because narrowing them takes time and testing. The principle of least privilege applies here too, but it's harder to apply when the goal is getting the integration running.
After creation, service accounts are rarely revisited. They don't trigger offboarding processes. They don't appear in HR records. They often outlive the projects that created them, the integrations they served, and in many cases, the people who knew they existed.
When a person who owned a service account leaves, the account often becomes genuinely ownerless. There's no one to update the credentials, no one to review the permissions, and no one to disable it when it's no longer needed.
3what it costs you
A service account with broad permissions and no owner is an unmonitored credential in your environment. If the credentials are exposed, through an accidental commit, a compromised system, or a misconfigured storage location, the access they carry is live until someone revokes it.
The response depends on someone knowing the account exists and what it can reach. In environments without a service account inventory, neither is guaranteed.
There's also the access review gap. Compliance frameworks that require periodic access reviews, including SOC 2, ISO 27001, and DORA, extend to non-human identities. An access review that covers only human users leaves service accounts outside the scope of any control. That's a gap that auditors find.
Overpermissioned service accounts are also a lateral movement path. A compromised application credential that holds admin-level access can reach far more than the original integration required.
what it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedCash App / Block, 2022howThe person logs back in from home, weeks after leaving.what leavescustomer lists and reportswho ends up with itthe former employee and whoever they work for next
- it happenedColonial Pipeline, 2021howThe forgotten account's password turns up in a breach dump.what leavesa working way into the networkwho ends up with ita ransomware crew
- it happenedCloudflare, 2023howA key or token set up for old work keeps working after everyone forgets it.what leavesinternal systems and documentswho ends up with itwhoever tries the key first
4what works
Nothing else is possible until an inventory exists, and it has to span more than the directory: service accounts from the IdP, the cloud platforms, the major SaaS applications, and every system where integrations are configured, with API keys and OAuth service credentials counted alongside named accounts. The population is usually larger than anyone expects, and the unknown portion is where the risk lives.
Ownership is the control that makes every other control workable. Each service account maps to a current employee who knows what it does, what it connects to, and who will act when it needs updating or disabling. Accounts that can't be assigned an owner are the highest-priority items on the entire list, because an unowned credential has nobody to rotate it, nobody to scope it, and nobody to notice when it should be retired.
Permission levels get compared against need rather than left at whatever made the integration work on day one. An account holding admin-level rights to serve an integration that reads one specific resource is a scope-reduction candidate. The same review surfaces the accounts whose projects ended: an integration that no longer runs justifies no credential at all, and those accounts get disabled.
The maintenance habit is rotation. Long-lived service credentials rotate on a documented schedule keyed to the sensitivity of the access, with high-privilege credentials cycling more often, so an exposed secret has a bounded useful life instead of an indefinite one.
on the record
your turn
what you can do about it
this week
List your service accounts with their owner and what each can reach.
Any account without an owner is the first to review.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →