How should IAM teams count identities when access is used by both people and machines?

How should teams count identities when people and machines both use access?

The cleanest way to count is by authorization subject, not by headcount. If a person, service account, workload identity, or delegated credential receives its own policy decisions, it should appear in the denominator. That gives IAM, audit, and finance the same operational view of the population that access controls and reviews actually govern.

That approach matters because a narrow “named user” count hides the identities that create review workload, entitlement sprawl, and license or tooling cost. It also avoids false confidence when a small human population sits on top of a much larger machine identity estate.

What exactly belongs in the counting unit?

Count any identity that can be granted, reviewed, or revoked independently. In practice that includes workforce users, contractors, service accounts, workload identities, application identities, shared technical accounts, and delegated credentials when they are used to make distinct access decisions. The key test is simple: if removing that identity changes an access review, a policy, or an offboarding action, it belongs in scope.

Do not collapse everything into “users” unless your reporting is explicitly human-only. A machine identity that authenticates through a certificate, token, or cloud role can still be a first-class governance object even though no person signs in interactively. The governance unit should reflect who or what is being controlled, not just who sits in an HR directory.

For teams formalising that boundary, NHIMG’s Human vs Non-Human Identity is useful because it frames where human and machine populations meet, while the IAM and IGA Basics guide anchors the difference between authentication, authorization, provisioning, and entitlement governance.

Why does mixed human-machine counting matter for reporting and control design?

Mixed populations distort both measurement and decision-making if they are counted inconsistently. Access review completion rates, orphaned-account metrics, and privilege-census figures all become misleading when machine identities are excluded from the denominator but still generate policy and audit work. The same is true for budget forecasts, because tooling, vaulting, rotation, and governance effort scale with the actual controlled population.

Teams also need to separate “identity count” from “login count.” A single person may own multiple identities, and a single automated system may represent many operational functions. If reporting assumes one human equals one identity, the numbers understate control complexity and overstate governance maturity.

NHIMG’s Identity Security Programme Guide is a good navigation point when the issue is programme scope, because it treats human, non-human, and agent populations as one operating model. For machine-heavy estates, the Cloud Workload Identity Guide shows why temporary cloud roles and federated workload access should be counted as governed identities rather than hidden implementation detail.

Practitioner Guidance

What to verify: Define whether the reported metric is “named people,” “all identities under policy,” or “all active identities with revocation paths.” If those three are mixed, every trend line will be hard to trust.

What to measure: Keep separate counts for human identities, machine identities, and delegated identities, then reconcile them to the systems that enforce policy. That makes it obvious when access reviews, credential rotation, or lifecycle work is growing faster than workforce headcount.

Common mistake: Using HR or directory records as the sole denominator. That is usually too narrow for governance and too blunt for operational planning, especially where service accounts and workload identities carry real access risk.

Practitioner takeaway: Count the population that actually consumes authorization decisions, because governance breaks when the reporting unit is smaller than the controlled estate.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should teams count identities when both users and machines access the same system?