What Non-Human Identity Is and Why It Matters

Non-Human Identities (NHIs) act as digital gatekeepers for the automated world. They are the digital identifiers assigned to entities such as code, applications, services, and devices, enabling them to be authenticated by and access other resources without human intervention.

Human identities (e.g., employees, contractors, customers, partners) authenticate through interactive flows where credentials are presented in real time—passwords, passkeys, and biometrics, often combined via multifactor authentication (MFA) and federated via single sign-on (SSO). NHIs, on the other hand, authenticate programmatically using pre-issued credentials, operating independently and often autonomously, performing machine-to-machine (M2M) communications at massive speeds and volumes. In some cases, an NHI may also act on behalf of a human principal through delegated access. Industry research consistently shows that NHIs significantly outnumber human identities in modern enterprises. CyberArk research reports ratios of approximately 82:1, while other industry studies—such as Palo Alto Networks—indicate figures exceeding 100:1. This imbalance is expected to continue widening as organizations adopt cloud-native architectures, microservices, automation, and AI agents.

NHIs originate from software lifecycle events, not from business or organizational lifecycle events. Human identities are created, modified, and decommissioned through business-driven processes such as hiring, role changes, and termination, typically referred to as Joiner, Mover, and Leaver (JML) processes. In contrast, NHIs are created through technical events such as application deployment, infrastructure provisioning, workload startup, pipeline execution, autoscaling, agent invocation, and so on. Many NHIs originate from software and infrastructure lifecycle events rather than traditional business lifecycle events. However, some NHIs, such as device identities, may also be created and managed through asset onboarding, deployment, and decommissioning processes. This fundamental difference explains why traditional identity governance models, which rely on Human Resources (HR)-driven JML processes, do not naturally apply to NHIs.

It helps to draw a clear boundary around NHIs because modern environments contain many non-human entities and artifacts, not all of which are identities. In this document, an entity qualifies as an NHI only when it can authenticate (prove who it is) and be authorized (be granted permissions), either directly or indirectly, to access resources.

A common non-examples (to avoid confusion) is a configuration record (e.g., a CMDB entry for a server), which is not an identity unless it is used to authenticate or obtain entitlements. Other examples include:

• Metadata objects
• Code or scripts that do not authenticate
• Secrets, tokens, API keys, or certificates, unless they are bound to an identity

It is also helpful to acknowledge and differentiate between an NHI (also referred to as the identity subject or principal—both of which also apply to human identities) and a credential, which is often mislabeled as a non-human identity, leading to further confusion or ambiguity. While an identifier can be associated with a purpose and perform multiple tasks or actions, a credential specifically authenticates that identity for a particular task or action. As an example, a human identity may hold different physical identification documents, such as a passport and a driver’s license; however, only the driver’s license authorizes them to drive a vehicle. Similarly, an NHI may use an API key for one action and an OAuth token for another while fulfilling its purpose.

Security and IT professionals must distinguish between governance and management. Governance can be defined as a broad set of policies, accountability, and structures that provide proper control, audit, and security of the NHIs. It incorporates ownership identification, adherence, and continuous monitoring and auditing systems to identify possible threats or violations. NHI governance should be integrated into the organization’s Enterprise Risk Management (ERM) framework, mapping technical machine-access exposures to corporate risk registers to ensure that automated access vulnerabilities are identified, tracked, and managed as business risks.

Management is concerned with end-to-end steps throughout the lifecycle of the NHI (i.e., provisioning, maintenance, deprovisioning) while meeting the established policies. It encompasses the processes and systems that work together to provide, configure, monitor, and decommission NHIs throughout their lifecycle. Although the rules are established in governance, they must be put into practice in day-to-day management and operations. Identity management systems provide access controls and automate the process of issuing and decommissioning NHIs in accordance with the governance framework policies.

The size and magnitude of NHI management have been increasing exponentially, posing a major challenge to security and governance models. The increase in the use of cloud, containers, microservices, and automation technologies is the main factor driving the rapid growth of NHIs, which demand automated M2M communications.

While organizations have been advancing human identity management through a variety of tools glued together, over the past few years, non-human identity management has largely been a decentralized byproduct of software development and, at best, managed by individual application owners that treat the controls governing these NHIs as blockers instead of security enablers. As a result, NHIs have grown dramatically, often with inconsistent attention or oversight.
This boundary matters because governance controls apply to “actors with access,” not to everything non-human in the environment.

Considering NHIs has become essential when addressing the realities of contemporary enterprise operations due to the growing dependence on automation, cloud-based environments, and workflows that are quickly becoming powered by artificial intelligence (AI). Identities are employed in many manners, and they include controlling system-to-system communications and performing automated tasks, as well as providing and ensuring secure access to application resources and, in most cases, not directly involving human interactions.

NHI Classification Framework: Identity Subject vs. Authentication Mechanism

To reduce ambiguity in the discussion of NHIs, it is helpful to be specific in definitions. A helpful distinction separates the binding entity (the identity subject) from the credential mechanisms (authentication). This practical approach separates what the identity represents from how it proves its legitimacy, ensuring clearer governance and more consistent security controls.

Identity Subject

The identity subject, or what the identity is bound to¹, describes the entity that the identity represents, including:

• Service and integration account identities (application principal)
• Workload and microservice identities (pod, service, function)
• Infrastructure identities (instance, node)
• Device identities (hardware, firmware, Internet of Things (IoT))
• Agent identities (autonomous actor, including AI)

The identity subject determines who or what is requesting access, thereby driving governance requirements, ownership, lifecycle expectations, and entitlement needs.

