How should security teams estimate non-human identity sprawl across cloud, SaaS, and on-prem environments?

Why This Matters for Security Teams

NHI sprawl is rarely concentrated in one platform. Service accounts in on-prem directories, OAuth apps in SaaS, workload identities in cloud, and API keys embedded in CI/CD all add up to an identity estate that is much larger than most teams expect. The practical risk is not just count, but unmanaged growth: stale credentials, duplicated privileges, and identities that no owner can explain.

Industry data from the Ultimate Guide to NHIs shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts. That gap matters because estimation is the first control step: if teams cannot approximate where NHIs accumulate, they cannot prioritise discovery, rotation, or offboarding. NIST’s Security and Privacy Controls expects inventory and access control discipline, but NHI sprawl often grows faster than periodic audits can catch.

In practice, many security teams discover the scale of sprawl only after a breach, an audit request, or a failed offboarding effort has already exposed how fragmented the identity estate has become.

How It Works in Practice

A defensible estimate starts with high-level inputs, then turns those inputs into environment-specific multipliers. Headcount is a useful anchor, but it should be adjusted for the number of engineering teams, business units, and external integrations. A SaaS-heavy organisation will usually have more OAuth apps and delegated tokens, while a cloud-native engineering stack tends to create more workload identities, CI/CD secrets, and automation accounts. On-prem environments often hide service accounts inside legacy applications and directory services, so they require separate discovery assumptions.

The most reliable approach is to estimate by identity class, not by a single enterprise total. For example:

• Human-to-machine ratios by team type: engineering, data, IT operations, and business apps.
• Cloud account and subscription count: each environment tends to create its own service principals, roles, and keys.
• SaaS application count: every connected app can introduce tokens, webhooks, and delegated access.
• CI/CD and infrastructure automation: pipelines, runners, and deployment tools often hold the highest secret density.
• Legacy on-prem systems: service accounts, scheduled tasks, and shared credentials often require manual validation.

This is where research and standards should inform the baseline. The NHI and Secrets Risk Report highlights that NHIs now outnumber human identities by 144:1 in some enterprise environments, driven by AI agents, CI/CD automation, and third-party integrations. That does not mean every organisation should assume that ratio, but it does show how quickly sprawl can scale once automation becomes the default. For control design, NIST guidance on account management and least privilege remains relevant, especially when combined with runtime inventory from cloud APIs, SaaS admin consoles, secret scanners, and directory exports.

Good estimation also includes confidence scoring. Teams should label findings as observed, inferred, or likely, then assign a review cadence for each segment. That creates a baseline that is honest about uncertainty while still pointing to the highest-risk concentrations, such as orphaned service accounts or secrets outside vaults. These controls tend to break down when identities are created by shadow IT, local scripts, or unmanaged third-party integrations because there is no single system of record.

Common Variations and Edge Cases

Tighter estimation often increases collection overhead, requiring organisations to balance speed against completeness. That tradeoff matters because some environments can be sampled effectively, while others need direct enumeration to avoid false confidence.

Current guidance suggests treating SaaS, cloud, and on-prem as separate discovery domains rather than forcing one universal multiplier. In regulated industries, procurement records, CMDB data, and IAM exports may be enough to produce a stable baseline. In fast-moving engineering organisations, best practice is evolving toward continuous discovery because the identity estate changes too quickly for quarterly reviews to remain accurate.

Edge cases often include acquired companies, contractor-heavy operations, and multi-region platforms. Mergers can double NHI sprawl overnight, while contractors frequently introduce short-lived access paths that disappear from central ownership records. Multi-cloud and hybrid deployments also create duplicated service identities across environments, which can make a simple count misleading unless duplicates are grouped by function and trust boundary. For deeper patterns, NHIMG’s 52 NHI Breaches Analysis and Top 10 NHI Issues show how sprawl becomes operational risk when ownership, rotation, and offboarding lag behind growth. The practical objective is not a perfect count on day one, but a repeatable method that surfaces where identities multiply fastest and where discovery effort will pay off first.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities in cloud environments?
• How should security teams govern non-human access to engineering environments in cloud and Git platforms?
• How should security teams control token sprawl across cloud and SaaS environments?
• How should security teams reduce identity sprawl across hybrid and multi-cloud environments?