Ninety-seven percent of non-human identities hold excessive privileges [Entro Security 2025 State of NHI Report]. Not a sampling error. Not a niche finding from a handful of startups. Entro analyzed production environments across industries and found that nearly every service account, API token, and automation credential carried permissions far beyond what the workload required. The ratio of machine identities to human identities in most enterprises now exceeds 50:1, with some sectors reaching 500:1 [ManageEngine 2026 Identity Security Outlook]. Your identity governance program almost certainly covers the 1. The other 50 sit outside it.
Auditors have started asking. PCI DSS 4.0.1 introduced explicit requirements for system and application account governance, effective March 31, 2025. NIST CSF 2.0 embeds non-human identity controls across its Protect and Govern functions. ISO 27001:2022 now treats human and non-human identities under the same governance discipline in Annex A 5.16. The regulatory signal is consistent: organizations that govern only human identities fail identity controls. The question auditors pose is straightforward: “Show me your inventory of non-human identities, their privilege levels, and your rotation evidence.”
Five governance requirements determine whether your NHI program produces clean audit evidence or generates findings. The first one trips up even well-resourced teams.
Non-human identity governance requires organizations to inventory, classify, and lifecycle-manage every service account, API token, certificate, and automation credential with the same rigor applied to human users. NHIs outnumber human identities 50:1 or higher in most enterprises, and 97% carry excessive privileges [Entro Security 2025]. Frameworks including PCI DSS 4.0.1, NIST CSF 2.0, and ISO 27001:2022 now mandate explicit NHI controls.
Why Do Non-Human Identities Create the Largest Governance Gap?
Non-human identities account for approximately 80% of identity-related breaches, yet most governance programs track only human users [CSO Online 2026]. The gap exists because NHIs originate from every team with deployment authority: engineering creates service accounts for CI/CD pipelines, operations provisions API keys for monitoring tools, data teams generate tokens for ETL workflows, and AI teams spin up credentials for autonomous agents. No single team owns the full inventory. GitGuardian’s 2026 State of Secrets Sprawl report found 28.65 million new hardcoded secrets in public GitHub commits in 2025 alone, a 34% increase year over year [GitGuardian 2026]. Each leaked secret represents an NHI credential outside governance scope. When auditors request your NHI inventory, the question tests whether your organization even knows what it has, not whether the controls work.
The Inventory Problem
Most organizations discover their NHI count during audit preparation, not before. A mid-market SaaS company running AWS, Azure AD, and four SaaS platforms typically has 3,000 to 8,000 NHIs across service accounts, OAuth tokens, API keys, service principals, and certificates. Manual inventory is not feasible at this scale. The Cloud Security Alliance’s 2026 State of NHI and AI Security survey found that more than 16% of organizations do not track the creation of new AI-related identities at all [CSA 2026 State of NHI and AI Security].
Who Owns NHI Governance?
Ownership ambiguity is the root cause of most NHI governance failures. Engineering creates the credentials. Security writes the policy. IT operations manages the infrastructure. Nobody consolidates the inventory. The Entro Security 2025 report found that 60% of NHIs are shared across multiple applications, creating single points of failure with no clear owner [Entro Security 2025]. Assign a single identity governance function, whether in security, IT, or GRC, with authority to enforce lifecycle policies across all NHI types.
Run a discovery scan across your identity providers (Azure AD, Okta, AWS IAM), secrets managers (HashiCorp Vault, AWS Secrets Manager), and CI/CD platforms (GitHub Actions, GitLab CI, Jenkins). Export every service account, service principal, API key, OAuth token, and certificate into a centralized inventory. Tag each NHI with its creating team, associated application, privilege scope, and last-used date. Flag any NHI with no activity in the last 90 days for decommission review. Present the inventory as your first audit evidence artifact.
What Do Compliance Frameworks Require for Non-Human Identity Controls?
Three major frameworks now contain explicit or embedded NHI governance requirements, and auditors test them with increasing specificity. PCI DSS 4.0.1 Requirements 7.2.5, 7.2.5.1, 8.6.1, 8.6.2, and 8.6.3 mandate unique credentials for system and application accounts, interactive login restrictions, and periodic access reviews based on targeted risk analysis [PCI DSS 4.0.1 Req. 7.2.5, 8.6.1-8.6.3]. NIST CSF 2.0 addresses NHI governance through its Protect function (PR.AA: Identity Management, Authentication, and Access Control) and its Govern function (GV.RR: Roles, Responsibilities, and Authorities), requiring organizations to manage workload identities with the same policy rigor as human accounts [NIST CSF 2.0 PR.AA, GV.RR]. ISO 27001:2022 Annex A 5.16 explicitly applies identity management requirements to non-human identities, and Annex A 5.18 extends access rights governance to service accounts and machine credentials [ISO 27001:2022 A.5.16, A.5.18].
PCI DSS 4.0.1: The Most Prescriptive Standard
PCI DSS 4.0.1 sets the clearest bar for NHI governance. Requirement 8.6.1 mandates unique credentials for every system and application account. Requirement 8.6.2 prohibits interactive login for these accounts except under documented, time-limited, management-approved exceptions. Requirement 8.6.3 requires regular rotation of passwords and passphrases for application and system accounts, with immediate rotation if compromise is suspected [PCI DSS 4.0.1 Req. 8.6.1-8.6.3]. Organizations processing cardholder data must produce evidence of all three controls. The targeted risk analysis under Requirement 7.2.5.1 determines your review frequency: quarterly reviews are the floor for high-privilege service accounts.
NIST CSF 2.0 and ISO 27001:2022
NIST CSF 2.0 takes a principles-based approach. The framework does not prescribe rotation schedules, but it requires documented governance of all identity types, continuous monitoring of access permissions, and real-time adjustment of privileges based on risk [NIST CSF 2.0 PR.AA]. ISO 27001:2022 closes the historical gap between human and machine identity governance. Annex A 5.16 treats all identities under one management standard, and auditors now test NHI controls during certification audits with the same rigor as GRC engineering practices applied to human accounts.
| Framework | NHI Requirement | Audit Evidence |
|---|---|---|
| PCI DSS 4.0.1 | Unique credentials, no interactive login, regular rotation [Req. 8.6.1-8.6.3] | Credential inventory, rotation logs, exception approvals |
| NIST CSF 2.0 | Governance of all identity types, continuous monitoring [PR.AA, GV.RR] | NHI policy document, access review records, monitoring dashboards |
| ISO 27001:2022 | Unified identity management for human and non-human [A.5.16, A.5.18] | Identity register, privilege justifications, lifecycle records |
| SOC 2 TSC | Logical access controls including service accounts [CC6.1, CC6.2, CC6.3] | Access review exports, provisioning/deprovisioning logs |
Map your NHI inventory against each applicable framework’s requirements. For PCI DSS 4.0.1, document unique credentials per account and verify zero interactive logins using authentication logs. For NIST CSF 2.0, produce a written NHI governance policy and quarterly access review records. For ISO 27001:2022, add NHIs to your identity register with the same fields used for human users: owner, purpose, privilege scope, creation date, and last review date. Store all evidence in your API-driven evidence collection system for automated retrieval during audits.
How Should You Build the NHI Lifecycle from Provisioning to Decommission?
The Entro Security 2025 report found that 91% of former employee tokens are never revoked and 71% of NHIs are not rotated within recommended timeframes [Entro Security 2025]. These two statistics reveal the core lifecycle failure: organizations provision NHIs on demand but never build the decommission and rotation processes. A service account created for a deployment three years ago still holds production database credentials because nobody tracks its lifecycle. The Cloud Security Alliance’s 2026 survey confirmed the pattern: 78% of organizations lack documented policies for creating or removing AI identities [CSA 2026 State of NHI and AI Security]. Building the lifecycle means treating every NHI as a managed asset with a birth, a purpose, periodic reviews, and a planned retirement.
Provisioning with Purpose
Every NHI needs a creation record: who requested it, what application it serves, what minimum privilege it requires, and when it expires. Tie provisioning to a ticket or change request in your ITSM system. This creates the audit trail auditors request under continuous compliance monitoring programs. Enforce least privilege at creation: start with zero permissions and add only what the workload requires. PCI DSS 4.0.1 Requirement 7.2.5 requires documented justification for every NHI’s access scope [PCI DSS 4.0.1 Req. 7.2.5].
Rotation and Credential Hygiene
Static, long-lived credentials are the single highest-risk NHI pattern. GitGuardian found that secrets leaked in 2022 still had a validity rate above 64% when retested in January 2026 [GitGuardian 2026]. Replace long-lived API keys and passwords with short-lived tokens or certificates wherever your infrastructure supports it. For credentials that must remain static, enforce rotation at 90-day intervals for standard accounts and 30-day intervals for accounts with access to sensitive data or production databases. Document every rotation event with timestamp, account identifier, and responsible team.
Decommissioning and Zombie Credential Elimination
Zombie credentials, NHIs tied to decommissioned applications, departed employees, or completed projects, represent the most exploitable identity class. The Internet Archive breach in October 2024 exploited unrotated access tokens tied to its Zendesk support platform [Aembit 2025 NHI Breach Analysis]. Build an automated decommission trigger: when an application is retired, when an employee with sole ownership leaves, or when an NHI shows zero activity for 90 days, the credential enters a decommission workflow. Disable first, delete after a 30-day grace period, and log both actions.
Build three lifecycle artifacts for your auditor. First, a provisioning policy requiring ITSM tickets, least-privilege justification, and expiration dates for every NHI. Second, a rotation schedule documenting 90-day (standard) or 30-day (sensitive) rotation intervals with automated alerts at 75% of interval. Third, a decommission report showing all NHIs disabled in the last quarter, the trigger event (application retirement, employee departure, inactivity threshold), and the disable/delete timestamps. Store rotation evidence and decommission logs in your GRC platform for compliance-as-code enforcement.
AI Agents and Machine-Speed Identity Proliferation
AI agents converted NHI risk from a static governance challenge into a machine-speed execution problem in 2025 [Cyber Strategy Institute 2026 NHI Reality Report]. An autonomous AI agent performing code reviews, data analysis, or customer interactions requires its own credentials, often with broad API access across multiple systems. The CSA 2026 survey found that 92% of respondents lack confidence in their legacy IAM solutions’ ability to manage NHI and AI identity risks [CSA 2026 State of NHI and AI Security]. AI-service secret leaks surged 81% year over year in 2025, with 1.275 million AI-service secrets detected on public GitHub [GitGuardian 2026]. Every agent framework, whether LangChain, AutoGen, or CrewAI, generates credential requirements that traditional IAM systems were never designed to handle. Organizations deploying AI agents without NHI governance controls are creating identity sprawl at a rate no manual review process will contain.
The Agent Credential Chain
A single AI agent workflow might require an LLM API key, a database connection string, an object storage credential, and OAuth tokens for three SaaS integrations. Each credential represents an NHI. A team running ten agent workflows creates 50 to 70 new NHIs in a week. Without governance, these credentials accumulate with no owner, no rotation schedule, and privileges inherited from the developer’s personal access level rather than scoped to the agent’s actual needs.
Governance Controls for AI Agent NHIs
Apply the same lifecycle governance to AI agent credentials as to any other NHI, with two additions. First, require a delegation scope document for every agent: what systems the agent accesses, what actions it performs, and what data it reads or writes. This becomes the privilege justification your auditor requests. Second, enforce session-scoped credentials wherever possible. An agent performing a 30-minute data pipeline run should receive a token valid for 45 minutes, not a permanent API key. The Cyber Strategy Institute’s 2026 report predicts that regulators will demand explicit NHI governance evidence for AI agents within the next 12 months [Cyber Strategy Institute 2026 NHI Reality Report].
Create an AI agent NHI register separate from your general NHI inventory. For each agent workflow, document the agent name, owning team, every credential the agent uses, each credential’s privilege scope, the delegation scope (what the agent is authorized to do), and the credential expiration policy. Review agent NHIs weekly during rapid deployment phases and monthly during steady state. Implement session-scoped tokens using your secrets manager’s dynamic secrets feature (HashiCorp Vault dynamic secrets, AWS STS temporary credentials). Disable any agent credential not used in the last 14 days.
What Audit Evidence Do You Need for NHI Governance?
Auditors requesting NHI evidence follow a predictable pattern: inventory, then policy, then lifecycle proof, then exception management. The 79% of organizations that rated their NHI attack prevention confidence as low or moderate in the CSA 2026 survey share a common trait: they produce human identity evidence on demand but scramble when auditors pivot to service accounts and API tokens [CSA 2026 State of NHI and AI Security]. Building the evidence package before the audit starts converts NHI governance from a finding generator into a control strength. Every artifact maps to a specific framework requirement, and most artifacts serve multiple frameworks simultaneously, which is the core efficiency of a mature GRC engineering practice.
The Five-Artifact Evidence Package
Your NHI audit evidence package needs five artifacts. First, a complete NHI inventory with owner, application, privilege scope, creation date, and last-activity date for every identity. Second, a written NHI governance policy covering provisioning, rotation, access review, and decommissioning. Third, rotation logs showing credential changes with timestamps, the old credential hash (not the credential itself), and the responsible team. Fourth, quarterly access review exports demonstrating privilege validation against the least-privilege standard. Fifth, an exception log documenting every interactive login by a service account, every rotation delay, and every privilege escalation, with management approval and time-bound remediation.
Automating Evidence Collection
Manual evidence collection fails at NHI scale. An organization with 5,000 NHIs cannot produce quarterly access review evidence through spreadsheets. Use your identity provider’s API to export access review data directly into your GRC platform. Configure your secrets manager to log rotation events to a centralized SIEM. Build automated alerts for NHIs approaching rotation deadlines. The goal: when your auditor requests NHI evidence, you pull a report, not assemble a binder. GitGuardian’s research found that manual secrets management costs organizations $172,000 or more annually per 10 developers [GitGuardian 2026]. Automation pays for itself in audit preparation time alone.
Build your NHI evidence pipeline in four steps. First, connect your identity providers (Azure AD, Okta, AWS IAM) to your GRC platform via API for automated inventory sync. Second, configure your secrets manager to forward rotation events to your SIEM or log aggregator with structured fields: account ID, rotation timestamp, initiating process, and success/failure status. Third, schedule quarterly NHI access reviews in your GRC platform with automated owner notifications and escalation for non-response. Fourth, create a standing exception log template in your ITSM system for documenting any deviation from NHI policy (missed rotation, interactive login, privilege escalation) with required fields for business justification, approval authority, and remediation deadline.
Non-human identity governance is the identity control auditors check next. Organizations governing only human identities operate with a 2% visibility window while 98% of their identity surface sits unmanaged. The frameworks have caught up: PCI DSS 4.0.1, NIST CSF 2.0, and ISO 27001:2022 all require explicit NHI controls. Build the inventory, enforce the lifecycle, automate the evidence, and NHI governance becomes a control strength rather than the finding that derails your audit timeline.
Frequently Asked Questions
What is non-human identity governance?
Non-human identity governance is the practice of inventorying, classifying, lifecycle-managing, and auditing every machine credential, including service accounts, API tokens, certificates, OAuth tokens, and CI/CD secrets, with the same policy rigor applied to human user accounts. NHIs outnumber human identities 50:1 or higher in most enterprises [ManageEngine 2026 Identity Security Outlook], making governance at scale a prerequisite for passing identity-related audit controls.
How many non-human identities does a typical enterprise have?
Most enterprises operate 50 to 100 NHIs for every human identity, with some sectors reporting ratios as high as 500:1 [ManageEngine 2026 Identity Security Outlook]. A mid-market company with 500 employees might maintain 25,000 to 50,000 service accounts, API keys, tokens, and certificates across cloud providers, SaaS platforms, and CI/CD pipelines.
Which compliance frameworks require NHI controls?
PCI DSS 4.0.1 mandates unique credentials, rotation, and access reviews for system accounts under Requirements 7.2.5 and 8.6.1-8.6.3 [PCI DSS 4.0.1]. NIST CSF 2.0 requires governance of all identity types through its Protect and Govern functions [NIST CSF 2.0 PR.AA, GV.RR]. ISO 27001:2022 Annex A 5.16 applies identity management to non-human identities explicitly [ISO 27001:2022 A.5.16]. SOC 2 TSC CC6.1 through CC6.3 cover logical access controls for all account types, including service accounts.
Non-human identity governance vs. privileged access management: what is the difference?
Privileged access management (PAM) controls elevated access for specific high-risk accounts, both human and machine. Non-human identity governance covers the full lifecycle of every machine credential: discovery, provisioning, classification, rotation, access review, and decommissioning. PAM is one control within NHI governance, focused on the highest-privilege subset. NHI governance addresses the 97% of machine identities with excessive privileges that PAM solutions alone do not inventory or lifecycle-manage [Entro Security 2025].
How often should organizations rotate NHI credentials?
Organizations should rotate standard NHI credentials every 90 days and sensitive or production-database credentials every 30 days, with immediate rotation upon suspected compromise [PCI DSS 4.0.1 Req. 8.6.3]. Short-lived tokens (under 60 minutes) are preferable to static credentials wherever infrastructure supports them. GitGuardian found that secrets leaked in 2022 retained a 64% validity rate when retested in January 2026 [GitGuardian 2026], proving that most organizations fail to rotate even known-compromised credentials.
How do AI agents affect non-human identity governance?
AI agents create NHIs at machine speed, with each agent workflow generating five to seven new credentials for LLM APIs, databases, storage, and SaaS integrations. AI-service secret leaks surged 81% year over year in 2025 [GitGuardian 2026]. The CSA 2026 survey found that 78% of organizations have no documented policies for creating or removing AI identities [CSA 2026], making AI agents the fastest-growing source of ungoverned NHIs.
What audit evidence do auditors request for NHI governance?
Auditors request five core artifacts: a complete NHI inventory with owner and privilege scope, a written NHI governance policy, credential rotation logs with timestamps, quarterly access review exports showing privilege validation, and an exception log documenting any policy deviations with management approval. These artifacts map directly to PCI DSS 4.0.1 Requirements 7.2.5 and 8.6.1-8.6.3, NIST CSF 2.0 PR.AA, and ISO 27001:2022 A.5.16 and A.5.18.
Get The Authority Brief
Weekly compliance intelligence for security leaders. Frameworks decoded. Audit strategies explained. Regulatory updates analyzed.