Note that several subject types can act on behalf of a human principal through delegated access. In such cases, the NHI’s actions should be scoped by the human’s permissions to avoid misuse as well as reflected transparently in the form of delegator, intent, and actions on the audit logs to retain accountability.

Authentication Mechanism

The authentication (credential) mechanism, or how the identity proves itself², is used by the identity subject to authenticate. Common authentication mechanisms include:

• Static secret (password, API key, SSH keys)
• Signed token (JWT/OIDC, SAML assertion, LOAS)
• Certificate (X.509, SPIFFE SVID)
• Hardware-backed or attestation-backed credentials (Trusted Platform Module (TPM), Hardware Security Modules (HSM), secure element)
• Cloud-native session credentials (STS-style temporary creds)

This dimension defines how the identity asserts trust, influencing security strength, rotation policies, renewal automation, and cryptographic requirements.

Why This Separation Matters

Organizations frequently conflate the identity subject (the entity or actor) with the authentication mechanisms (e.g., tokens, keys, certificates) used to verify them, treating API keys, tokens, or certificates as if they are the identity. In practice, these are simply authentication mechanisms. The identity subject is the actual actor, and a single identity subject may use multiple authentication mechanisms throughout its lifecycle.

For example, a Kubernetes workload may:

• Use OIDC tokens to access cloud APIs
• Use mTLS certificates for service‑to‑service communication

Although these are different types of credentials, they both authenticate the same underlying workload identity.

Note: In some environments, the same service account or API key may be shared across multiple services or applications. While this is a common operational pattern, it is generally not recommended because it reduces traceability and makes it harder to determine which specific service performed an action. For stronger accountability and auditing, identities should ideally be unique to a single service or workload.

Practical Outcome

By classifying NHIs across these two axes, organizations improve visibility, reduce mismanagement of credentials, and strengthen overall identity governance:

• Governance decisions such as ownership, lifecycle management, access scopes, and entitlements should be anchored to the identity subject and policies driven by context

• Security controls such as credential strength, rotation frequency, token issuance and management, and renewal policies should be tailored to the credential mechanism

How They Fit Together

Service and Integration Account Identities (application, service principal)

These are the “legacy” workforce of automation. They are typically long-lived accounts used to enable third-party integrations (e.g., a Salesforce connector) or automate background tasks for on-premises servers.

• Characteristics: Often use static credentials (e.g., API keys, username and password); rarely rotated; high risk of “secret sprawl” in code

• Primary Governance Challenges: Stale principals and non-expiring or long-lived credentials that are no longer in use, were never decommissioned, and may be still active. Additionally, identifying the human owners accurately and appropriately to transfer ownership when the current owners leave the organization (the “Orphaned Account” problem)

Workload and Microservice Identities (pod, service, function)

The identity of the application code running inside a container or cluster. This is the standard for modern east-west traffic (i.e., service-to-service and broker-mediated communication, including asynchronous event-driven patterns).

• Characteristics: Highly ephemeral; managed by orchestration platforms (e.g., Kubernetes service accounts) or identity fabrics (e.g., SPIFFE/SPIRE)

• Primary Governance Challenges: Establishing clear ownership, lifecycle management, and authorization and accountability for these highly ephemeral identities at scale; thousands of them may be created and destroyed in minutes, overwhelming traditional audit log

Infrastructure Identities (instance, node)

Identities assigned to the compute resources themselves rather than the software running on them. This includes virtual machines (VMs) and cloud instances.

• Characteristics: Provisioned by the cloud provider (e.g., AWS Instance Profile, Azure Managed Identity); tied to the lifecycle of the infrastructure resource

• Primary Governance Challenges: Ensuring these identities are destroyed immediately when the infrastructure is decommissioned to prevent “ghost resources”

Device Identities (hardware, firmware, IoT)

Identities tied to physical devices across both Operational Technology (OT) and Information Technology (IT) environments, from industrial sensors to smart office equipment.

• Characteristics: Constrained by hardware limitations (e.g., may not support complex encryption); often deployed in hostile physical environments

• Primary Governance Challenges: Scale and updateability; rotating keys on a fleet of 50,000 remote sensors without “bricking” them is operationally difficult

Agent Identities (autonomous actor, including AI)

The newest and fastest-evolving class of NHI. Unlike static scripts, AI agents powered by large language models (LLMs) can reason, plan, and execute complex chains of tasks independently.

• Characteristics: Non-deterministic behavior; may possess “delegated authority” to act on behalf of a human user

• Primary Governance Challenges: Agent impersonation, excessive action authority and scope creep. As an example, an agent authorized to “read calendar” might autonomously decide to “send invites” if not strictly scoped. Multi-step chaining has become an acute risk that is particularly exacerbated by agent privileges. Additionally, audit logs often lack complete attribution across delegator, agent, intent, and actions, creating gaps in accountability and traceability

Why NHI Risks Differ from Human Identity Risks

NHIs introduce risks that can differ from human identity risks. These identities are often created through systems and automation, not through business processes. They often operate continuously and without direct human oversight. A human user’s slower cadence—reading a screen, clicking through a workflow, pausing between actions—creates natural opportunities to notice mistakes before they compound. An NHI executing thousands of operations per second offers no such window, so misconfigurations and compromises propagate faster than detection or response can keep up.³

Traditional identity governance relies on clear lifecycle events such as hiring, role changes, and termination. These signals do not exist in the same way for many NHIs. As a result, gaps emerge in ownership, lifecycle management, and visibility. These gaps directly impact security.

NHIs often have persistent and broad, high-privileged access across systems. When these identities are misconfigured or compromised, they can enable unauthorized access, data exposure, and lateral movement. As organizations adopt distributed architectures, automation, and AI-driven systems, the scale and impact of these risks continue to grow.

