Service accounts

what 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.

why 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.

what 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 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.