Executive Summary 
NHIs power automation but pose significant risks if ungoverned. Industry experts across the board suggest that we treat them like human identities—discover, govern, and monitor them. 
​ 
What Are Non-Human Identities?
​ 
Non‑human identities (NHIs) are digital identities, actors and credentials assigned to non‑person entities so they can authenticate, be authorized, and interact with systems, data, and services without manual human input.  
Unlike human identities, NHIs are machine‑operated, often long‑lived, and typically used in high‑volume, automated workflows that underpin cloud, API, and microservices architectures. 
These identities often proliferate silently as teams deploy new services and pipelines. 
NHIs fall into several broad categories, these categories are aligned with Cloud Security Alliance, IBM, NHI Management Group standards plus emerging AI agent guidance: 

  • Service accounts: Dedicated accounts for applications or background jobs (e.g., "webapp‑db‑user", "backup‑service"). 
  • API keys and tokens: Credentials used by APIs and microservices (such as cloud provider keys, OAuth client secrets).  
  • Machine or device identities: Certificates, OAuth tokens, SSH keys for servers, VMs, containers, and IoT devices.  
  • Automation identities: CI/CD runners, scripts, and orchestration tools.  
  • AI‑based agents: LLM‑powered bots that autonomously call APIs and modify data, increasingly treated as first‑class non‑human identities in modern governance frameworkas
  • How NHIs Differ from Human Identities ?
  • Human identities are usually lifecycle‑managed via HR‑driven onboarding and offboarding, while NHIs are often auto‑provisioned by infrastructure‑as‑code, cloud‑native tooling, or CI/CD pipelines and can persist long after they are needed
Non-Human Identity Management

NHIM — Lifecycle Management

Governing the full life of every non-human identity, from provisioning to de-provisioning, is the backbone of a defensible NHI program.

Glownexus  ·  NHI Governance  ·  6 min read

Introduction

Non-Human Identities (NHIs) need to be governed end to end, under a Non-Human Identity Management (NHIM) program, to ensure security and compliance. The unsanctioned adoption of AI tools — shadow AI — has made this harder still.

The NHIM governance program should manage the full life of an NHI, from initial provisioning, through access-rights changes, to final de-provisioning. It should also include the implementation of policies and controls that enable least privilege, just-in-time access, and removal of identities to reduce the attack surface.

Importance of Lifecycle Management

The principles of lifecycle management remain the same for NHIs, except that they must be enforced more stringently and monitored more closely. Insufficient controls on the lifecycle of NHIs increase the attack surface. That exposure may take the form of an over-permissioned account, unrotated or long-lived credentials, or NHIs without traceable ownership.

AI agents compound this further as they can operate autonomously and, in some cases, spawn ephemeral agents that hold a certain level of access.

Use Cases

Five practices anchor a working NHIM lifecycle program — each with its own risks, controls, and prerequisites.

1

Decommissioning

Unlike workforce or human identities, NHIs typically have no natural trigger — such as a termination or the end of employment — to signal deactivation or removal. The result is credentials that stay active, with continuing access to sensitive data, applications and APIs.

The following should be implemented as part of the NHI lifecycle processes:

  • Set default end dates on new NHIs at creation
  • Disable and then delete the identities
  • Review access before removal
Prerequisites
  • Organizational-level policies to enforce this standard
  • Implementation of a product that is purpose built with connectors for the current infrastructure/application landscape
  • Read/Write access to the underlying infrastructure to enable timely offboarding
  • Availability of APIs and other native access to gather and update the native application objects
2

Creation

Actively manage NHI creation. This should be a policy implementation across the board. Developers and infrastructure admins must not be permitted to embed credentials in Infrastructure as Code (IaC), scripts, or code without explicit approval.

A workflow needs to be in place for any NHI creation. The following principles should be implemented as part of this:

  • A formal request-and-approval process for all NHI creation
  • Mandatory ownership assignment on NHI creation
  • The discovery and scanning process should identify any NHIs that do not have ownership assigned
Prerequisites
  • Implementation of organizational policy disallowing any credential creation without explicit approvals
  • An NHIM tool should be chosen that either has built-in policies that map to existing organizational policy, or allows custom policies to be created
3

Vaulting and Rotation

On creation, set default properties for the NHI to be rotated on a set timer. It can be every 30, 60, or 90 days, depending on the risk categorization of the NHI/target application.

  • Credentials should be vaulted on creation
  • Rotation should be set to a default number of days — depending on the NHI authorization, application risk, or other factors like the type of regulated domain the NHI exists in
Prerequisites
  • Enterprise-grade vaults for storing credentials with sufficient access control enabled
  • Availability of APIs or native methods to allow third-party applications such as the NHIM solution to read object attributes and trigger rotation events as needed
4

Continuous Authentication and Authorization

Static token grants or permission grants like roles or entitlements pose a threat. Once leaked or hijacked, they sharply increase the risk of damage to infrastructure and data. NHIs typically do not have multi-factor authentication set up, and hence a stricter dynamic policy needs to be set up.

The following can be implemented to enforce this, if not already implemented:

  • Cryptographically verifiable workload identity, such as mTLS certificates, SPIFFE/SPIRE identities, cloud workload identity, or signed tokens
  • Short-lived access tokens or certificates instead of permanent API keys and passwords
  • Workload or container attestation, verifying that the request originates from an approved workload, image, host, namespace, or deployment
  • Revalidation when the token is renewed, the workload changes, the session persists beyond its expected duration, or risk signals change
  • Continuous telemetry for unusual activity, such as unexpected source, request volume, time, geography, API sequence, or target resource
Prerequisites
  • Awareness amongst enterprise-wide teams handling CI/CD pipelines
  • Policy guidance and implementation enforcement from Compliance and InfoSec teams
  • Regular audits to confirm that these frameworks are implemented, and to flag and close any gaps
5

Regular Access Reviews

NHIs are commonly not managed directly, so an NHI can remain active beyond its end date, or keep operating with more permissions than were intended. Reviews should therefore be a regular process. The NHI review policy can be kept separate from the one covering workforce identities, and should run at a slightly higher frequency, as some NHIs are short-lived.

  • Trigger access review for orphan NHIs post ownership assignment
  • If required, propose two-level reviews — technical owner (developer, team) and application owner
  • Trigger access reviews on any change of access detected
  • Classic access review cycles — quarterly, bi-annual and so on — based on enterprise-wide compliance requirements

Conclusion

Unlike workforce identities, NHIs — and especially AI agents — often do not follow formal, process-driven paths for creation and access modification; much of this happens on the fly, across many different teams. Managing the lifecycle of NHIs thus becomes the most crucial part of any NHIM program to ensure security and compliance.

Disciplined creation, vaulting and rotation, continuous authentication and authorization, timely decommissioning, and regular access reviews together close the gaps that most commonly lead to over-permissioned accounts, long-lived credentials, and orphaned identities.

These best practices are intended to clarify the challenges and outline the steps you can take now to begin managing NHIs effectively.

Ready to bring your NHIs under control?

Talk to Glownexus about building an NHIM program that covers creation, vaulting, authentication, decommissioning and access reviews end to end.

Contact Us