What is a service account and why is it risky?
By Identra · Updated
A service account is a non-human identity that applications, scripts, and infrastructure use to authenticate to other systems without a person at the keyboard. Service accounts are risky because they typically carry long-lived credentials, accumulate broad privileges, and outlive the people and projects that created them, leaving powerful access that no one owns or monitors.
Key numbers
- Machine identities outnumber human identities 82 to 1 in the average organization (CyberArk Identity Security Landscape, 2025)
- 31% of all users in audited environments are service accounts with high access privileges and low visibility (Silverfort Identity Underground Report, 2024)
- Only 20% of companies are highly confident they have visibility into every service account (Silverfort Identity Underground Report, 2024)
- Only 15% of organizations are highly confident in their ability to secure non-human identities (Cloud Security Alliance and Astrix Security, 2024)
What is a service account?
A service account is an account created for software rather than for a person. A backup job that logs into a database, a CI pipeline that pushes containers to a registry, a monitoring agent that scrapes metrics from every host: each authenticates with a service account. They exist in nearly every layer of the stack, from Active Directory service accounts and cloud IAM service principals to Kubernetes service accounts and database logins baked into application config.
Service accounts are one of the oldest forms of non-human identity, and in most enterprises they are still the most numerous. The Silverfort Identity Underground Report (2024), drawn from hundreds of live production environments, found that 31% of all users are actually service accounts with high access privileges and low visibility. They predate API keys, workload identities, and AI agents, but they share the same core problem: they authenticate and act without a human in the loop.
Why are service accounts risky?
The risk is not that service accounts exist. Automation requires them. The risk comes from how they are typically created, credentialed, and then forgotten. Three properties show up again and again.
- Long-lived: service account passwords and keys often go unrotated for years because no one knows what will break if they change. A credential that never expires gives an attacker a persistent foothold.
- Overprivileged: under deadline pressure, engineers grant broad roles like domain admin or a wildcard cloud policy to make an integration work, then never scope it down. The account keeps every permission it was ever given.
- Unowned: the engineer who created the account changes teams or leaves the company. The account keeps running, but no human can answer what it does, what it should access, or whether it is still needed.
- Exempt from human controls: service accounts usually cannot complete MFA, are excluded from conditional access policies, and rarely appear in access reviews, so the guardrails built for people simply do not apply.
How do attackers abuse service accounts?
Attackers prize service accounts precisely because of those properties. In Active Directory environments, Kerberoasting lets an attacker request a service ticket for a service account and crack its password offline, no alerts required. In the cloud, a service account key committed to a repository or left in a config file grants direct API access with whatever privileges the account holds. Once inside, a compromised service account is ideal for lateral movement: its activity looks like the machine-to-machine traffic it has always generated, so anomalous behavior blends into baseline noise. The confidence gap is stark. Only 20% of companies are highly confident they have visibility into every service account (Silverfort, 2024), and only 15% of organizations are highly confident in their ability to secure non-human identities broadly (Cloud Security Alliance and Astrix Security, 2024).
Discovery and ownership binding
You cannot secure accounts you cannot see, so the first control is discovery: enumerating every service account across directories, cloud providers, databases, and CI systems, then mapping what each one actually does. Authentication logs matter more than inventory lists here. The question is not just which accounts exist, but which sources they authenticate from, which destinations they touch, and which of their granted privileges they actually use. That behavioral map is what separates a live, load-bearing account from a dormant one that should be removed.
The second control is ownership binding: attaching every service account to a named human owner and a business purpose, and keeping that binding current as people leave and teams reorganize. An account with an owner can be reviewed, scoped down, and eventually retired. An account without one becomes untouchable, because no one is confident enough to change it. Unowned accounts are where risk compounds quietly for years.
Rotation vs. deprovisioning
Teams often treat credential rotation as the finish line for service account hygiene. Rotation matters, but it answers a narrower question than deprovisioning does, and the two are not interchangeable.
A rotated credential on an overprivileged, unowned account is still an overprivileged, unowned account. Mature programs use rotation as ongoing hygiene for accounts that have earned the right to exist, and deprovisioning as the default for accounts that cannot demonstrate current usage and a current owner. The forcing function for both is the same: continuous visibility into what each account is actually doing.
| Practice | What it fixes | What it leaves in place |
|---|---|---|
| Credential rotation | Shrinks the window in which a stolen password or key remains usable | The account itself, its accumulated privileges, and every consumer that depends on it |
| Deprovisioning | Removes dormant accounts and their standing access entirely | Nothing, but it requires usage evidence and a confident owner to pull the trigger |
How Identra thinks about it
Service account risk, on our reading, is fundamentally a runtime problem. Inventories and rotation schedules describe what an account is allowed to do; only live authentication behavior shows what it actually does, and the gap between the two is where attackers operate. Watching service accounts at runtime, alongside the human, workload, and AI-agent identities they interact with, is what makes ownership binding accurate, makes deprovisioning safe, and makes a compromised account look different from a healthy one while the session is still open.
Go deeper: The Non-Human Majority
Frequently asked questions
What is the difference between a service account and a user account?
A user account belongs to a person who logs in interactively, completes MFA, and gets offboarded when they leave. A service account belongs to software: a backup job, a pipeline, a monitoring agent. It authenticates without a human present, usually cannot complete MFA, has no natural offboarding date, and often outlives the engineer and project that created it.
What is Kerberoasting?
Kerberoasting is an Active Directory attack in which any authenticated user requests a Kerberos service ticket for a service account, then cracks the ticket offline to recover the account's password. It generates no failed logins and few alerts, and it works best against service accounts with old, human-chosen passwords, which is exactly what most environments still have.
How often should service account credentials be rotated?
Common guidance is at least every 90 days, and immediately after any suspected exposure or when a person with knowledge of the credential leaves. But rotation alone is not the goal. A rotated credential on an overprivileged, unowned account is still a risk, so pair rotation with usage review, least-privilege scoping, and deprovisioning of accounts that no longer earn their existence.
How do you find all the service accounts in an environment?
Start from authentication logs rather than inventory lists. Enumerate accounts across Active Directory, cloud IAM, databases, Kubernetes, and CI systems, then map which sources each account authenticates from, which destinations it touches, and which granted privileges it actually uses. That behavioral map separates live, load-bearing accounts from dormant ones that should be retired, and it is the evidence ownership binding depends on.