Top Metrics to Evaluate For Non-Human Identity Governance

You can stand in front of your board with a dashboard that looks like control. Thousands of service accounts discovered. Secrets stored in a vault. Scans running on schedule, with every row showing green. Yet you still cannot answer the question that matters: Is any one of those identities assigned to an owner, scoped correctly, and safe to revoke?

That gap is the central problem with how many teams measure non-human identity security. The numbers that are easy to count—accounts found, scans run, and secrets stored—measure activity. They do not prove that the organization has reduced risk to non-human identity threats.

Before selecting metrics, separate the identity subject from the authentication mechanism. A service account, service principal, workload, device, OAuth client, infrastructure identity, RPA bot, or AI agent can be a non-human identity (NHI). An API key, client secret, token, SSH key, or certificate is a credential that an identity uses to authenticate. One identity can use several credentials, so counting both the identity and each credential as separate identities inflates the inventory and distorts every downstream metric.

Effective measurement starts with a reliable inventory and continues through ownership, least privilege, credential hygiene, certification, and remediation. The following nine metric categories measure control rather than activity and culminate in a composite view of whether an NHI governance program is working.

Inventory coverage and the non-human-to-human identity ratio

Inventory coverage should be the first control metric. It measures the percentage of active, in-scope NHI subjects that have been discovered, classified, and cataloged in the central identity inventory.

• Inventory coverage = active in-scope NHIs cataloged ÷ active in-scope NHIs observed across authoritative systems

Do not derive the denominator from the central inventory itself. Reconcile the inventory against cloud platforms, identity providers, SaaS applications, secrets managers, source-control systems, CI/CD platforms, infrastructure-as-code repositories, container platforms, and other authoritative sources. The Cloud Security Alliance presents a target of more than 95% coverage of known NHIs, but the metric should also show connector coverage, data freshness, and discovery confidence. A program can report 100% coverage of connected systems while still missing an unconnected cloud account or shadow integration.

The non-human-to-human identity ratio provides useful context after inventory quality is established.

• Non-human-to-human identity ratio = active NHI subjects ÷ active human identities

Common non-human identity examples include service accounts, service principals, managed identities, OAuth clients, workload identities, infrastructure identities, RPA bots, and AI agents. Credentials such as API keys, tokens, client secrets, and certificates should remain in a separate credential inventory.

There is no universal “good” ratio. The value depends on architecture, automation, cloud adoption, and the counting method. Define whether the ratio includes ephemeral workload instances, shared identities, development environments, and third-party integrations, and then apply that definition consistently. A rising ratio is not inherently a problem, but it becomes evidence of non-human identity sprawl when ownership, review, or credential-compliance coverage fails to keep pace with growth.

The controls that improve these metrics are broad discovery, source reconciliation, identity classification, and continuous monitoring for new identities. ChargePoint used Lumos integrations to pull access data into one place and route access requests for more than 70 applications. Although that deployment centered on workforce access, it demonstrates the connector breadth and reconciliation discipline required to build a dependable identity inventory.

Ownership coverage rate

Ownership coverage measures the percentage of active, in-scope NHIs that have a valid, accountable human owner and a documented business or technical purpose.

• Ownership coverage = NHIs with a valid owner and purpose ÷ active in-scope NHIs

The target should be 100%. An identity without a valid owner cannot be reliably reviewed, investigated, or decommissioned. A populated owner field is not enough; the owner must still be active, understand the identity's purpose, and have the authority to approve changes to its access.

Vault storage does not prove ownership. A secrets manager can show that a credential exists and is centrally controlled, but it does not identify who should review the underlying identity, explain its dependencies, or respond when its behavior changes.

Ownership should be attributed from multiple signals, including repository history, deployment manifests, infrastructure tags, CMDB records, application ownership, network flows, cloud metadata, and prior access approvals. Require an owner and purpose at creation, revalidate ownership when teams or applications change, and route unresolved ownership to an escalation queue. Lumos brings available ownership signals into a unified identity inventory so each NHI remains attributable throughout its lifecycle.

Orphaned identity rate and dormant identity rate

Orphaned and dormant identities should be measured separately because they represent different conditions and require different remediation paths.

An orphaned NHI lacks a valid owner or business purpose.

• Orphaned NHI rate = active in-scope NHIs without a valid owner or purpose ÷ active in-scope NHIs

The target is zero unresolved orphaned identities. Some records may enter a temporary investigation state, but they should have an assigned remediation owner and a deadline.

A dormant NHI is a persistent identity that has not shown expected activity within the policy window for its identity type.

• Dormant NHI rate = persistent NHIs with no expected activity during the policy window ÷ persistent NHIs assessed

Do not apply one inactivity window to every identity. A threshold of 30, 60, or 90 days may be useful for a persistent service account, but it is meaningless for an ephemeral workload and may be too short for a quarterly batch process or disaster-recovery identity. Define dormancy by identity type, expected execution pattern, environment, and criticality.

