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

Count every distinct identity that receives authorization decisions, not just named users. That includes service accounts, workload identities, and delegated credentials if they independently consume policy. The useful governance question is whether your reporting denominator matches the real population under control, because access reviews and budget forecasts both fail when the counted unit is too narrow.

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.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Identification and Authentication (Non-Organizational Users)	Mixed human-machine access includes service and external technical identities.
	AC-2 — Account Management	Counting identities by governed account supports complete lifecycle and review scope.
Recommendation — Apply IA-9 to govern authentication for non-organizational identities that consume policy. Use AC-2 to inventory, review, and revoke every active identity under control.
ISO/IEC 27001:2022	A.5.16 — Identity management	The question is about defining the governed identity population across people and machines.
Recommendation — Define the managed identity population and keep it aligned to real access subjects.
CIS Controls v8	CIS-5 — Account Management	Mixed identity counting directly affects account inventory and access review coverage.
Recommendation — Maintain a complete account inventory that includes human and machine identities.
CSA Cloud Controls Matrix	IAM — Identity and Access Management	Cloud identity governance must include workforce and machine identities in one population.
Recommendation — Map both human and machine identities into a single IAM governance model.

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.