Pillar 03 · programme frame

Non-human identity management.

Non-human identity management (NHI management, sometimes NHIM) is the set of governance capabilities that administer the lifecycle, credentials, and permissions of the software identities in an enterprise. It is the sister discipline to human IAM and privileged access management, sharing some concepts, operating on different primitives, and requiring its own tooling.

By HumanAudit Inc. editorial teamLast reviewed 5 August 2026
VerifiedLast reviewed 5 August 2026 by the HumanAudit Inc. editorial team.Corrections logEditorial policy
On this page
  1. One-sentence definition
  2. The 7 capabilities
  3. The 5-stage maturity model
  4. NHI management vs. IAM vs. PAM
  5. The ownership question
  6. Metrics that matter
  7. A 12-month roadmap
  8. FAQ

TL;DR

  • NHI management is the programme layer above NHI security; security is the outcome, management is the capability set.
  • Seven core capabilities: inventory, ownership, credentials, privileges, lifecycle, monitoring, integrations.
  • Measure against a five-stage model; most organisations start between stage 1 and stage 2.
  • It sits alongside IAM and PAM rather than under either, different primitives, different scale.
  • Typical ownership is split between IAM (inventory + lifecycle) and DevSecOps / platform engineering (credentials + workload identity).

The one-sentence definition

NHI management is the set of capabilities, people, processes, and tooling, that discover, own, credential, authorise, monitor, and retire the non-human identities in an organisation's environment, with the goal of making compromise hard and consequences of compromise contained.

The seven capabilities of a mature NHI programme

A useful way to structure an NHI programme is by capability, because capabilities are what you invest in and measure against. The seven capabilities we return to across this site:

1. Discovery and inventory

Continuous, automated discovery of non-human identities across every source system, directories (Active Directory, Entra ID, LDAP), cloud accounts (AWS, Azure, GCP), SaaS tools (Google Workspace, Microsoft 365, Salesforce, GitHub, etc.), CI/CD systems, Kubernetes clusters, secret stores, and databases. The output is a consolidated NHI inventory with attributes: name, type, location, creation date, last-used date, owner, permissions scope, credential age.

Inventory is where programmes start because it is the foundation on which every other capability depends. An inventory that is 60% complete is worse than honest, it produces false confidence about the 40% you cannot see.

2. Ownership and accountability

Every NHI has a named, current human owner. At the point of creation, an owner is identified and recorded. When the owner changes jobs or leaves, the NHI is flagged for re-ownership or decommissioning. Ownership is enforced by tooling, you cannot create an NHI without nominating an owner, and the system escalates orphaned NHIs for attention.

3. Credential lifecycle

Secrets are stored in a central secret store, never in code. Credentials have defined rotation schedules and are automatically rotated. Where possible, static credentials are replaced with short-lived dynamic credentials or workload identity federation.

4. Privilege management

NHI permissions are granted at the minimum needed for the purpose. Permissions are reviewed on a regular cadence and drift is detected and flagged. Just-in-time elevation is used for rare privileged operations. Unused permissions are removed.

5. Lifecycle management

NHIs have defined creation, modification, and retirement processes. Decommissioning is triggered by identifiable events: employee departure, application retirement, integration removal. NHIs without recent activity are automatically flagged and escalated for retirement.

6. Anomaly monitoring and detection

NHI behaviour is baselined, and anomalies (unusual login location, unusual API pattern, unusual permission use) are alerted. Detections flow into the SOC or a dedicated identity threat detection and response (ITDR) capability.

7. Third-party integration governance

OAuth applications, SaaS-to-SaaS connections, and partner API integrations are catalogued, reviewed at installation, re-reviewed on permission change, and revoked on deprecation. Post-Salesloft/Drift, this has moved from an edge concern to a core capability for any SaaS-heavy organisation.

The 5-stage NHI maturity model

We use a five-stage maturity model throughout this site, the same model underpins the interactive maturity assessment. It is adapted from CMMI-style capability maturity models and calibrated against empirical observation of NHI programmes across the maturity spectrum.

StageCharacteristicTypical breach blast radius
1 · Ad hocNo inventory. Secrets in code. No ownership. No rotation.Full tenant compromise; months of attacker dwell
2 · ReactivePartial inventory. Secret scanner detecting known leaks. Rotation after exposure.Widespread lateral movement through forgotten accounts
3 · DefinedCentral secret store. Documented policy. Annual reviews. Uneven coverage.Contained to one integration; detection slow
4 · ManagedAutomated rotation. Behavioural monitoring. OAuth review. Continuous evidence.Detected and revoked in hours; minimal data loss
5 · OptimisedShort-lived credentials default. Workload identity federation. NHIDR + SOAR.Identity not reusable; attacks fail by design

In practice, most organisations, including large ones with significant security investment, sit between stages 1 and 3 on their NHI programme. A stage-4 NHI programme is an achievement. Stage-5 is rare and typically only reached by organisations with dedicated NHI engineering capacity and a zero-trust architectural commitment.

NHI management vs. IAM vs. PAM

Three adjacent disciplines, commonly confused:

  • Identity and access management (IAM), traditionally human-centred. Single sign-on, multi-factor, access reviews, joiner-mover-leaver. Vendors: Okta, Microsoft Entra, Ping Identity, SailPoint, Saviynt.
  • Privileged access management (PAM), the subset of IAM focused on highly privileged access. Traditionally human-admin-centred (root, domain admin) but increasingly extended to service accounts. Vendors: CyberArk, BeyondTrust, Delinea, Teleport.
  • Non-human identity management (NHI management), identity governance for software identities. Overlaps with PAM on service accounts, overlaps with IAM on lifecycle concepts, but handles primitives and scale the others were not designed for.