Table 1 summarizes the key risk areas, their description, and the resulting impact.

Table 1: NHI Key Risk Areas

Benefits of Automated NHI Lifecycle Management

We recommend several different and varied, though integrated, best practices for governing and managing NHIs.⁴

• Reduced Attack Surface: Short-lived tokens, along with frequent rotation and timely event-driven revocation, help prevent credential theft by removing stale and “orphaned” credentials, thereby reducing the blast radius of compromised credentials. Together with automated decommissioning, it ensures that when a project ends or a task is retired, the NHI and associated credentials are revoked, addressing both credential and identity exploitation

• Least Privilege Enforcement: Continuous monitoring identifies credentials that haven’t been used recently and automatically marks them for decommissioning. It also ensures that the permissions are adjusted and the NHI does not “collect” permissions over time as new features are added (privilege creep). Additionally, automated entitlement reviews prevent active NHIs from collecting excessive permissions over time

• Compliance: Maintains a near real-time, provable list of every NHI accessing your data and associated privileges, along with audit trails, which are required by relevant standards and governance frameworks like SOC2, ISO 27001, GDPR, HIPAA, and NIST

• Forensic Readiness: Automated lifecycle management and continuous monitoring deliver precise timelines of NHI creation, access history, and expiration, drastically reducing Mean Time to Resolution (MTTR) during forensic investigations

• Operational Efficiency and Uptime Reliability: Allows self-service provisioning of identities, eliminating manual ticketing processes. Automated credential rotation or renewal processes prevent “human error” in security and DevOps teams that can occasionally lead to accidental system outages

• Cost Optimization: Reduces cost and operational expenses by automatically discovering and deleting “orphaned” NHIs

• Metrics and Reporting: All automation benefit claims should be accompanied by measurement targets (e.g., a defined false-negative rate bound for credential anomaly detection, validated against injected-anomaly test scenarios). This is especially critical for agent identities, whose non-deterministic behavior makes baseline drift detection harder to validate⁵

Proposed Practices

This paper outlines four practical, interconnected best practices for managing and governing NHIs.

Practice 1: Differentiate by Lifecycle Phases

Identity lifecycle management systems have existed for decades, originating in the mid-to-late 1990s as directory services such as Lightweight Directory Access Protocol (LDAP) and Microsoft Active Directory. These systems have since then evolved into Identity Management (IdM) tools that govern access to different systems and applications. They have also evolved from standalone on-prem services to automated end-to-end lifecycle management SaaS solutions that are more comprehensive and sophisticated and focused on a better user experience through AI and chatbots. However, these systems have primarily been centered around humans and HR processes (hiring, job transfers, or termination) to manage their lifecycle through JML events.

NHIs, on the other hand, do not have an associated HR process and they do not align to traditional IdM systems, thereby creating significant gaps and consequent security risks. A significant portion of them are created by developers or through automation scripts on various platforms and systems across hybrid-cloud, SaaS, and on-prem environments, often with little or no oversight, leading to “shadow” identities that lack visibility or adequate governance. To prevent this, organizations should establish a governance checkpoint during application onboarding that requires ownership assignment and lifecycle requirements for NHIs to be defined before production deployment. Consequently, these are frequently created without due diligence, granted broader privileges than necessary to avoid disrupting automated processes, rarely adjusted or downgraded appropriately to maintain their least-privileged standing, or decommissioned.

• Policy Definition and Ownership Model: Define the policy framework that governs NHI creation, scope, rotation, attestation, and decommissioning. Establish ownership rules (such as business vs. technical owners), distinct from any human responsible, accountable, consulted, and informed (RACI) models. As part of application onboarding, require teams to document NHI ownership, permitted usage, and lifecycle controls before identities are provisioned. This foundation enables organizations to accurately identify drift, classify risk, and prioritize actions based on business impact.

• Discovery, Classification, and Ownership: Continuously identify all existing and new NHIs and their associated credentials (e.g., tokens, keys, certificates) across cloud, SaaS, and on-premise environments to build an inventory. Categorize them by their purpose, role, permissions, resources, and dependencies to assess risk scores and then classify them based on these risk scores into different tiers to help with appropriate prioritization. Additionally, identifying a human “owner” or team and transferring ownership appropriately is critical to ensure accountability

• Provisioning and Access Control: Provision NHIs with least-privilege access aligned with its intended purpose—based on generation templates as applicable—and permissions scoped to specific resources or services. Create ephemeral credentials where possible, that are short-lived and expire automatically after a specified duration or immediately after the task is complete. Additionally, ensure that the permissions are adjusted periodically through automated entitlement reviews so that the NHI does not “collect” permissions over time as new features are added

• Active Monitoring and Intervention: Continuously log all activities and transactions, monitor usage patterns for anomalies, and automatically revoke possibly compromised credentials or rotate them based on such patterns and security policies to limit the opportunity for bad actors based on risk severity. For agent-driven actions, it’s worth capturing the invoking identity—who authorized the actions and a note of intent—so audits can confirm activity matches that were allowed and quickly spot unusual behavior

• Decommissioning and Offboarding: Offboarding NHIs safely and appropriately is critical and done by revoking active tokens and deactivating or deleting stale and orphaned identities when they are no longer needed, such as after a task completes, a project ends, or an application has been decommissioned

The following table summarizes how the four lifecycle phases apply across the five different types of NHIs. (See Appendices C and D for more detail.)

Table 2: Types of NHI by NHI Lifecycle Phase

Practice 2: Develop New Detection and Response Capabilities

