NHIM - Lifecycle Management

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. Shadow AI has compounded this problem. The NHIM governance program should manage the initial provisioning of the NHI to the access rights changes and the 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 NHI except that they need to be more stringent and monitored. Insufficient controls on the Lifecycle of NHIs increases the attack surface. It could be an over permissioned account, unrotated or long-lived credentials or NHIs without traceable ownership.
With the AI agents the Non-Human Identity Lifecycle compounds as these can be autonomous and, in some cases, give rise to ephemeral agents with certain level of access.

Use Cases

Decommissioning

Unlike the Workforce/Human identity, the NHIs typically do not carry a trigger like a termination or end of employment, to indicate deactivation or removal.
This results in active credentials with access to sensitive data, applications, APIs, etc.
The following should be implemented as part of the NHI Lifecycle processes:

• Set default End Dates on new NHIs on 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

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 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:

• Process implementation for request and approval processes in NHI creation
• Mandatory ownership assignment on NHI creation
• The discovery, scanning process should identify any NHIs which do not have ownerships assigned

Prerequisites

• Implementation of organizational policy disallowing any credential creation without explicit approvals
• A NHIM tool should be chosen that either has built-in policies which map to existing organizational policy or allows creation of custom policies to implement

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 upon 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 like the NHIM solution to trigger read operations of object attributes and trigger events to rotate the credentials as needed

Continuous Authentication and Authorization

Static token grants or permission grants like roles or entitlements pose a threat. Once leaked or hijacked, the chances of damage to the infrastructure or data go up multiple times. The NHIs do not have a 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 determine if the Frameworks are implemented and flag and improve gaps

Regular Access Reviews

It’s common for the NHIs to not be managed directly. There are situations where an NHI could remain active beyond its end date or continue working with more permissions than were intended.
Reviews should be a regular process, especially for the NHIs. This policy can be separate from the workload identities and should be implemented at slightly increased frequency as some NHIs can be 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 reviews set up – quarterly, bi-annual, etc., based on the enterprise-wide compliance requirements

Conclusion

Unlike workforce identities, the NHIs and specially AI agents, often do not follow formal and process-oriented creation and access modification paths – with a lot of this action happening on the fly by various 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.
The aim of these best practices is to help understand the challen