User-based metrics assume the main governance burden comes from people, but many modern authorization systems are consumed by software identities as well. Once machine identities are part of the decision path, the access estate grows beyond headcount. That changes audit scope, lifecycle ownership, and cost predictability, so user-only accounting understates both operational and security effort.
Why user-only metrics stop reflecting the real governance burden
User-based access metrics were built for a world where most entitlement activity followed employee headcount. In mixed identity environments, that assumption fails because many access decisions, reviews, and rotations now attach to services, workloads, bots, APIs, and other software actors. The metric still counts “users,” but the control burden is driven by identities, privileges, and lifecycle events that are not human.
That mismatch matters because the unit of governance changes. A single machine identity can touch multiple environments, rotate more frequently than a person changes roles, and require different owners, approval paths, and evidence. If the metric does not represent those populations, it becomes a poor proxy for operational load and security exposure.
Mixed estates also break the link between headcount and access inventory. Software identities often outnumber people, accumulate entitlements faster, and stay active longer than their human counterparts. In practice, that means the real denominator is the total set of governed identities, not the employee roster. A general identity primer such as IAM and IGA Basics helps frame why governance has to follow the identity, not just the person.
What mixed identity environments do to audit scope and ownership
Once software identities are in play, audit scope expands beyond joiner-mover-leaver processes for staff. Teams must account for service account ownership, token rotation, key custody, offboarding, and evidence of least privilege across systems that may not map cleanly to HR records. That is why lifecycle-focused guidance like NHI Lifecycle Management Guide is useful: it reflects the fact that non-human access must be discovered, attributed, maintained, and retired on its own cadence.
Ownership also becomes more distributed. Human access is usually owned by a manager, team lead, or IAM process. Machine access may be owned by platform engineering, application teams, DevOps, or a vendor integration team, which means a user-only metric hides the real control owner and the real remediation path. A review-centric model such as Access Reviews and Certification Guide aligns better because it treats review scope as an entitlement problem, not a people-count problem.
The practical result is that audit evidence becomes harder to assemble from a single system of record. If an organisation can only report user counts, it may miss dormant machine accounts, long-lived API credentials, or orphaned service principals that still have production reach. That is a governance gap, not just a reporting gap.
Why cost and security estimates become unreliable
User-only metrics also distort cost predictability. License volume, review effort, vaulting, rotation, monitoring, and exception handling all scale with the number and type of identities under management. Software identities often require more frequent oversight per account than human users, so the marginal effort is not linear. An identity metrics approach like Identity Security Metrics and KPIs Guide is more informative because it measures outcomes such as deprovisioning speed, review completion, and privileged exposure rather than raw headcount.
Security posture is affected in the same way. A user count can look stable while the machine identity estate grows sharply, especially in cloud and CI/CD environments. That creates more secrets, more token paths, and more opportunities for overprivilege or stale access. The issue is not simply scale; it is that the attack surface moves from employee accounts to workloads that may be harder to inventory and harder to attribute.
For that reason, the right reporting unit is usually a mix of people, software identities, and governed entitlements. If management wants a single number, it should be one that reflects access scope, review volume, or governed credential population rather than staff count alone. For organisations with a large non-human footprint, Top 10 NHI Issues is a useful way to see the failure modes that user-only reporting tends to miss.
Risk and Threat Considerations
When software identities are folded into the access estate but not into the metrics, organisations can underestimate both exposure and remediation effort. That creates a governance blind spot: dormant or overprivileged machine identities may remain active because they are invisible in user-centric reporting, and attackers often exploit exactly that kind of long-lived, poorly owned access.
Failure mechanism: human-centric reporting excludes machine identities from inventory, review, and lifecycle metrics, so stale privileges, reused credentials, and hidden ownership gaps persist.
Impact: access reviews become incomplete, audit evidence is weaker, and the organisation can carry more privilege and more secret exposure than its dashboards suggest.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Machine and human access both depend on credential lifecycle control. |
| AC-2 — Account Management | Mixed identity estates require inventory and governance beyond user headcount. | |
| AC-6 — Least Privilege | Overprivilege risk rises when software identities are excluded from access metrics. | |
| Recommendation — Track and rotate authenticators for every identity class, including non-human accounts. Maintain account inventories that include service and machine identities. Apply least privilege to all identities, not just workforce users. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity governance must cover people and software identities in mixed estates. |
| A.8.2 — Privileged access rights | Machine identities often carry privileged access that user-only metrics miss. | |
| Recommendation — Define identity ownership and lifecycle rules for all identity types. Control and review privileged access across human and non-human accounts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account management metrics must include non-human accounts to reflect real workload. |
| CIS-6 — Access Control Management | Mixed identity access needs consistent authorization and review discipline. | |
| Recommendation — Inventory, review, and remove inactive accounts across all identity classes. Enforce least privilege and periodic review for every access path. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | User-only metrics hide overprivileged software identities in mixed environments. |
| NHI-07 — Long-Lived Secrets | Machine identities often depend on secrets whose lifecycle breaks user-based reporting. | |
| NHI-01 — Improper Offboarding | Offboarding in mixed estates includes retiring machine identities, not only people. | |
| Recommendation — Measure and reduce excess privilege on non-human identities. Track and shorten secret lifetimes for machine access paths. Remove non-human access when systems, vendors, or integrations are decommissioned. | ||
Practitioner Guidance
What to prioritise: separate reporting for people, software identities, and total governed entitlements. If the same dashboard is used for workforce count and access estate size, it will understate effort as soon as workloads, service accounts, or API clients become material.
What to verify: the metric should answer a governance question, such as “How many identities require review or rotation?” rather than “How many employees do we have?” If it cannot drive an ownership decision, an audit sample, or a remediation queue, it is probably the wrong metric.
Practitioner takeaway: mixed environments need access metrics that follow the governed identity population, not the HR population, because security work scales with entitlements, secrets, and lifecycle events as much as with people.
Related resources from NHI Mgmt Group
- Why do manual access reviews break down in hybrid identity environments?
- How should security teams implement identity-based access control in mixed environments?
- Why do role-based access control models break down in modern collaboration and AI environments?
- Why do manual user access reviews break down in SaaS environments with frequent role changes?