NHIs have grown exponentially in recent years, but in addition to their massive scale, they often perform highly critical functions across cloud services, infrastructure, and third-party integrations, as well as autonomous AI agents. However, unlike human users, who may access systems predictably from specific locations, either by IP or geography, or at a certain time of day, NHIs do not exhibit such physical behavior patterns that can be detected. Identity Threat Detection and Response (ITDR) systems orDetection and Response (D\&R) often detect misuse through these physical behaviors and determine incidents such as “impossible travel”—patterns that are centered around humans, but not for an NHI. NHIs are becoming a prime target for attackers as they can operate without triggering traditional ITDR systems. Therefore, it is not enough to maintain an inventory of NHIs or categorize them into tiers, they also need continuous monitoring and near-real-time detection to protect them from attackers.

Non-Human Identity Threat Detection and Response (NHITDR) is an extension of the traditional ITDR cybersecurity framework, specifically designed to monitor and secure NHI identities by detecting “behavioral drift” and unauthorized privilege expansion. The core capabilities of an NHITDR include the following:

• Continuous Detection and Discovery: Identify new NHIs automatically to keep the inventory updated and alert the relevant security teams for further classification

• Building Identity Graphs: Map the complex, interconnected relationships among NHIs, their human owners, and the resources they access—including assumed-role chains and delegated trust relationships that create transitive privilege escalation paths—into specialized data models (identity graphs) rather than static list-based inventories, thereby reducing the risk of “shadow” NHIs and their associated permissions

• Behavioral Baselining: Establish a normal or expected activity baseline for all non-ephemeral NHI identities based on its defined purpose, generation template, usage patterns, and privileges (e.g., typical access duration, operations performed, resources requested or updated)

• Real-Time Detection: Flag and track NHI anomalies and deviations per policy (e.g., accessing customer data for the first time, executing suspicious updates, performing “vault dumps” or mass secret downloads). Analyze using identity graphs to identify the “blast radius” and the resources at risk

• Incident Response: Mitigate immediately upon detection by first revoking compromised tokens and access keys to sever attacker access, then isolating affected workloads and scoping the blast radius through identity graph traversal to determine the full extent of compromise. Automate and orchestrate recovery workflows, including issuance of replacement credentials, only after the environment has been verified as clean, with human validation retained for high-severity or ambiguous incidents to ensure fresh secrets are not introduced into a still-compromised context

  • Adopt a two-layer graph model that separates durable control-plane identities (e.g., ServiceAccounts, IAM roles, federated bindings) from volatile, time-decayed instance telemetry, ensuring that identity graphs remain computationally tractable in dynamic environments such as Kubernetes and serverless platforms. Because ephemeral workloads inherit—rather than mint—identities, anomaly detection and blast-radius analysis operate against a comparatively stable identity set, with bounded graph staleness kept below the minimum exploit window rather than requiring strong real-time consistency

Practice 3: Manage Ephemeral Credentials Differently from Static Credentials

Traditional authentication mechanisms for machine identities have included static service account passwords, shared secrets, and API keys, which are long-lived and often do not expire. Even today, it is not uncommon to come across service accounts with non-expiring passwords that were configured this way to avoid “outages.” These static credentials, however, pose a significant risk and “blast radius” because a security breach would allow an attacker to operate over long exposure windows until ITDR systems detect the incident and trigger any effective responses.

Ephemeral credentials are short-lived, dynamically generated secrets that automatically expire after a brief period or after a single use, thereby minimizing the window of time during which an attacker can use the stolen secret. They are also generally bound to a specific workload or context, which can restrict lateral movement if compromised.

There are various considerations for securing and managing each type of ephemeral credential:

• Static Secret (e.g., password, API key, SSH keys): Static secrets are the most common and historically prevalent credential type. They include passwords, API keys, SSH keys, connection strings, database credentials, and other long-lived secrets that remain constant until explicitly rotated. While convenient, they pose significant security risks due to their persistence

  • Vaulted Storage with Centralized Governance: Every static secret should be stored in a secure vault or secret manager to control and limit access. Enterprises often operate multiple vaults by design (e.g. across cloud-native, PAM systems, and application-specific stores), and may require an additional layer of centralized governance overseeing policy enforcement and auditing across vaults
  • Automatic Rotation for Security Purposes: Programmatically rotate the secret on schedule to remove stale and long-lived credentials and prevent credential theft. It also ensures that a leaked credential has a “shelf-life” and limits the opportunities for an attacker. Scheduled rotation shrinks the exposure window if a secret is compromised and removes orphaned credentials over time
  • Automatic Rotation for Operations Purposes: Proactively renew before expiry, automate propagation to all dependent consumers, validate that dependents have picked up the new credential before retiring the old one, and ensure rollback capability if propagation fails
  • Runtime Injection: Use sidecars or environment variables to inject secrets just-in-time to minimize the risk of leaks

• Signed Token (e.g., JWT/OIDC, SAML assertion): Signed tokens are cryptographic documents that contain identity claims, permissions, and metadata. They enable stateless authentication and authorization, allowing verifiers to validate tokens without contacting the issuer for each request. This makes them ideal for distributed microservice architectures

  • Short TTL: Set access tokens to expire quickly (e.g., a few minutes instead of hours) to minimize the attack window if they are leaked
  • Use Refresh Token Rotation (“Rolling”): Every time a refresh token is used to get a new access token, issue a new refresh token and invalidate the old one to prevent replay attacks. Ensure enough grace period is incorporated to prevent lockout conditions where a refresh token is already invalidated before a new one was received
  • Audience Validation: Ensure the token is only accepted by the specific service it was intended for
  • Asymmetric Signing: Use asymmetric keys for signing so the verifying service doesn’t need a shared key for validation
  • Limit Scope and Audience: Ensure tokens carry the minimum necessary permissions and are restricted to specific services only
  • Secure Storage: Store tokens in secure, encrypted locations or operating system key stores

