Your IGA program knows every employee's access. It has no idea what your service accounts, API tokens, or AI agents can do. That gap (the non-human identity blind spot) is where most modern breaches begin.
In December 2024, a single compromised API key in BeyondTrust's Remote Support SaaS platform gave attackers a path into US Treasury employee workstations. The Treasury classified it a major incident. The breach didn't start with a phished employee or an exploited vulnerability. It started with one non-human credential that nobody was watching.
Two months earlier, authentication tokens sitting in an Internet Archive GitLab repository (left accessible and unrotated for nearly two years)were exploited in a breach affecting 31 million user accounts.
The pattern behind these incidents is consistent and worth naming plainly: attackers are not going around non-human identities. They are going through them. Service accounts, API keys, OAuth tokens, machine credentials: these are the entry points, because these are the identities that governance programs were never built to cover.
The category of practice that addresses this is called NHI governance. It applies the same visibility, lifecycle management, access review, and audit rigor to non-human identities that mature IGA programs apply to human users. For a step-by-step program guide, see our article on governing service accounts. And in most enterprises, it does not exist yet.
What Is a Non-Human Identity?
A non-human identity (NHI) is any digital credential used by a system, workload, application, or automated process to authenticate and authorize its actions, without a human actively logging in.
NHIs are not users. They are the machine actors running modern enterprise infrastructure: the identities that execute the automations, integrations, pipelines, and AI workflows that power the business. In most organizations today, they outnumber human identities by 40 to 1. In highly automated environments, that ratio approaches 500 to 1.
The taxonomy is broader than most security teams initially assume. Service accounts: named accounts in Active Directory or a cloud IAM system, associated with a specific application or automated process. But NHIs also include API keys and bearer tokens used to authenticate programmatic requests, OAuth applications connecting SaaS platforms to each other, cloud service principals and managed identities in AWS, Azure, and GCP, certificates and SSH keys, CI/CD pipeline credentials, RPA bot identities, secrets stored in vaults and key management systems, and increasingly, AI agents with tool-calling credentials that access customer data, production APIs, and enterprise systems.
Every one of these credential types shares the same governance problem: they were created outside HR processes, they authenticate without human interaction, they accumulate without decommission triggers, and they are almost universally excluded from access review programs.
What Is NHI Governance?
NHI governance is the discipline of applying IGA-grade controls to non-human identities across their full lifecycle.
The term "IGA-grade" is deliberate. Identity Governance and Administration programs exist to answer a specific set of questions about human identities: who has access to what, whether that access is appropriate, who approved it, and whether it has been reviewed recently. NHI governance asks the same questions about machine identities, and builds the same systematic processes to answer them.
It covers best practices for service accounts, with each area mapped to established best practices for service accounts.
Discovery and inventory. Before anything else, an organization needs to know what non-human identities exist, where they live, and what they can access. For most enterprises, this is the first and largest gap. NHIs are scattered across Active Directory, cloud IAM layers, SaaS applications, code repositories, CI/CD systems, and developer workstations, with no central registry.
Ownership and accountability. Every NHI needs a named human owner: the person or team responsible for confirming that the account still serves a valid purpose and that its access is appropriate. In practice, most NHIs are unowned. They outlive the developers who created them and accumulate with no accountability chain.
Lifecycle management. NHIs need formal creation controls (mandatory owner assignment, initial least-privilege policy, documentation of purpose), operational hygiene (dormant account detection, credential rotation checks, over-permission alerting), and decommission workflows (triggered when the associated application or project is retired). None of these exist in most organizations without deliberate program investment.
Access reviews and attestation. Periodic certification campaigns should extend to NHIs, requiring owners to confirm that each account's access is still necessary and appropriately scoped. Failed attestations should trigger automatic revocation. This is governance parity: the same review rigor that applies to employees applies to the machine identities operating alongside them.
Risk scoring and posture monitoring. Static access reviews are not sufficient for the pace at which NHI environments change. Continuous monitoring should surface new excessive-privilege findings, dormant accounts, credential rotation lapses, and orphaned identities between review cycles, prioritized by risk level so teams can act on what matters most.
Compliance reporting and audit evidence. Auditors under SOX, PCI DSS, ISO 27001, HIPAA, and GDPR are now asking questions about non-human identities. Which accounts have access to financial systems? Which credentials have access to cardholder data environments? Who owns the service accounts touching patient health information? NHI governance produces the audit trail and certification records that answer these questions systematically.
Why Your IGA Program Doesn't Cover NHIs
Most IGA programs were built around a single foundational assumption: identities originate from HR systems. An employee is hired, an identity is created, and the joiner-mover-leaver (JML) model governs it from that point forward. The IGA platform's discovery, provisioning, review, and deprovisioning workflows all trace back to that HR event.
Non-human identities have no HR event. A developer creates a service account to support a new integration. A DevOps engineer generates an API key for a CI/CD pipeline. An AI agent deployment creates credentials to access production APIs. None of these appear in Workday or BambooHR. None of them trigger an onboarding workflow. None of them will trigger an offboarding workflow when the project ends, the engineer moves teams, or the agent is replaced.
The result is a parallel identity universe running alongside the governed one. Your IGA platform has a clean record of every employee's access. It has no record of the service accounts those employees created, the tokens those integrations use, or the credentials those AI agents hold.
Four structural differences make this gap hard to close with human-identity tools.
NHIs authenticate programmatically, not interactively. MFA cannot be applied. The primary authentication control available for human identities is architecturally unavailable for machine identities.
NHIs have no behavioral baseline tied to a person. A human user who suddenly accesses systems outside their normal pattern triggers anomaly alerts. A service account that authenticates 10,000 times per day looks identical to one that has been compromised and is now authenticating on an attacker's behalf.
NHIs accumulate without natural decommission signals. Employees leave and trigger offboarding. Projects end and trigger nothing. Service accounts, API keys, and integration tokens from retired projects stay active indefinitely.
NHIs multiply automatically. Every new microservice, pipeline stage, SaaS integration, and AI agent deployment creates new credentials. At the velocity of modern software delivery, no manual tracking process scales.
The Scale of the Problem
Numbers help make the scope concrete.
Non-human identities outnumber human identities by 40 to 1 in the typical enterprise. The NHI population grew 44% year-over-year between 2024 and 2025. One Fortune 500 bank auditing its identity infrastructure found 4.2 million non-human identities against an expected 50,000 human accounts: most unmanaged, many abandoned.
97% of non-human identities carry excessive privileges. Over-permissioned NHIs are the most common cloud misconfiguration in 2025. 1 in 20 AWS machine identities carries full Administrator privileges.
80% of identity-related breaches involve compromised NHIs such as service accounts and API keys. When a non-human credential is compromised, the average attacker dwell time is over 200 days — more than three times the equivalent figure for compromised human accounts. The gap exists because nobody is watching.
The AI dimension is accelerating everything. Microsoft Copilot Studio users have collectively created more than one million AI agents. Each agent deployment creates credentials (API keys, tool-access tokens, service identities)that authenticate to enterprise systems without human involvement. In 2025, 45% of the workforce used unapproved AI tools, each deployment generating unmanaged credentials that will never appear in an IdP. AI-related secrets alone accounted for 1.27 million exposures in public code repositories last year, an 81% year-over-year increase and the fastest growth of any credential category.
Gartner named "Identity and Access Management Adapts to AI Agents" one of its top cybersecurity trends for 2026. OWASP published a dedicated Non-Human Identities Top 10 framework in 2025. The regulatory and standards environment is catching up to where the risk already is.
The Five NHI Governance Gaps (And What Fills Them)
Most organizations that take stock of their NHI posture find the same five gaps in roughly the same order of severity.
Gap 1: Discovery
You cannot govern what you cannot see. The first gap is simply not knowing what non-human identities exist across the environment. They live in Active Directory, in cloud IAM layers, in individual SaaS applications, in code repositories, in vault systems, and in CI/CD pipelines, with no central inventory.
Closing this gap requires discovery across all of these environments simultaneously, not just the ones visible to cloud IAM tools. The fastest-growing segment of the NHI population — SaaS-layer identities like OAuth apps, integration tokens, and SaaS automation users — is invisible to infrastructure-focused tools. Any NHI governance program that can't reach the SaaS layer is working with an incomplete picture.
Gap 2: Ownership
Discovered NHIs need owners. The ownership gap is widespread because NHIs are created in moments of operational urgency, without formal ownership assignment, and then outlive the people who created them. A service account whose creator has since left the organization is effectively ownerless, but it retains its full access.
Closing this gap requires owner inference (using HR and application metadata to identify the most likely accountable team when explicit ownership was never recorded), mandatory assignment at creation enforced by policy, and a process for reassigning ownership when personnel change.
Gap 3: Lifecycle
NHIs need the same lifecycle rigor as human identities, adapted to their creation patterns. They need creation controls that enforce least privilege and documentation from the start. They need operational checks that flag dormant accounts (unused for 30, 60, or 90 days with active permissions), over-permissioned accounts (privileges exceeding what the workload demonstrably needs), and accounts with stale credentials (API keys or certificates approaching or past rotation deadlines). And they need decommission workflows that run when the associated application is retired, not years later when someone discovers the account in an audit.
Gap 4: Access Reviews
The standard access certification campaign covers employees. Extending it to NHIs requires two things the typical IGA platform doesn't provide for machine identities: visibility into what NHIs exist and what they can access, and a review workflow that can be presented to an owner who may have limited context about what the account originally did.
When this gap is closed, it looks like a quarterly or semi-annual certification campaign that includes service accounts, API keys with long-term access, and OAuth applications alongside the employee population, with the account's usage data, last activity, privilege level, and purpose surfaced to help the owner make a meaningful attestation decision.
Gap 5: Secrets and Credential Hygiene
Long-lived credentials are the primary NHI breach vector. API keys set once and never rotated. Tokens embedded in code and forgotten. Certificates expiring without renewal. Service account passwords never changed because changing them might break an undocumented integration.
Closing this gap requires rotation enforcement (automated where possible, policy-enforced everywhere), expiry monitoring, and active scanning for credentials exposed in code repositories or configuration files. This is where NHI governance intersects with secrets management: complementary disciplines that address different dimensions of the same problem.
What Good NHI Governance Looks Like in Practice
A mature NHI governance program produces a specific set of outcomes. It's useful to make these concrete, because "NHI governance" can feel abstract until you see what it replaces.
Before NHI governance, a typical enterprise has service accounts that have been running for three to five years with no review. Developers who created them left the organization without any deprovisioning process for the accounts they owned. API keys exist in code repositories that are technically public or semi-public. OAuth applications connected to the organization's Salesforce instance include at least a few from vendors whose contracts ended years ago. AI agents deployed by product teams have broad API access with no documented owner.
After NHI governance, every non-human identity in the environment appears in a central inventory with its owner, its access profile, its last activity date, its risk score, and its credential rotation status. Quarterly review campaigns surface accounts whose access has drifted from what their purpose requires. Dormant accounts are flagged within 90 days of inactivity. When a project is retired, the associated service accounts and tokens are decommissioned as part of the project closure process. When an auditor asks which identities have access to the cardholder data environment, the answer comes from a system of record, not a spreadsheet.
Narvar, a technology company with 300+ users across time zones, reached exactly this state after deploying Zluri. Their specific challenge: external and service accounts in tools like Monday.com and Confluence remained active long after projects closed. Philip Zhou, Director of IT Operations, put it directly: "We had customer and partner accounts that stayed active long after projects closed. With Zluri, we can now enforce clean-up policies automatically." After implementation, Zluri's policy engine auto-suspends inactive accounts after 90 days with a full audit trail. Narvar saved 150+ hours annually in audit effort and achieved $16K in operational savings.
How Zluri Delivers NHI Governance
Zluri is an identity security platform built to govern every identity (human and non-human)across SaaS, cloud, and on-premises environments from a single control plane. It is the only platform that extends IGA-grade governance to the SaaS identity layer that cloud-native and infrastructure-focused tools cannot reach.
The NHI governance capability stack works as follows.
Discovery across every environment. Zluri's IVIP (Identity Visibility and Intelligence Platform) uses 8 discovery methods to surface non-human identities wherever they live — IDPs and SSO, HRMS, MDMs, direct SaaS and cloud application integrations, CASBs, finance systems, directories, and optional desktop agents and browser extensions. This includes AWS IAM roles and access keys, Azure service principals and managed identities, GCP service accounts, GitHub service accounts and personal access tokens, GitLab tokens, Snowflake keypair users, RPA bot identities, AI agent and agentic workflow credentials, and the SaaS-layer integration identities that infrastructure-only tools miss entirely.
The 360-degree NHI identity card. Every discovered NHI is normalized into a complete identity profile: type, owner (assigned or inferred from HR and application metadata), privilege level, last activity, accessed-by mapping showing which humans and systems call this NHI, credential rotation age and expiry, the applications and resources the NHI can reach, and a risk score.
IRIS — the intelligence layer. IRIS (Identity Risk Intelligence System) is the engine beneath every governance decision Zluri makes. It ingests raw identity signals from all discovery sources, normalizes and deduplicates records, builds a relationship graph connecting each NHI to its permissions and the resources it can reach, and surfaces risk-scored findings with prioritized recommended actions. When a service account has been dormant for 90 days and still holds admin-level access to a production database, IRIS surfaces it as a high-priority finding automatically, without anyone having to run a manual query.
Access reviews extended to NHIs. Zluri's access certification engine (the same workflow used for human identity reviews)extends to non-human identities. Review campaigns can include service accounts, OAuth apps, API credentials, and other NHI types alongside the employee population. Owners receive attestation requests with full context: usage data, privilege level, last activity, and purpose. Failed attestations trigger automatic revocation through Zluri Actions.
Lifecycle automation via Zluri Actions. Zluri Actions executes remediation across integrated systems, revoking access, rotating credentials, suspending dormant accounts, triggering decommission workflows — without manual IT intervention. The policy engine can enforce rules like auto-suspension after 90 days of inactivity, automatic escalation for accounts approaching credential expiry, and deprovisioning when an associated application is retired.
SoD enforcement for machine identities. Zluri's Segregation of Duties engine checks for toxic access combinations involving NHIs alongside human identities. A service account that can both initiate and approve a financial transaction creates a SoD conflict whether or not a human is involved. Zluri surfaces these combinations and enforces separation policies across both identity types.
Unified compliance reporting. A single compliance evidence set covers human and non-human identities. When a SOX auditor asks which identities have access to financial systems, when a PCI DSS assessor asks about cardholder data environment access, when an ISO 27001 review requires evidence of privileged access management, the answers come from one system of record, not a reconciliation between an IGA platform and a separate NHI tool.
NHI Governance and the Compliance Mandate
Regulatory frameworks are explicitly expanding their scope to include non-human identities, and the pace of that expansion is accelerating.
SOX auditors increasingly ask for evidence that all accounts touching financial systems, including automated processes and service accounts — have been reviewed and are appropriately permissioned. Demonstrating that only human identities were covered in the last access certification is no longer sufficient for a clean finding.
PCI DSS v4.0 Requirement 8.7 specifies that only programmatic methods should access cardholder databases, but those programmatic methods (the service accounts and API keys doing the accessing)need to be governed, owned, and periodically reviewed. Requirement 10 requires audit logs covering all access, including automated access.
ISO 27001:2022 expanded its access controls to account for non-human actors more explicitly. Demonstrating management of privileged access now includes service accounts and API keys with elevated permissions.
HIPAA requires that any automated process touching Protected Health Information be governed. A service account with PHI access that is unowned, unreviewed, or over-permissioned is a compliance risk regardless of whether a human ever logged in using it.
OWASP's Non-Human Identities Top 10, published in 2025, lists improper offboarding, secret leakage, insecure authentication, overprivileged NHIs, long-lived secrets, and human-only access management policies as the defining risks. Every item on that list maps directly to the governance gaps described in this article.
The direction of travel is clear. NHI governance is moving from a security best practice to a compliance requirement. Organizations that build the program now are building it on their terms. Organizations that wait will build it under audit pressure, with less time and more remediation work.
Building an NHI Governance Program: Where to Start
The scope of NHI governance can feel paralyzing when viewed all at once. A practical starting point focuses on three things in sequence.
Start with discovery. Run a full inventory across your environment: cloud IAM, Active Directory, and the SaaS application layer. Accept that the number will be larger than expected. A realistic inventory is the foundation for everything else, and it is the only way to know the actual scope of what needs to be governed.
Then prioritize by risk. Not all NHIs carry the same risk. An API key with read-only access to a non-production data set is not the same as a service account with write access to a production financial database. Use privilege level, last activity, and environment classification to tier the inventory, then focus initial governance effort on the highest-risk accounts.
Then establish ownership for the high-risk tier. For teams evaluating service account management tools to operationalize this, the tools guide covers how to match capabilities to your specific governance gaps. Assign a named human owner to every account in the top tier, with explicit accountability for attestation. This is the hardest step because it requires cross-functional cooperation: IT, security, DevOps, and application owners all need to participate. But ownership is the precondition for everything else. You cannot run an access review, enforce a lifecycle policy, or hold anyone accountable for a breach if no one owns the identity.
Everything else builds on that foundation: periodic access reviews, lifecycle automation, credential rotation enforcement, and continuous posture monitoring.
Frequently Asked Questions
What is the difference between NHI governance and PAM?
Privileged Access Management (PAM) tools focus on securing the credentials themselves: vaulting passwords, rotating API keys, managing secrets, and controlling privileged sessions. NHI governance focuses on the identity layer above the credential: whether the NHI should exist, who owns it, whether its access is appropriate, and whether it has been reviewed. The two are complementary. A PAM tool manages the vault; an NHI governance program manages who has access to what and ensures that access is periodically certified. Most organizations that have CyberArk or a similar PAM tool still lack access reviews, ownership models, and audit trails for the identities those tools protect.
Which types of identities does NHI governance cover?
NHI governance covers any non-human credential used to authenticate and authorize system access. This includes service accounts in Active Directory and cloud IAM, API keys and bearer tokens, OAuth applications connecting SaaS platforms, cloud service principals and managed identities (AWS IAM roles, Azure service principals, GCP service accounts), certificates and SSH keys, CI/CD pipeline credentials, RPA bot identities, secrets stored in vaults and key management systems, and AI agent credentials. The taxonomy is expanding as new automation and AI deployment patterns generate new credential types.
Why can't existing IGA platforms handle NHIs?
Traditional IGA platforms were built around the assumption that identities originate from HR systems. Their discovery, provisioning, review, and deprovisioning workflows all depend on human lifecycle events: hire, role change, termination. NHIs have no HR event. They are created outside IT processes, authenticate without human interaction, and have no natural decommission trigger. This is the core reason service accounts and user accounts require fundamentally different governance approaches. Most IGA platforms lack the discovery integrations to find NHIs where they actually live, and their review workflows assume a human identity model that doesn't apply to machine identities.
How does NHI governance relate to secrets management?
Secrets management and NHI governance are complementary disciplines. Secrets management addresses the credential itself: secure storage, rotation, expiry, and access control. NHI governance addresses the identity using the secret: who owns it, whether its access is appropriate, whether it has been reviewed, and whether it should still exist. A mature program needs both. A well-managed vault that contains credentials for unowned, over-permissioned, never-reviewed service accounts is still a governance risk.
What compliance frameworks require NHI governance?
SOX, PCI DSS v4.0, ISO 27001:2022, HIPAA, and GDPR all have provisions that implicate non-human identities to varying degrees. SOX auditors increasingly require evidence that automated processes and service accounts touching financial systems have been reviewed. PCI DSS Requirement 8 addresses programmatic access to cardholder data environments. ISO 27001:2022 expanded its access controls to include non-human actors. OWASP published a dedicated NHI Top 10 framework in 2025. US government mandates including EO 14028 and NSM-10 now require real-time cryptographic inventorying that directly implicates NHI populations.
How does Zluri approach NHI governance differently from competitors?
Zluri's primary advantage is coverage of the SaaS identity layer: the OAuth apps, integration tokens, SaaS automation users, and connected service accounts embedded in the 100+ SaaS applications an enterprise runs. Infrastructure-focused tools like ConductorOne and Veza govern cloud and on-premises NHIs but cannot see this layer. Zluri's integration fabric was built for SaaS-first environments, and it surfaces NHI types that other tools simply don't reach. Beyond discovery, Zluri's second differentiator is governance parity. NHIs go through the same access review engine, the same certification workflow, the same auto-remediation logic, and the same compliance reporting as human identities, within one unified platform.
What is the first step in building an NHI governance program?
Discovery. You need an accurate inventory of what non-human identities exist before you can govern them. Start by running discovery across your cloud IAM layers, Active Directory, and your SaaS application environment. Accept that the count will be larger than expected. Most organizations find three to five times as many NHIs as initially estimated. Once you have a baseline inventory, tier it by risk (privilege level, environment, last activity) and focus initial governance effort on the highest-risk accounts.
.svg)
