The 5 Metrics Every Security Team Needs to Govern Non-Human Identities

Most security teams can tell you their mean-time-to-detect for endpoint alerts. Ask them the same question about a compromised service account, and you'll get silence. That gap is the NHI governance problem in one sentence.

Non-human identities now outnumber human identities at a ratio of 144 to 1 - a 56% jump in a single year, according to ^[1]. Yet most organizations still govern them the way they governed human accounts in 2015: spreadsheets, periodic reviews, and hope. The result is a growing population of untracked, unowned machine identities with standing access that no one reviews - and ^[2] notes that by the time an auditor or attacker finds them, the exposure has been there for months or years.

Before you can govern NHIs, you have to find them. Only about 28% of organizations believe they can prevent a rogue agent from causing damage, per the ^[3]. Step zero is continuous discovery - an always-on inventory that catches every service account, API key, OAuth token, and AI agent as it's created, not six months later during an audit. Everything below assumes you've started there.

Once you have an inventory, you need a measurement framework. Here are the five metrics that matter - what each one is, why it predicts risk, how to calculate it, and what target to aim for.

---

Metric 1: NHI Coverage Rate

What it is: The percentage of discovered NHIs that are actively governed - meaning they have a named owner, a defined purpose, and are enrolled in your lifecycle policies.

Why it predicts risk: An ungoverned NHI is invisible to your access reviews, your rotation schedules, and your deprovisioning workflows. ^[4] found that for most organizations there has never been a single source of truth for NHIs, nor any standardized onboarding, offboarding, or ownership processes - leaving inventories incomplete at best. Every ungoverned identity is a potential blind spot an attacker can exploit without triggering a single alert.

How to calculate it:

NHI Coverage Rate = (Governed NHIs ÷ Total Discovered NHIs) × 100

Baseline by running a full discovery scan across your IdP, cloud environments, CI/CD pipelines, and SaaS apps. Count every identity that has an assigned owner and is enrolled in a policy. Divide by total discovered. Most organizations starting this exercise find coverage below 40%.

Target: ≥ 90%. Anything below 70% means a material portion of your machine identity estate is operating outside governance controls.

---

Metric 2: Orphaned-NHI Rate

What it is: The percentage of NHIs whose owner has left the organization or whose owning team no longer exists - identities that are functionally unaccountable.

Why it predicts risk: A surprising 75% of companies report having machine identities without dedicated personnel managing them, per ^[5]. When an engineer leaves, the API keys and service accounts they created don't leave with them. ^[6] found that only 19% of organizations have automated processes for offboarding API keys. The SolarWinds breach is the canonical example: an orphaned secret allowed attackers to compromise thousands of systems long after the human who created it was gone.

How to calculate it:

Orphaned-NHI Rate = (NHIs with no active owner ÷ Total Governed NHIs) × 100

Cross-reference your NHI inventory against your HRIS. Flag any NHI whose owner account is deactivated or whose owning team has been dissolved. Also flag NHIs owned by distribution lists - ^[2] notes that when NHIs are owned by a team alias, no one takes responsibility and stale identities accumulate.

Target: < 5%. Zero is the goal; 5% is the realistic ceiling for a dynamic organization. Above 10% is a material risk that warrants an immediate remediation sprint.

---

Metric 3: Excessive-Privilege Rate

What it is: The percentage of NHIs whose granted permissions exceed what they demonstrably use - measured against actual runtime activity, not stated purpose.

Why it predicts risk: This is the most alarming number in the NHI space. 97% of NHIs have excessive privileges, according to the ^[7]. The mechanism is mundane: a developer needs a service account under deadline pressure, attaches AdministratorAccess, and moves on. Nobody revisits it. That account now has god-mode access to your entire AWS environment for a task that needed read access to one S3 bucket. Just 0.01% of machine identities control 80% of cloud resources, per ^[8]. Systems with least-privileged AI access have a 17% security incident rate versus 76% for over-privileged systems - a ^[9].

How to calculate it:

Excessive-Privilege Rate = (NHIs with permissions > actual usage ÷ Total Governed NHIs) × 100

Compare granted permissions against a 30-90 day window of actual API calls and resource access. Any NHI that hasn't used a permission in that window is a candidate for right-sizing. Cloud providers expose this data natively (AWS IAM Access Analyzer, GCP Policy Analyzer); the challenge is aggregating it across your full stack.