• Certificate (e.g., X.509, SPIFFE SVID): Certificates provide cryptographic proof of identity through public key infrastructure (PKI). They bind an identity to a public key, enabling mutual authentication (mTLS) where both parties verify each other’s identity. Certificates are foundational for Zero Trust architectures and service mesh implementations. Use SPIFFE/SPIRE to issue SVIDs, or use Certificate Lifecycle Management (CLM) platforms and cloud-managed CA services such as AWS Private CA, Google Cloud CA Service, or Azure Key Vault to support high-volume programmatic issuance without manual intervention. Short-lived certificates reduce operational reliance on complex certificate revocation mechanisms, including certificate revocation lists (CRLs), because compromised or expired certificates are replaced frequently and remain valid only for limited periods

  • Automated Renewal: Use ACME protocols with automated certificate issuance tools or orchestration tools like cert-manager to handle rotations without human intervention
  • Protect the Private Key: Ensure the private key is generated, used, and then immediately discarded from memory upon session end

• Hardware-Backed Attestation (e.g., TPM, HSM, secure element): Hardware-backed or attestation-backed credentials are identity credentials that derive their trust from or are cryptographically bound to hardware attestation. Unlike simple hardware-stored credentials, these tamper-resistant cryptographic credentials incorporate proof of the hardware and software environment, enabling relying parties to verify not just identity but also platform integrity. The fundamental security assurance relies on private keys being generated within the secure hardware boundary and never leaving it

  • Platform Attestation: Before issuing a credential, require a “quote” (a cryptographically signed snapshot of a machine’s current state that allows a remote server to confirm that the OS running on the machine is authentic) from the TPM to prove that the OS hasn’t been tampered with
  • Non-Exportable Keys: Generate keys inside the TPM/HSM module so they can be used but never extracted
  • Execution Context Verification: Before granting access, organizations should verify that the workload, container, VM, or device using the identity is operating in a trusted and expected environment. A valid identity alone may not be sufficient if the underlying execution environment has been compromised. Combining identity verification with platform attestation and workload integrity checks can help reduce the risk of compromised systems continuing to operate with legitimate credentials.

• Cloud-Native Session Credentials (STS-style temporary creds): Cloud-native session credentials are temporary credentials issued by cloud identity services, typically through Security Token Service (STS) or an equivalent mechanism

  • Identity Federation: Use workload identity federation (WIF) and token “exchange” to translate an identity token for a short-lived temporary access token. It is well supported by all major cloud providers like AWS, Azure and GCP, and emerging on other third party applications. However, securing WIF requires protecting the upstream identity token through token audience binding, short TTLs and pipeline secret scanning to avoid being stolen and misused
  • No Long-Term Keys: Use IAM Roles that provide short-lived session tokens automatically. Most major cloud providers offer SDKs on the workload that can call a metadata service to request granularly defined temporary credentials through their Security Token Service (STS). It also automatically refreshes these credentials before they expire to maintain access

Practice 4: Define a Standards-Based Framework

Define and operationalize a framework to ensure you are properly governing and managing your NHIs, built on standard patterns and frameworks. Some of these are well established like SPIFFE, while others like WIMSE and SPICE are actively emerging.

• Secure Production Identity Framework for Everyone (SPIFFE): The Secure Production Identity Framework for Everyone (SPIFFE) defines a set of open-source specifications for providing verifiable identities to software workloads across heterogeneous environments through three components—A unique, URI-formatted name for a workload (SPIFFE ID), a verifiable credential (SPIFFE Verifiable Identity Document or SVID), typically an X.509 certificate or a JWT, that carries the SPIFFE ID and the SPIFFE Workload API. A workload calls the local SPIFFE Workload API to request for a credential once node attestation is completed through its native cloud metadata service and registered

• Workload Identity in Multi-System Environment (WIMSE): WIMSE is an actively emerging initiative that aims to standardize how software workloads (containers, microservices, etc.) identify, authenticate, and trust one another across diverse cloud and on-premises platforms. WIMSE aims to establish a set of token translation rules for JSON Web Tokens (JWTs), SPIFFE IDs, mTLS certificates, and Remote Attestation Tokens (RATS) to enable clean interoperability. It also focuses on continuous, fine-grained verification, allowing identities and security contexts to be safely propagated and re-authenticated downstream across an entire service chain, rather than the traditional authentication model, where identities are verified only once at the edge during login or the initial use of a credential

• Secure Patterns for Internet Credentials (SPICE): SPICE aims at standardizing digital credentials through a three-party model (Issuer, Holder, and Verifier) to ensure they are secure, privacy-preserving, and interoperable across different systems. It uses modern cryptographic formats like JOSE (JSON Object Signing and Encryption), COSE (CBOR Object Signing and Encryption), and JSON Web Proof (JWP) format to allow creation of verifiable claims by revealing only the specific pieces of information needed (selective disclosure) without exposing its root infrastructure details or full signing keys—allowing an NHI to perform a multi-hop autonomous task with cryptographically linked machine assertions. This allows the end verifier to confirm an unbroken, fully authorized sequence of events from start to finish

NHI Governance Implementation and Deployment

The following three-phase plan is an example of how NHI governance can be implemented and deployed.

Phase 1: Foundation

The foundation phase establishes the infrastructure, processes, and policies required for effective NHI governance.

