Count by identity type, not by headcount alone. A practical model separates human users, service accounts, workload identities, and any automated principals that can request access or trigger policy decisions. That approach gives you a truer view of audit load, entitlement volume, and operational support demand than a user-only metric can provide.
Why This Matters for Security Teams
Identity counts drive more than license planning. They shape audit scope, access review volume, incident response paths, and the amount of credential hygiene work required to keep a system stable. When human users and machines share the same platform, a user-only count hides the real operational burden because service accounts, API keys, workload identities, and automation principals often outnumber people by a wide margin. NHI Mgmt Group notes in the Ultimate Guide to NHIs that NHIs outnumber human identities by 25x to 50x in modern enterprises.
That matters because machine identities behave differently from users. They do not log in on a schedule, they can be embedded in code and pipelines, and they can proliferate across environments without the visibility that normal joiner-mover-leaver processes provide. Guidance from the OWASP Non-Human Identity Top 10 treats unmanaged machine identity sprawl as a distinct risk category, not a subset of workforce IAM. In practice, many security teams discover the scale gap only after access reviews, secret rotation, or an incident has already exposed how many machine principals were never counted at all.
How It Works in Practice
The practical model is to count identities by category and purpose, then aggregate those counts into one governance view. A useful breakdown is:
- Human identities: employees, contractors, partners, and admins.
- Service accounts: non-interactive accounts used by applications or infrastructure.
- Workload identities: cryptographic identities for services, pods, jobs, and agents.
- Automation principals: scripts, CI/CD runners, bots, and scheduled tasks that can request access.
That approach lets teams measure entitlement volume, credential lifecycle work, and review scope separately for each identity type. For example, a single application may represent one user-facing system but contain dozens of machine principals across dev, test, and production. If those principals authenticate with long-lived secrets, they also create rotation, offboarding, and blast-radius problems that a seat-based count will never show.
Current best practice is to pair the count with metadata: owner, system, environment, authentication method, last rotation date, and whether the identity can trigger policy decisions or only consume resources. NHI Mgmt Group’s Key Challenges and Risks research highlights how poor visibility and excess privilege are common failure modes. Implementation guidance from OWASP Non-Human Identity Top 10 and NIST Zero Trust Architecture both support the same operational idea: count what can actually authenticate, request, or act, not just what appears on the HR roster.
That model usually becomes the source of truth for entitlement reviews, secrets inventory, and ownership reporting. Teams can then compare human to non-human ratios, track growth by environment, and isolate identities that never go through standard offboarding. These controls tend to break down in environments with unmanaged scripts, shadow CI/CD pipelines, or vendor-managed integrations because the identity inventory is incomplete before governance even begins.
Common Variations and Edge Cases
Tighter identity counting often increases inventory overhead, requiring organisations to balance measurement accuracy against the cost of maintaining it. The most common tradeoff is between simplicity and fidelity: a single “active identity” metric is easy to report, but it obscures operational risk; a segmented model is more accurate, but only if ownership and lifecycle data stay current.
There is no universal standard for this yet, so teams usually adapt the count to the decision being made. For licensing, headcount may still matter. For security governance, machine identities should be counted separately because they create different control obligations. This becomes especially important in shared platforms where one application account fronts many downstream services, or where one human can provision hundreds of ephemeral workload identities through automation.
Some organisations also count only identities that can authenticate directly, while others include principals that can indirectly trigger access decisions, such as orchestration bots or policy agents. The latter is often the safer choice for risk reporting, but it must be documented clearly to avoid double counting. For a broader understanding of how machine identity exposure translates into real compromise, the 52 NHI Breaches Analysis shows that missed machine identity governance repeatedly shows up in breach pathways. The practical answer is to define identity categories up front, count them consistently, and report the mix rather than collapsing everything into one number.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity sprawl starts with poor inventory of machine and human principals. |
| NIST CSF 2.0 | ID.AM-1 | Asset and identity inventory supports accurate scope for mixed user-machine systems. |
| CSA MAESTRO | TRM-01 | Agentic and workload identities must be tracked separately from users. |
Count and classify every human and non-human identity before assigning ownership or controls.