Target: < 20%. The industry baseline is 97% - so even reaching 50% is meaningful progress. The goal is continuous right-sizing, not a one-time audit.

---

Metric 4: Credential Age / Static-Secret Staleness Rate

What it is: The percentage of NHI credentials (API keys, service account passwords, tokens, certificates) that exceed your defined maximum age without rotation.

Why it predicts risk: Static secrets are the gift that keeps giving - to attackers. 71% of NHIs are not rotated within recommended timeframes, per ^[10]. 7.5% of machine identities in cloud environments are between 5 and 10 years old, and over 2% of active secrets are more than a decade old, according to ^[11]. The Internet Archive breach (October 2024) is the textbook case: attackers exploited unrotated API keys leaked from a GitLab repository, gaining access to over 800,000 support tickets. ^[12] shows 70% of secrets stay valid after two years - meaning most organizations are carrying years of accumulated credential exposure.

How to calculate it:

Static-Secret Staleness Rate = (NHI credentials exceeding max-age policy ÷ Total NHI credentials) × 100

Set a max-age policy by credential type: API keys ≤ 90 days, service account passwords ≤ 60 days, certificates managed to their expiry. Query your secrets manager, IdP, and cloud IAM for last-rotation dates. Credentials with no rotation date recorded should be treated as maximally stale.

Target: < 10% exceeding policy. For high-privilege NHIs, the target is 0%. Automate rotation wherever possible - ^[13] notes that manual rotation fails at scale when service dependencies, hard-coded credentials, and maintenance windows collide.

---

Metric 5: Mean Time to Deprovision (MTTD-NHI)

What it is: The average elapsed time between an NHI becoming eligible for deprovisioning (project ends, employee leaves, service retired) and its credentials being fully revoked across all systems.

Why it predicts risk: Access management has a timing problem. ^[14] notes that most organizations can grant access in hours but removing it can take days - and that gap is where breaches happen. For NHIs, the problem is worse: there's no HR offboarding trigger, no manager to approve the ticket, and no natural lifecycle event to prompt action. Only 20% of organizations have formal processes for offboarding and revoking API keys, per the ^[15]. Every day an eligible-for-deprovisioning NHI stays active is a day an attacker can use it.

How to calculate it:

MTTD-NHI = Average(Deprovision Completion Date - Eligibility Trigger Date) across all NHI offboarding events in the period

Eligibility triggers include: employee termination (for NHIs they owned), project closure, service retirement, or failed access review. Track both the trigger event and the date all associated credentials are confirmed revoked - not just disabled in your IdP, but revoked in every downstream system.

Target: < 4 hours for high-privilege NHIs; < 24 hours for standard NHIs. If your current MTTD-NHI is measured in weeks, that's the first metric to attack - it has the most direct impact on breach blast radius.

---

The Interactive NHI Governance Scorecard

Use the calculator below to score your current program against all five metrics and see where to focus first.

---

From Metrics to a Governance Program

Measuring these five numbers is the start, not the finish. The sequence that works in practice:

1. Discover first. You can't govern what you haven't found. Continuous discovery - not a quarterly scan - is the prerequisite for every metric above.
2. Assign ownership. Every NHI needs a named human owner. Without ownership, coverage and orphan metrics are meaningless.
3. Right-size privileges. Use runtime data, not stated purpose. The 97% excessive-privilege rate exists because nobody went back to check.
4. Automate rotation. Manual rotation fails at scale. Policy-driven, automated rotation is the only way to keep staleness rates below 10% when you're managing thousands of NHIs.
5. Wire deprovisioning to lifecycle triggers. HRIS terminations, project closures, and failed access reviews should automatically queue NHI deprovisioning - not create a ticket that sits in a queue.

This is exactly the lifecycle model described in our piece on the NHI explosion driving enterprise risk - and the operational efficiency case is made in detail in Calculating the True ROI of Identity Automation.

The organizations that get breached via NHIs aren't the ones that didn't care - they're the ones that never measured. Organizations with weak NHI management are 22% more likely to experience financial theft and pay approximately $150,000 more to recover than average, per the ^[16]. A scorecard doesn't fix the problem. But it makes the problem visible - and visible problems get fixed.