• Discovery and Inventory: The initial priority is to comprehensively identify all NHIs across cloud, on-premises, and hybrid environments—including service accounts, API keys, machine identities, and other non-human credentials

• Baseline Policy Development: Minimum security policies must be established to cover least-privilege access, credential rotation schedules, and secrets scanning within CI/CD pipelines. Secret scanning ensures that sensitive credentials, such as API keys and service account tokens, are not exposed in code repositories or configuration files

• Ownership Assignment: Every new NHI must be assigned a designated owner during creation and made accountable for its lifecycle and security posture. Existing NHIs must be categorized based on their risk and ownership validated iteratively starting with those having critical and high risks. Unowned identities represent immediate governance gaps

• High-Risk Remediation: NHIs with excessive privileges or elevated risk profiles must be prioritized for immediate remediation—rotating stale credentials, tightening access controls, and eliminating unnecessary privileged identities

• Emerging Identity Types: The governance framework must be extensible to accommodate AI agents and other emergent non-human entities. As AI systems become embedded in organizational operations, their identities require the same governance rigor as traditional NHIs. Agentic identities are currently the fastest growing category with the least defined guardrails

Phase 2: Automation

The automation phase focuses on reducing manual processes by automating the provisioning, management, monitoring, and protection of NHIs throughout their lifecycle.

• Centralized Secrets Management: Modern NHI automation aims to eliminate static keys altogether and should ensure Workload Identity Federation and short-lived, secretless credentials. Moving toward ephemeral, dynamic identities is the true end-state of automated NHI lifecycle governance, as it makes traditional rotation unnecessary. If you must maintain static NHI credentials, migrate all of them to vaults, such as AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault, to establish consistent access controls and audit trails

• Automated Provisioning: New NHI creation must follow automated workflows that enforce established policies—including least privilege access and mandatory vault storage—ensuring a consistent security posture from the point of provisioning

• Automated Credential Rotation: Credential rotation must be automated on policy-defined schedules, eliminating reliance on manual processes and reducing the window of exposure from compromised credentials

• Security Information and Event Management (SIEM) Integration and Monitoring: NHI activity must be integrated with SIEM platforms to enable real-time monitoring, anomaly detection, and early identification of potential compromise indicators

Phase 3: Optimization

The optimization phase matures NHI governance through advanced controls, continuous validation, and forward-looking capability development.

• Just-in-Time (JIT) Access: Privileged NHI access must transition to JIT models, in which elevated permissions are granted only when required and automatically revoked upon completion, minimizing the duration of privileged exposure

• Secretless Authentication: Organizations should accelerate migration toward ephemeral, short-lived tokens and certificate-based authentication, eliminating long-lived credentials that represent persistent attack surfaces

• Behavioral Analytics: Continuous validation of NHI behavior through machine learning and advanced analytics enables the detection of suspicious access patterns and anomalous activity, providing an adaptive security layer aligned with Zero Trust principles of continuous verification

• Continuous Compliance Reporting: Real-time compliance dashboards must be operationalized to support audit readiness, regulatory requirements⁶, and board-level security reviews, ensuring ongoing visibility into NHI governance posture

Conclusion

The landscape of enterprise cybersecurity has reached a critical inflection point where NHIs vastly outnumber and outpace human users, completely redefining the modern identity perimeter. As detailed throughout this document, traditional, human-centric IAM practices and HR-driven provisioning models are fundamentally mismatched with the speed, scale, and decentralized nature of software-driven lifecycles. Mitigating the persistent threats of over-privilege, static secret exposure, and orphaned access requires immediate programmatic intervention.

Current identity management tooling needs to be quickly evaluated as it is unlikely to manage a variety of NHIs. In addition, organizations must shift left by integrating automated discovery, robust identity mapping, and dynamic policy-based access controls into their core technology stacks. Crucially, by rigorously decoupling the identity subject from its underlying authentication mechanisms, enterprises can establish precise visibility and structural accountability over everything from microservices to autonomous AI agents. Putting these integrated governance frameworks into immediate practice allows enterprises to transform their non-human access layers from a hidden operational liability into a transparent, secure, and board-level priority—safeguarding the load-bearing infrastructure of the automated enterprise within a resilient Zero Trust environment.

Appendix A: Types of Entities where NHIs Exist

Table A: Types of Entities where NHIs Exist

Appendix B: Types of Credentials

Table B: Types of Credentials

Appendix C: Risks by NHI Type

NHIs introduce risk by providing machine-operated access to systems, data, and services without the governance controls typically applied to human users. These identities are widely used across cloud platforms, automation pipelines, third-party integrations, and AI systems, and they often operate continuously without direct human oversight.

The following two tables present the key risk areas associated with five types of NHIs: Service and Integration Account Identities, Workload and Microservice Identities, Infrastructure Identities, Device Identities, and Agent Identities. There are 14 risk areas, presented across two tables. Each row focuses on a specific NHI type, and each column describes how control weaknesses allow those identities to operate outside their intended ownership, lifecycle, access, or trust constraints. The risks described are independent of specific implementations or technologies. These risks are not exhaustive, do not reflect specific implementations or technologies, and do not indicate relative likelihood or severity. Risk conditions may overlap across identity types.

Table C-1: First 5 Risks of 15

Table C-2: Next 5 Risks of 15

Table C-3: Last 5 Risks of 15

This analysis shows that all NHI types introduce meaningful security risk, regardless of how they are implemented or where they operate. Risks such as hidden access paths, excessive privilege, persistent credentials, unclear accountability, and limited visibility consistently arise across service accounts, workload identities, automation identities, third-party integrations, and AI agents.