Inactivity is a signal, not automatic proof that access is unnecessary. Before removing an identity, validate its dependencies, scheduled jobs, failover role, and downstream consumers. The safe sequence is to identify the owner, assess impact, disable or quarantine the identity, monitor for failures, and then decommission it after the validation period.

NHI lifecycle triggers should come from technical systems rather than only from HR events. Useful triggers include application retirement, repository archival, pipeline removal, cloud-resource deletion, integration disconnection, workload termination, owner departure, and team reassignment. The same control pattern applies when an application, integration, infrastructure resource, or automated workload outlives the project that created it. NHI programs need technical lifecycle signals that identify those conditions before the identity becomes an unmanaged access path.

Privilege right-sizing rate

Privilege right-sizing measures how closely an NHI's granted entitlements match its approved purpose and observed behavior. Report both an unused-entitlement rate and a policy-compliance rate.

• Unused-entitlement rate = granted entitlements with no observed use during the analysis window ÷ total granted entitlements
• Least-privilege compliance = NHIs whose entitlements match policy or an approved exception ÷ active in-scope NHIs

Unused access is evidence for review, but it is not sufficient evidence for immediate revocation. Some permissions support incident response, failover, monthly or quarterly jobs, or indirect dependencies that telemetry does not fully capture. Evaluate observed use alongside entitlement sensitivity, workload purpose, dependency data, approved exceptions, and owner validation.

A policy statement that says “least privilege is enabled” does not demonstrate control. The control is visible when unnecessary grants decline, high-risk exceptions expire, and new identities are provisioned from minimal templates rather than cloned from overprivileged accounts.

Controls that improve this metric include granted-versus-used analytics, entitlement-risk scoring, owner validation, time-limited exceptions, policy-as-code, and automated right-sizing workflows. This is where least-privilege access becomes measurable rather than declarative. Lumos uses identity and access context to help teams identify excess access, route proposed changes to accountable owners, and maintain an evidence trail for each decision.

Standing versus time-bound privileged access

Measure privileged access at the grant level rather than labeling an entire identity as either standing or just in time. An identity may have a mixture of permanent, scheduled, and request-based entitlements.

• Standing privileged access rate = active standing privileged grants ÷ all active privileged grants
• Time-bound privileged access rate = privileged grants with enforced expiration ÷ all active privileged grants

Standing access remains available until someone explicitly removes it. Just-in-time or time-bound access is issued for an approved, bounded window and expires automatically. It does not necessarily disappear the moment a workload stops making requests; it remains valid until the approved window ends or the task completes.

Counting JIT requests does not show whether risk has declined. A high request volume can coexist with extensive permanent administrative access. The meaningful outcome is a lower percentage of standing privileged grants and a higher percentage of privileged grants with enforced expiration.

Prioritize administrative access, production write access, secrets-management access, and other high-impact grants. Convert eligible access to request-scoped, task-scoped, or scheduled grants; require explicit exceptions for standing access; and review those exceptions regularly. Break-glass and emergency access should also be time-bound, monitored, and reviewed after use.

Code42 reduced privileged access by 67% after introducing time-based access for employees. That result concerns workforce identities, but it illustrates the control pattern NHI programs should apply wherever a platform can issue expiring grants instead of permanent privileges.

Static-credential-free coverage, rotation compliance, and age

Credential metrics should distinguish managed or short-lived authentication from long-lived static credentials.

• Static-credential-free coverage = assessed NHIs that do not rely on long-lived static credentials ÷ assessed NHIs
• Rotation compliance = static credentials within their policy-defined rotation or renewal interval ÷ static credentials assessed

Also track median age, 95th-percentile age, maximum age, failed rotations, expired credentials, stale copies, and credentials with unknown consumers. The Cloud Security Alliance presents at least 95% rotation compliance as a target for credentials that remain subject to rotation policies.

Vault integration is necessary but insufficient. A vaulted static key is still a long-lived credential if it never rotates, remains embedded in downstream systems, or lacks a reliable revocation path. Effective non-human identity management solutions should report the credential type, issuer, lifetime, last rotation, next expiration, dependent consumers, propagation status, and stale copies—not merely whether the secret is stored in a vault.

Do not apply human-password guidance directly to machine credentials. NIST SP 800-63-4 does not explicitly address machine-to-machine authentication or API access. Its recommendation against periodic password changes applies to subscriber passwords, not directly to NHI credentials. For NHIs, define credential lifetimes according to credential type, workload criticality, platform capabilities, and the impact of compromise.

The preferred end state is to reduce reliance on static credentials through managed identities, workload identity federation, automatically issued short-lived tokens, and short-lived certificates. Where static credentials remain necessary, automate issuance, renewal, propagation, validation, rollback, and revocation. Keep overlapping validity only as long as needed to update and validate dependent consumers; there is no universal overlap period that is safe for every system.

Certification quality and completion

