Service Account Sprawl, the Risks and How to Measure Them
Introduction
Six service account sprawl risks matter most: orphaned accounts, dormant accounts, excess privilege, shared credentials, nested impersonation chains and third-party integrations with standing tokens. You measure sprawl with five metrics: accounts by system, owner coverage, dormancy, privileged share and machine identities per employee, trended over time.
A risk list alone is not enough. Your board needs a number that moves, and your team needs to know which accounts to fix first.
Oak, the AI-native identity operating system, governs every identity, human, machine, and AI agent, on one live graph. It continuously correlates what every identity can access with what it actually uses, then routes risk-prioritized decisions to the right reviewers.
Key takeaways
- Six risks drive sprawl, including impersonation chains and standing tokens.
- Five metrics with fixed denominators turn sprawl into a board-ready trend.
- A baseline taken before full inventory mistakes discovery for growth.
- Oak rolls service account sprawl findings into one identity risk score.
- Privileged and orphaned accounts come first, then the largest blast radius.
What service account sprawl is and why it happens
Service account sprawl is the gap between the service accounts that exist in your environment and the ones anyone governs.
Teams typically create a service account for each integration, pipeline and application, then rarely retire it. When the creator leaves, the account stays, with its credentials and access intact.
Many accounts never pass through a provisioning workflow. Engineers often create them directly in cloud and SaaS consoles, so they start life out of band.
An out-of-band entitlement is access granted inside the application itself, which never reaches your governance model.
Your IGA typically sees only the identities it can tie to a person. A service account with no human attribute falls outside its model, so no campaign ever includes it.
The 2026 Identity Security Landscape, a survey of 2,930 security decision-makers, found 109 machine identities per human.
Already running an IGA? Oak connects to the IGA you already run and covers what it cannot reach, starting with the service accounts outside its campaigns.
Six service account sprawl risks that matter
Each risk below has its own mechanism, and most map to a metric later in this guide.
Credentials sit at the center of most of them. The Verizon 2026 DBIR found credential abuse appears somewhere in the attack chain of 39% of breaches.
Orphaned accounts
An orphaned service account has no named owner. Nobody can approve a change to it, review its access or decide to retire it.
Ownership comes first. Until an account resolves to a named human or team, it sits outside your certification process.
Dormant accounts
A dormant service account holds valid credentials but shows no recent use. Its access serves no business need, yet an attacker can still use it.
Declared access cannot reveal dormancy. You need usage data correlated with each entitlement to see which access is live and which is idle.
Excess privilege
Service accounts are often granted admin at creation so the integration works, then never right-sized. The 2026 Identity Security Landscape found 40% of machine identities have access to organizational data.
Map each permission to a privilege level (admin, write or read), then weight it by resource sensitivity. Admin on a payroll database outranks admin on a test environment.
Shared credentials
Teams often share one secret across several applications or people. No action can then be attributed to the person, script or agent that triggered it.
Rotation becomes risky because nobody knows what will break. So the secret never rotates, and its exposure grows with every new consumer.
Nested impersonation chains
Account A can assume account B, which can assume account C. The entitlements declared on account A understate what it can actually reach.
Transitive reach is what an identity reaches indirectly: roles it can assume, secrets it can read and accounts it can reset.
Third-party integrations with standing tokens
OAuth apps and vendor integrations often hold long-lived tokens with no expiry. The token keeps working long after the project that justified it ends.
Third parties are a growing route in. The Verizon 2026 DBIR found a third party was involved in 48% of breaches, a 60% increase on the previous year.
Inventory each token a vendor holds, with its scope and last use. A standing token with write access and no recent activity is a priority finding.
Blast radius, the measure that sets priority
Effective access is what an identity can actually do once groups, roles and inheritance resolve. Blast radius extends effective access with what an identity can reach through other identities, weighted by how sensitive those resources are.
Treat blast radius as a proactive metric: compute it before a breach and fix the largest radius first. Oak surfaces nested impersonation chains with their full blast radius.
How to measure service account sprawl
Measurement starts with a complete inventory, and that is where programs commonly undercount. Service accounts typically hide in on-prem and homegrown systems that your cloud consoles do not reach.
Each share below divides by a denominator you freeze at baseline. A change in the number then reflects a change in risk rather than a change in scope.
The five metrics
Together they show where sprawl concentrates and where ownership and privilege fall short.
The 90-day window and the privileged definition are suggested starting points, not an industry standard. Set each one for your estate, then hold it fixed.
Read the metrics as a set. A falling dormant share alongside a rising privileged share means you cleaned up the easy accounts and left the dangerous ones.
Owner coverage is the metric to watch closest. A low owner share caps progress on the other four, because unowned accounts have nobody to approve a fix.
Baseline and trend
Take the baseline only after the inventory covers each system you run. Otherwise the first trend line shows growth that is really discovery.
Freeze the denominators at baseline and report newly discovered accounts as a separate line. Better discovery should never look like worse sprawl.
Trend each metric on a cadence you set, such as monthly or once per review cycle, and report direction rather than raw counts. A falling orphaned share is easier for a board to read than a table of totals.
Align the cycle to your audit obligations. PCI DSS v4.0 Requirement 7.2.4 mandates reviewing user accounts and access privileges at least every six months.
Then give the board one number above the five. Oak correlates access with actual usage, and its findings roll up into an identity risk score for the board.
Report that score as the headline, with your five metrics as the program detail beneath it.
Reducing service account sprawl in risk order
Fix sprawl in the order that removes the most risk per action.
- Privileged and orphaned accounts, because unowned admin access has nobody to stop it.
- Nested impersonation chains, starting with the largest blast radius.
- Third-party integrations with standing tokens, revoked or scoped to current need.
- Dormant accounts, disabled once usage data confirms no business need.
- Shared credentials, split into one credential per consumer so rotation is safe.
- Remaining accounts, each assigned a named owner at creation.
Swap standing privilege for just-in-time access wherever an account needs admin only occasionally. Standing privilege reduction shrinks blast radius while the account keeps the access it needs when it runs.
Then make ownership permanent. Every identity needs certifying: service accounts, contractors, RPA bots, and AI agents, each tied to an accountable human owner.
The same discipline applies when governing machine and agent identities: classify each one, resolve an owner, and review it alongside your people.
Large estates often need help with the first full inventory. Oak offers a free white-glove implementation program for qualifying large enterprises.
Conclusion
Service account sprawl risks become manageable once you can count them. Five metrics with fixed denominators give you a trend line your board can read.
For the CISO, that trend line answers the board's identity question with evidence. For the IAM lead, it shows which systems and owners to fix next.
Leaving sprawl unmeasured has a price. The IBM Cost of a Data Breach Report 2026 puts the global average breach at a record $4.99 million, up 12%.
Oak remediates from the source the moment an identity deviates. Your metrics then move because the underlying risk moved.
Get a demo to measure service account sprawl across your own estate on one live graph.
Frequently asked questions
What is the difference between a zombie account and an orphaned account in service account sprawl?
A zombie account in service account sprawl is orphaned and dormant at once: no owner, no recent use, yet valid credentials. An orphaned account may still run a live integration, so disabling it can break production. Oak surfaces both orphaned and dormant accounts, so you can disable zombies first and resolve an owner for active orphans before changing anything.
Do AI agents add to service account sprawl?
Yes, AI agents add to service account sprawl, because many run on service accounts, OAuth apps or their builder's credentials. An agent on its builder's credentials reaches everything the builder can. Oak governs agents as their own identity type, mapping an accountable human owner and who each agent acts on behalf of. Each agent runs continuous reviews driven by its own risk profile, not a fixed calendar.
How often should you review service accounts to control service account sprawl?
Review service accounts at least as often as your audit framework requires, then add event triggers so sprawl cannot build between cycles. Joiner-mover-leaver (JML) events trigger event-driven micro-certifications. A creator's departure then prompts review of the accounts they owned. Oak gives reviewers context on every row, including last use, peer comparison and sensitivity, so each decision reduces risk instead of rubber-stamping access.
How do you govern service accounts created before your service account sprawl program?
You govern service accounts created before a sprawl program by working backward from activity, because their creators and documentation are often gone. Attribute each action to its trigger, whether a person, script or agent; the most frequent trigger is usually the best owner candidate. Oak classifies non-human identities into one taxonomy, resolves a named human or team owner and attributes every action to its trigger.
What should you show the board first about service account sprawl risks?
Show the board one identity risk score for service account sprawl risks first, then the trend behind it. A single direction of travel is easier to govern than five raw metrics. Oak rolls its findings into an identity risk score for the board. Pair it with your largest blast radius and the third-party integrations still holding standing tokens.
Discover related posts