While the specific form of risk varies by identity type, the underlying pattern is consistent: NHIs can retain powerful access that is difficult to see, constrain, attribute, or retire. When control weaknesses are present, that access can persist beyond its intended scope, extend across systems, and remain undetected over time. Understanding these risks at the identity-type level provides a necessary foundation for assessing impact and selecting appropriate governance and mitigation strategies.

Appendix D: Impact by NHI Type

When NHIs operate outside their intended ownership, lifecycle, access, or trust constraints, the resulting consequences are shaped by the role, privilege level, and architectural position of the affected identity. Some NHI types amplify impact through broad permissions or control-plane access, while others extend exposure duration through limited observability or unclear accountability.

The following two tables describe the concrete impacts of these control weaknesses across the five NHI types. Due to the number of impact areas, they are presented across two tables.

The following tables describe the impacts associated with the 14 risk areas identified in Appendix C across five NHI types. They are not exhaustive, do not reflect specific implementations or technologies, and do not indicate relative likelihood or severity. Impacts may overlap across identity types.

Table D: Impacts of 15

These tables show that NHI risks and their impacts occur across all types of NHIs. The same core risks, such as lack of visibility, excessive privilege, weak attribution, and limited observability, consistently exist whether examining service accounts, API keys, workload identities, or AI agents. However, the consequences of those risks depend on how and where each identity operates within the environment.

Understanding NHI risk, therefore, requires distinguishing between the conditions that create exposure, how those conditions exist across NHI types, and the resulting impacts. This applies consistently across automation, cloud infrastructure, third-party integrations, and AI systems, and supports informed prioritization and governance decisions without conflating causes, effects, or solutions.

Appendix E: NHI Lifecycle Phases

Table E: NHI Lifecycle Phases

Note: Each phase’s artifacts must be periodically cross-validated against an independently produced ground-truth snapshot (e.g., a human-reviewed NHI inventory sample run in a controlled test environment) to verify the completeness and accuracy of NHI discovery, monitoring, and lifecycle management processes.

Appendix F: Metrics and Reporting

Governance Metrics

Effective NHI governance requires metrics that quantify coverage, accountability, and lifecycle management maturity:

• Inventory Coverage: Measures the percentage of NHIs discovered and cataloged, targeting greater than 95% of all known identities to ensure comprehensive visibility (and build a coverage program to continuously identify new and previously unknown identities, thereby adding to the known universe)

• Ownership Assignment: Tracks whether every NHI has a designated owner accountable for its full lifecycle—from provisioning through decommissioning. The target is 100%, as unowned NHIs become orphaned identities that evade governance controls

• Orphaned NHI Rate: Monitors identities that persist without active ownership or a valid business justification. The objective is elimination, as orphaned NHIs lack oversight and represent high-risk vectors for credential theft

• Certification Completion Rate: Measures the percentage of NHIs that undergo scheduled access reviews within prescribed cycles, aiming for above 98% to ensure entitlements are regularly validated against current business requirements

Security Metrics

Security metrics assess how effectively organizations protect NHI credentials and enforce least-privilege principles:

• Rotation Compliance: Tracks credentials rotated within policy-defined intervals, targeting 95% or higher to minimize exposure from stale or compromised credentials

• Vault Integration Rate: Measures credentials stored in centralized secrets management solutions such as AWS Secrets Manager or HashiCorp Vault, aiming for above 90% to ensure credentials are subject to consistent access controls and audit logging rather than being embedded in application code

• Least Privilege Compliance: Evaluates whether NHI entitlements conform to minimum-necessary access principles, targeting above 85% to limit the potential blast radius from credential compromise

• Mean Time to Detect (MTTD) and Mean Time to Remediate (MTTR): Quantify incident response effectiveness. The targets presented here are illustrative goals for mature NHI security programs and should be adjusted based on organizational risk, NHI criticality, and operational requirements. Target state goals, achievable with mature controls and aligned with emerging federal guidance, call for less than 24 hours for remediation to contain compromised identities before adversaries achieve lateral movement. CISA issued a binding operational directive (BOD) on June 10, 2026 that requires federal agencies to rethink their vulnerability management policies and requires 3-day patching for high risks and 60-day patching for low risks

• NHI Incident Trend Analysis: Tracks frequency and severity of NHI-related security incidents over time, indicating whether security controls are maturing or degrading

• NHI Dormancy and Attribution Rate: Tracks how many NHIs are inactive, and ensures every active account can be traced back to a specific application

• Tracking Inactivity: Measures how many accounts have a lastLogonTimestamp older than policy limits (e.g., 30, 60, or 90 days). This helps teams find and clean up unmonitored “zombie” accounts

• Tracking Ownership: Verifies that 100% of incoming requests map to a clear application name. Knowing exactly which application is using a credential stops teams from sharing a single account across multiple projects and gives clear visibility if an incident occurs

Operationalizing Metrics

Translating metrics into actionable intelligence requires three complementary mechanisms:

• Real-Time Dashboards: Aggregate data from secret vaults, SIEM platforms, IAM solutions, and CMDBs to provide a unified view of NHI posture, enabling continuous monitoring and risk identification without manual correlation across disparate systems

• Comprehensive Audit Records: Maintain immutable logs of all NHI lifecycle events—provisioning, access reviews, credential rotations, and security incidents—supporting both regulatory compliance reporting and post-incident forensic investigation

• Executive-Level Reporting: Distills operational metrics into board-level narratives that communicate NHI governance posture and residual risk in business terms, ensuring identity governance receives appropriate leadership attention as NHI-related breaches carry increasing material impact

Appendix G: Regulatory Alignment

Note: Mappings indicate alignment and do not guarantee certification.