Certification completion rate measures whether in-scope NHI access reviews finish within the required cycle.

• Certification completion rate = review items completed on time ÷ review items due

The Cloud Security Alliance presents a target above 98%, but completion alone does not establish review quality. A reviewer can approve every item without understanding the identity, its purpose, or its actual usage.

Add three quality metrics:

• Evidence-backed decision rate = completed decisions with a valid owner and usage or risk evidence ÷ completed decisions
• Review-remediation closure rate = required revocations or modifications completed within the service-level objective ÷ required review remediations
• Overdue high-risk review rate = high-risk review items past due ÷ high-risk review items due

These measures make non-human identity compliance defensible. An auditor should be able to see who reviewed the identity, what evidence was available, why the reviewer approved or changed the access, and whether the required remediation occurred.

Delta reviews improve reviewer focus by prioritizing new grants, privilege increases, ownership changes, unusual behavior, and other material changes. They should not automatically exclude unchanged high-risk access. Policy should determine which privileged or sensitive entitlements require periodic revalidation even when nothing has changed.

Lumos supports delta access reviews, centralized evidence, accountable reviewers, and multiple decision outcomes. A review should count as complete only when the decision and any resulting remediation are documented.

Mean time to remediate risky NHI findings

Mean time to remediate (MTTR) measures how quickly the organization resolves an NHI risk after detection. Measure findings rather than “risky identities,” because one identity can have several findings with different severities and remediation paths.

• MTTR = Σ(resolved timestamp − detected timestamp) ÷ number of resolved NHI findings

Report the mean, median, and 95th percentile, and segment the results by severity and finding type. Useful categories include exposed credentials, excessive privilege, missing ownership, dormant identities, anomalous behavior, failed rotations, and expired certificates.

A single universal target is rarely appropriate. Establish severity-based service-level objectives. Critical findings may require containment within minutes or hours, while lower-risk hygiene findings may allow a longer period. The Cloud Security Alliance uses less than 24 hours as an illustrative mature-state remediation target, but organizations should adjust that goal to their risk profile, operational constraints, and identity criticality.

Counting alerts or findings generated measures detection activity. It does not prove that risk was reduced. Track the percentage of findings resolved within the service-level objective, the age of the oldest open finding, reopened findings, and the number of accepted-risk exceptions approaching expiration.

Controls that reduce MTTR include automated rotation, revocation, quarantine, right-sizing, owner routing, dependency validation, and rollback. The same automation pattern helped Code42 bring access-request resolution down to four minutes. That was a workforce access result rather than NHI incident MTTR, but it shows how policy-based automation can compress operational response. For NHIs, apply the pattern to credential rotation, grant expiration, quarantine, and decommissioning.

Governed coverage rate

Governed coverage is a Lumos-recommended composite metric for the percentage of active, in-scope NHIs that meet a defined set of core governance controls simultaneously.

• Core governed coverage = active in-scope NHIs that have a valid owner and purpose, policy-compliant entitlements, policy-compliant credentials, and a current evidence-backed review ÷ active in-scope NHIs discovered

The composite makes it harder for one strong metric to obscure a weak control. For example, 100% vault coverage does not compensate for 20% ownership coverage, and a 99% review-completion rate does not compensate for unresolved remediation.

Governed coverage should not replace the component metrics. Report it alongside inventory coverage, data freshness, approved exceptions, standing privileged access, orphaned and dormant rates, and remediation performance. Publish the denominator and scope so stakeholders can see whether unconnected systems, ephemeral workloads, or difficult identity classes have been excluded.

A mature non-human identity security strategy uses a unified identity graph, policy framework, evidence model, and audit trail for human and non-human identities. It does not require identical controls for every identity type. A service account, workload, AI agent, and employee may share governance principles while using different lifecycle triggers, review cadences, credential controls, and remediation workflows.

That is the operating model Lumos is designed to support: one place to understand who and what has access, with lifecycle automation and review workflows tailored to the identity's purpose and risk. The result is a consistent audit trail without forcing machines into a human-only governance model.

Stop counting activity; start measuring control

Activity metrics can show that a team is busy. Control metrics show whether the program is reducing risk.

‍

What your scoreboard says about your program

A dashboard can show accounts discovered, scans completed, and secrets vaulted, with every number moving up and to the right. Those measures demonstrate activity. They do not answer whether each NHI is attributable, appropriately authorized, securely authenticated, reviewed, and removable.

In many environments, NHIs outnumber human identities and hold direct access to production systems, data, infrastructure, and business processes. Their governance cannot depend on a spreadsheet assembled before an audit or a separate console that no one reconciles with the rest of the identity program.

The number that matters is not how many NHIs you found. It is how many you can prove you govern. Lumos brings human and non-human identities into a unified control plane while preserving the lifecycle, credential, review, and remediation requirements that make each identity type different. See what a scoreboard built around control looks like in a Lumos demo.

‍