Service Account Sprawl: The NHI Problem Auditors Miss

Here's a number that should worry you: at a typical SaaS company with 100 employees, there are usually 300 to 1,000 service accounts in active use.

Not per department. In total. Some organizations have ratios as high as 10 service accounts for every human employee.

Most compliance auditors won't ask about any of them.

The Audit Framework Gap

When an auditor walks you through SOC2 access reviews, they're looking for one thing: evidence that you review who has access to what. The requirement is unambiguous — all user access must be reviewed quarterly.

But "user" in the audit world means one specific thing: a person. A human. Someone with a name, an email address, an employee record.

Service accounts don't fit that shape. Neither do API keys. Neither do AI agents. They're credentials, not users. They sit in a category that audit frameworks acknowledge exists but don't explicitly govern.

The result: your audit evidence shows you reviewed access. It doesn't show you reviewed 70% of the credentials that actually exist.

Why Service Accounts Accumulate

A service account gets created for a reason. Maybe a new SaaS integration needs to authenticate with your API. Maybe your CI/CD pipeline needs to push code. Maybe a third-party log aggregator needs to read CloudWatch.

The account gets provisioned, granted the permissions needed to make it work, added to a spreadsheet or ticketing system somewhere, and then... nobody revisits it.

Here's why:

No lifecycle management. When the integration is complete, the service account stays active. When the SaaS tool gets replaced, the old account stays active. When the engineer who created it leaves, the account stays active. There's no mechanism that says "this account has been unused for six months — investigate."

No deprecation timeline. Human access has a natural end date — someone leaves, their access gets revoked. Service accounts have no equivalent. A Jenkins credential created for a one-time migration in 2021 is probably still valid today.

No inventory discipline. Creating a service account requires (usually) one person and one command. Removing it requires coordinating across teams — the person who owns the system, the person who owns the credential, whoever maintains the integration. It's asynchronous friction. Most teams skip it.

Growing integration surface. Every new SaaS tool adds API keys. Every new microservice adds service accounts. Every new AI feature adds agent credentials. The surface grows constantly, and there's no automatic cleanup. You're in a compounding deficit.

What Auditors Actually See

During a SOC2 audit, your compliance team prepares a worksheet: "All active user accounts and their access levels, reviewed quarterly."

That worksheet lists:

• 87 human employees
• 12 of them have privileged access
• 4 onboarded this quarter, 2 offboarded
• A sign-off from their managers that access is still appropriate

The auditor glances at it, checkmarks the box, and moves on. Access review control is in place.

What the worksheet doesn't show:

• 342 service accounts in AWS
• 156 API keys in your SaaS ecosystem
• 28 CI/CD credentials across multiple pipelines
• An unknown number of agent credentials (if you're using AI for internal operations)
• Which of these accounts still have a business reason to exist
• How many were last used six months ago
• How many have overprivileged permissions that were granted for expedience and never trimmed

The audit passes. The control is documented. And the real access surface — the one where most of your actual risk lives — remains invisible.

The Consequences Get Real

This isn't just a compliance theater problem. Service account sprawl creates actual security and operational risk:

Lateral movement vectors. A compromised service account in your CI/CD pipeline has access to production systems. A forgotten API key from a defunct integration gives an attacker a foothold in your AWS account. An overprivileged agent credential can query your database.

Shared credentials. Multiple engineers know a service account password because it was easier than provisioning individual ones. When one of those engineers leaves, the password is still known to multiple people. You can't rotate it without coordinating across teams and downtime.

Forgotten owners. The engineer who created a service account left three years ago. Nobody knows what it's for. It still has write access to your production database. You can't decommission it because you don't know what depends on it. You can't rotate it because the rotation might break something.

Compliance liability. Your audit evidence claims you reviewed access. But you reviewed 20% of the credentials that actually exist. An auditor who digs deeper, or a regulator who follows up, or an incident response investigation that finds the forgotten service account — those scenarios surface the gap in your controls.

Alert fatigue. When you have 500 service accounts and one shows unusual activity, how do you know if it's a security event or normal behavior? Without baselines and without knowing what each account should be doing, every alert is a dead end.

The Compounding Problem

The service account sprawl problem doesn't stay static. It compounds:

• Every new integration adds accounts
• Every cloud migration copies old accounts alongside new ones
• Every team standardizes on a slightly different way of managing them
• Every forgotten account stays active until it causes a problem
• Every audit cycle documents that you reviewed access, while the actual surface grows

In five years, a company that started with 100 service accounts might have 800. Most organizations have no idea what the actual number is.

What NHI Governance Actually Looks Like

The answer isn't to shoehorn service accounts into human access review workflows. It's to govern them separately — with automation, continuous visibility, and policy enforcement:

Continuous discovery. Instead of a quarterly inventory, enumerate all service accounts, API keys, and agent credentials constantly. When a new account appears, flag it. When one goes unused for 90 days, surface it for review.

Ownership tracking. Every service account has an owner — the system it authenticates with, or the team that maintains the integration, or the application that runs under it. That relationship gets documented and tracked. When ownership changes, it gets updated.

Permission audit. For every service account, verify that its actual permissions match what it needs. Overprivileged accounts get flagged. Service accounts with admin-level access get high-priority review.

Credential rotation enforcement. API keys and passwords that haven't been rotated in 90 days get flagged. For supported integrations, rotation can be automated. For others, the owning team gets a deadline.

Usage baseline. For each service account, track what it actually does. An account that normally makes 50 API calls a day is normal; one that suddenly makes 10,000 is an anomaly. Usage data informs security decisions and lifecycle management.

Lifecycle integration. When a system gets decommissioned, its service accounts get revoked. When an integration is replaced, the old credentials get cleaned up. Identity lifecycle follows workload lifecycle.

This is how you make the 300–1,000 service accounts visible, manageable, and compliant.

How This Fits Into Your Audit Story

Your SOC2 audit requires documented access reviews. Vigil makes that documentation real. Instead of a spreadsheet that shows you reviewed 87 human accounts, you document that you reviewed:

• 87 human accounts with quarterly manager certification
• 342 service accounts with automated permission audits
• 156 API keys with rotation enforcement
• Every credential tagged with last-used dates and ownership

You're not just documenting controls. You're enforcing them. The access review isn't a spreadsheet snapshot three weeks old — it's the actual state of your environment, continuously verified.

Auditors see the full picture. Risk is visible. Compliance is defensible.

Related Reading

Service account sprawl is part of the broader non-human identity governance story. If you haven't already, start with Non-Human Identities: The Access Governance Blind Spot — it covers the full spectrum of machine identities and why governance platforms built for human workflows fail them. For the compliance angle specifically, Automated Access Reviews: Why SOC2 Teams Still Use Spreadsheets walks through how automation replaces the quarterly spreadsheet nightmare.

And if you're wondering what happens when these service accounts interact with your actual environment, Why AI Agents Need Access Governance covers what happens when autonomous workloads add another layer to the sprawl.

Ready to see your full service account inventory and govern it continuously? Book a demo with Vigil to see what you're actually running — human identities, service accounts, API keys, and agents — all in one view.

Evaluating NHI governance vendors? Enterprise tools like Astrix/Cisco, Oasis, and Veza/ServiceNow require months and $50K+. See how Vigil compares — Vigil vs Enterprise NHI Tools.