Table G: Regulatory Alignment of Governance Practices

References

Birkholz, H., Thaler, D., Richardson, M., Smith, N., & Pan, W. (2023). Remote Attestation Procedures (RATS) Architecture (RFC 9334). Internet Engineering Task Force (IETF). https://doi.org/10.17487/RFC9334

Chandramouli, R., & Butcher, Z. (2023). A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments (NIST Special Publication 800-207A). National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207A.pdf

Chandramouli, R., Kautz, F., & Torres-Arias, S. (2024). Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines (NIST Special Publication 800-204D). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-204D

Cloud Native Computing Foundation (CNCF). (n.d.). SPIFFE/SPIRE: Secure Production Identity Framework for Everyone. https://spiffe.io/

CNCF TAG Security. (2020). SPIFFE/SPIRE Joint Security Assessment. https://tag-security.cncf.io/community/assessments/projects/spiffe-spire/

Cloud Security Alliance. (n.d.). CCM Video Series: IAM – Identity & Access Management [Video]. https://cloudsecurityalliance.org/artifacts/ccm-video-series-iam-identity-and-access-management

Cloud Security Alliance. (n.d.). CSA Blog: Identity [Blog search results]. https://cloudsecurityalliance.org/blog?search=Identity

Cloud Security Alliance. (n.d.). Identity and Access Management Glossary. https://cloudsecurityalliance.org/artifacts/identity-and-access-management-glossary

Cloud Security Alliance. (n.d.). Latest Research: Zero Trust [Publication search results]. https://cloudsecurityalliance.org/research/publications/?search=Zero+Trust\&locale=en

Cloud Security Alliance. (n.d.). Machine Identity in Cybersecurity and IAM. https://cloudsecurityalliance.org/artifacts/machine-identity-in-cybersecurity-and-iam

Cloud Security Alliance. (n.d.). Map the Transaction Flows for Zero Trust. https://cloudsecurityalliance.org/artifacts/map-the-transaction-flows-for-zero-trust

Cloud Security Alliance. (2024). The State of Non-Human Identity Security Survey Report. https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report

Cloud Security Alliance. (2024). Top Threats to Cloud Computing 2024. https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-2024

Cybersecurity and Infrastructure Security Agency (CISA). (2026, June 10). Binding Operational Directive 26-04: Implementation Guidance for Prioritizing Security Updates Based on Risk. https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk

Cybersecurity Dive. (2025, November 12). Shadow AI Is Widespread — And Executives Use It the Most. https://www.ciodive.com/news/shadow-ai-employee-trust-upguard/805352/

Cybersecurity Insiders. (n.d.). Non-Human Identity Management: Addressing the Gaping Hole in the Identity Perimeter. https://www.cybersecurity-insiders.com/non-human-identity-management-addressing-the-gaping-hole-in-the-identity-perimeter/

CyberArk. (n.d.). The Seven Types of Non-Human Identities to Secure. https://www.cyberark.com/resources/blog/the-seven-types-of-non-human-identities-to-secure

Dark Reading. (2025, September 11). The Growing Challenge of AI Agent & NHI Management. https://www.darkreading.com/cybersecurity-operations/growing-challenge-ai-agent-nhi-management

Digit.fyi. (2025, March 13). Machine Identities Now Outnumber Humans 40,000 to 1. https://www.digit.fyi/machine-identities-now-outnumber-humans-40000-to-1/

Forbes. (2025, March 5). OWASP’s Top 10 NHI Risks: A Wake-Up Call for Modern Cybersecurity. https://www.forbes.com/councils/forbestechcouncil/2025/03/05/owasps-top-10-nhi-risks-a-wake-up-call-for-modern-cybersecurity/

Google Cloud. (n.d.). Attribute Reference for IAM Conditions. Identity and Access Management (IAM) Documentation. https://docs.cloud.google.com/iam/docs/conditions-attribute-reference

Huang, K., Narajala, V. S., Yeoh, J., Ross, J., Lambe, M., Raskar, R., Harkati, Y., Huang, J., Habler, I., & Hughes, C. (2025). Agentic AI Identity and Access Management: A New Approach. Cloud Security Alliance. https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach

National Security Agency. (2021, February). Embracing a Zero Trust Security Model (Cybersecurity Information Sheet). U.S. Department of Defense. https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF

National Security Agency. (2023, March 28). NSA Releases Maturity Guidance for the Zero Trust Network and Environment Pillar [Press release]. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3695223/nsa-releases-maturity-guidance-for-the-zero-trust-network-and-environment-pillar/

National Security Agency. (2024, March 14). NSA Releases Guidance on Zero Trust Maturity Throughout the Application and Workload Pillar [Press release]. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3784301/nsa-releases-guidance-on-zero-trust-maturity-throughout-the-application-and-wor/

National Security Agency. (2024, July 10). NSA’s Final Zero Trust Pillar Report Outlines How to Achieve Faster Threat Response Time [Press release]. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3833594/nsas-final-zero-trust-pillar-report-outlines-how-to-achieve-faster-threat-respo/

Palo Alto Networks. (n.d.). 2026 Identity Security Landscape. IDIRA. https://www.paloaltonetworks.com/idira/idira-identity-security-landscape

Ramani, R. (2021, August 3). Threat Hunting With Kubernetes Audit Logs. Square Corner Blog. https://developer.squareup.com/blog/threat-hunting-with-kubernetes-audit-logs/

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207

Tetrate. (2022, May 19). NIST Standards for Zero Trust: The SP 800-204 Series. https://tetrate.io/blog/nist-standards-for-zero-trust-the-sp-800-204-series

![][image1]