The right mental model is Venn overlap, not hierarchy. IAM platforms increasingly extend into NHI (Okta's Identity Security Posture Management, Entra's Agent ID). PAM platforms extend into NHI (CyberArk's post-Venafi acquisition portfolio). Dedicated NHI platforms extend into IAM-adjacent capabilities (Astrix's SaaS identity posture). In 2026 most enterprises run two or three of these stacks alongside each other.

Who owns the NHI programme

There is no single right answer. Common patterns we see:

  • IAM-led NHI programme, NHI management owned by the identity team, reporting to the CISO. Works when the organisation already has a strong human IAM practice. Risk: the discipline inherits human-IAM assumptions that don't transfer.
  • DevSecOps-led NHI programme, NHI management owned by platform engineering or application security, with a dotted-line to the CISO. Works in cloud-native, engineering-heavy organisations. Risk: governance rigour can be uneven.
  • Shared model, IAM owns inventory, ownership, and lifecycle; DevSecOps owns credential management, workload identity, and CI/CD integration. Works well but requires genuine collaboration.
  • Dedicated NHI team, emerging in organisations with large NHI populations (financial services, large SaaS providers). Owned by a small dedicated team, typically 2 to 6 people, reporting to the CISO.

Metrics that matter

KPIs we've seen work in practice:

  • Inventory coverage, percentage of NHIs in the inventory vs. estimated total. Goal: 95%+.
  • Orphan rate, NHIs without a current owner. Goal: <2%.
  • Credential age (p50, p95), median and 95th-percentile age of active credentials. Goal: p50 <90 days.
  • Least-privilege drift, unused permissions across the NHI population. Goal: declining month over month.
  • Detection coverage, NHIs under behavioural monitoring. Goal: 100% of high-privilege, 80%+ overall.
  • Offboarding lag, time from decommissioning event to NHI retirement. Goal: <7 days.
  • OAuth review cycle, percentage of OAuth integrations reviewed in the last 90 days. Goal: 100% for business-critical tenants.

A credible 12-month roadmap

For an organisation at stage 1 to 2 today aiming at stage 3 in 12 months, a plausible sequence:

  • Months 1 to 2: Stand up auto-discovery. Consolidate inventory across top three sources (probably AD, one cloud, GitHub). Assign initial ownership to the top 20% by privilege.
  • Months 3 to 4: Deploy secret scanning across repositories and CI. Rotate the oldest credentials. Retire obvious orphans.
  • Months 5 to 6: Centralise secret storage. Migrate the highest-risk NHIs into the secret manager.
  • Months 7 to 8: Right-size the top 10% by privilege. Establish an OAuth review cadence.
  • Months 9 to 10: Deploy behavioural monitoring on high-privilege NHIs. Establish NHIDR workflow with the SOC.
  • Months 11 to 12: Pilot workload identity federation for one new service. Document programme. Run an audit dry run.

Next in the library: The NHI lifecycle, what happens at each stage and where it fails.

Continue: Vendor comparison · Certificate lifecycle management

Frequently asked questions

What is NHI governance and how does it work?

Non-human identity governance is the practice of knowing which non-human identities exist, who is accountable for each, what each may access, and being able to evidence all three. It works through four repeating activities: automated discovery across cloud, SaaS and code; ownership attribution to a named person; control of credential scope and lifetime; and periodic review that results in executed revocations. The evidence produced by that last step is what distinguishes governance from inventory.

What does a formal NHI governance framework for API keys and service accounts look like?

At minimum it defines: what justifies creating an identity and who approves it, the maximum credential lifetime per risk tier, who the accountable owner is and what happens when they leave, the review interval by blast radius, the conditions for automatic retirement, and how exceptions are registered and expire. Written as policy this fits on a few pages; the difficulty is entirely in enforcement at creation time rather than in drafting.

What metrics should be used to evaluate non-human identity governance?

Four that resist gaming: inventory coverage as a percentage with a measurement date and method, the count of credentials with unbounded lifetime, the proportion of identities with a named individual owner, and the measured time from a revocation instruction to confirmed loss of access. Avoid counting identities discovered or alerts raised, since both rise with tooling maturity rather than with risk reduction.

How does NHI management differ from traditional IAM?

Traditional IAM is built on an authoritative source of record, usually an HR system, that triggers joining, moving and leaving. Non-human identities have no such source, so the triggers must be constructed. IAM also assumes interactive authentication with factors such as passwords and MFA; NHIs present keys, tokens and certificates. Access-review concepts transfer cleanly, the lifecycle trigger model does not, and the scale difference is typically one to two orders of magnitude.

Where should an NHI programme start?

With measurement rather than procurement. Establish inventory coverage, count credentials with no expiry, and measure how long revocation actually takes. Those three numbers scope the problem, support a budget conversation and are obtainable without buying anything. Buying a platform before an ownership model exists produces a well-organised list of problems the organisation is not structured to fix.

Is there a roadmap for learning non-human identity management?

A workable sequence: understand what counts as an NHI and how the categories differ, then read the OWASP Non-Human Identities Top 10 for the risk vocabulary, then a real breach case study to see how the risks combine in practice, then the lifecycle model, then workload identity through SPIFFE, and finally the governance and evidence layer through a framework such as ISO/IEC 42001. Our Learn section is ordered roughly this way.

Where does your programme actually sit?

Reading about NHI governance and measuring your own position are different exercises. The free maturity assessment scores you across discovery, ownership, credential control and evidence in about ten minutes, in your browser, and produces a written report.

Run the maturity assessment →or book a 20-minute discovery call →
Framework mapping: ISO/IEC 27001 Annex A for machine identity
Also see: NHI discovery methodology · NHI policy template