NHI lifecycle security depends on visibility, rotation, and ownership

At a glance

What this is: This is a best-practices post on securing the NHI lifecycle, with the key finding that NHIs now vastly outnumber human users and can concentrate cloud control in a tiny fraction of identities.

Why it matters: It matters because IAM teams cannot govern machine access with human-centric assumptions when service accounts, tokens, and API keys create a larger, faster-moving attack surface than employees do.

By the numbers:

• Non-human identities now outnumber human users by a factor of 17 to 1, according to the Veza 2026 State of Identity and Access Report.
• A mere 0.01% of NHIs control 80% of cloud resources across the enterprise.

👉 Read Veza's analysis of NHI lifecycle best practices and shadow identity risk

Context

Non-human identity governance fails when teams treat service accounts, bots, and API keys as static setup artefacts instead of living access subjects. The article argues that the real problem is not just volume, but that invisible identities can retain powerful permissions long after the purpose that created them has changed.

For IAM and security teams, the operational gap sits across discovery, ownership, privilege, rotation, and offboarding. Human controls like MFA and SSO do not solve machine identity sprawl, and spreadsheet-based tracking cannot keep pace with cloud and CI/CD-driven change.

The article’s guidance is typical of what enterprises are now confronting: NHI growth, hidden admin access, and lifecycle drift that outpaces manual governance. The central issue is that machine identity programmes have to be run as continuous control systems, not periodic clean-up exercises.

Key questions

Q: How should security teams implement NHI lifecycle management?

A: Start with discovery, then assign every service account, API key, token, and certificate to an owner with a defined approval and revocation path. Lifecycle management only works when creation, rotation, offboarding, and exception handling are linked to a single governance process rather than spread across DevOps and security teams.

Q: What problem does ownership attribution solve for service accounts and API keys?

A: It closes the gap between exposure detection and accountable remediation. Many organisations can find the secret, but not the human who introduced it, maintains it, or can safely replace it. Ownership attribution gives security teams a practical way to assign action without relying on informal knowledge that disappears during staff changes.

Q: What breaks when NHI ownership is missing?

A: When NHI ownership is missing, access reviews lose context, incident response slows, and stale identities persist longer than they should. The programme may still have tools and policies, but it lacks the accountable decision path needed to execute them reliably.

Q: What is the difference between short-lived credentials and permanent API keys for NHI security?

A: Short-lived credentials limit the window in which access can be abused, while permanent API keys remain valid until someone manually finds and revokes them. In practice, ephemeral access reduces blast radius and makes compromise less durable. Permanent keys create a standing trust assumption that is difficult to defend at scale.

Technical breakdown

Why NHI discovery has to start with runtime inventory

Non-human identities are often created outside formal IAM workflows, which means the authoritative record is fragmented across code repositories, CI/CD pipelines, cloud consoles, and vaults. A runtime inventory is different from a spreadsheet because it captures what actually exists, not what teams think exists. That matters when orphaned secrets or abandoned service accounts still authenticate successfully. Discovery is the prerequisite for every downstream control, because ownership, rotation, and revocation all depend on knowing the identity exists in the first place.

Practical implication: build continuous discovery across code, pipelines, and cloud environments before trying to tighten policy or rotation.

How short-lived credentials reduce NHI blast radius

Permanent API keys and hard-coded secrets create an access model that outlives the workload’s real need. Short-lived credentials, workload identity federation, and ephemeral tokens reduce dwell time by making access temporary and task-scoped. In practice, this shifts control from password-style secrecy to runtime trust. The key architectural change is that the application proves identity when needed, rather than storing a reusable credential that can be copied, leaked, or reused indefinitely.

Practical implication: replace long-lived machine secrets with ephemeral credential flows wherever the platform supports them.

Why NHI lifecycle automation is a governance control, not a convenience

Rotation and offboarding are not administrative chores; they are the control points that stop stale access from becoming persistent exposure. Automated rotation narrows the window in which a leaked secret remains useful, and rigorous offboarding prevents retired workloads from leaving behind active identities. This is especially important because NHI behaviour is more predictable than human behaviour, which makes deviation easier to detect if the lifecycle is under control. Without automation, the lifecycle always lags the environment.

Practical implication: define automated rotation and deletion triggers tied to workload state, not manual reminders.

Threat narrative

Attacker objective: The objective is to turn a single exposed machine credential into broad cloud access and sustained operational control.

1. Entry occurs when secrets, tokens, or service account credentials remain discoverable in repositories, pipelines, or other exposed locations.
2. Escalation follows when an over-privileged or orphaned NHI is reused to reach broader cloud resources than the workload actually needs.
3. Impact is the expansion of blast radius across cloud systems, especially when a tiny set of identities holds disproportionate control.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NHI lifecycle security fails when identity is treated as an object, not a governed subject. The article is correct that discovery, ownership, privilege, rotation, and offboarding have to be managed as a continuous chain. Once a service account is allowed to persist without lifecycle ownership, the programme has already accepted unmanaged access as normal. Practitioners should treat that as a governance failure, not a tooling gap.

Identity blast radius: 0.01% of identities controlling 80% of cloud resources is not an edge case, it is the operating model many enterprises have drifted into. That concentration means a small set of NHIs can create outsized systemic risk when permissions are inherited, reused, or never revisited. The governance implication is that access concentration has to be measured as a risk indicator, not discovered after an incident.

Human IAM controls do not transfer cleanly to machine identities. MFA, SSO, and user-centric review cycles do not solve the core problem of secrets that authenticate silently and persist for years. The article’s best-practice set points in the right direction, but the discipline needed here is lifecycle governance for NHI, not repurposed human access management. Practitioners should separate machine identity policy from employee IAM policy.

Continuous discovery is the control that makes the rest of NHI governance possible. Static inventories fail because cloud, code, and pipeline changes happen faster than review cycles. Without automated discovery, every other control is partial at best, because you cannot rotate, offboard, or scope what you have not found. The practical conclusion is straightforward: inventory drift is itself a security condition, not just an audit inconvenience.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Only 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Guide to the Secret Sprawl Challenge shows how hardcoded and scattered secrets keep lifecycle controls incomplete even when teams believe they have centralised management.

What this signals

Identity blast radius: when a tiny fraction of NHIs controls most cloud resources, the real governance problem is not count, but concentration. Teams should expect access review programmes to become more effective only when ownership, privilege scope, and retirement state are all measured together.

With 79% of organisations having experienced secrets leaks in our research, the practical signal is that lifecycle controls cannot depend on manual memory or periodic clean-up. The programme has to treat discovery and revocation as continuous operations, not support tasks.

The next maturity step is to link machine identity inventory to policy enforcement and workload state. That is where identity governance stops being descriptive and starts acting as a control plane for the environment.

For practitioners

• Implement continuous NHI discovery Scan repositories, CI/CD pipelines, cloud environments, and vaults to build a real-time inventory of every secret, token, certificate, and service account. Use ownership mapping so each identity is assigned to a human owner or engineering team before access review begins.
• Replace permanent keys with short-lived credentials Prioritise workload identity federation and ephemeral tokens for applications that currently rely on forever API keys. Reduce the time a leaked credential can be reused by making credential validity minutes or hours, not years.
• Automate rotation and offboarding triggers Tie key rotation to a 30 to 90 day schedule only where ephemeral access is not yet possible, and delete NHI credentials immediately when a workload is retired. This prevents shadow identities from lingering after application ownership changes.
• Baseline NHI behaviour and alert on drift Define normal access patterns for each bot or service account, then alert on spikes in API calls, unusual access times, or new resource targets. Pair anomaly detection with audit logging so every action is attributable during investigations.

Key takeaways

• The article’s core warning is that NHI sprawl becomes dangerous when ownership, privilege, and retirement are not governed as one lifecycle.
• The strongest evidence is concentration and invisibility, with a tiny share of identities controlling a disproportionate share of cloud resources.
• The practical response is to shift from manual tracking to continuous discovery, short-lived access, and automated offboarding.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
• Non-Human Identity Governance: Non-human identity governance is the practice of managing, controlling, and auditing every machine identity across its full lifecycle. It covers service accounts, API keys, tokens, certificates, and AI agent credentials — ensuring each has a defined owner, scoped privilege, rotation schedule, and revocation path. Without governance, NHIs accumulate silently and become the primary attack surface in cloud and automated environments.

What's in the full article

Veza's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for building a single source of truth for NHIs across code, CI/CD, and cloud environments.
• Practical examples of how to move from hard-coded keys to short-lived credentials and workload identity federation.
• Specific automation patterns for lifecycle rotation, deletion, and ownership assignment in active environments.
• Behavioural monitoring approaches for identifying anomalous service account activity before it becomes a breach.

👉 Veza's full post covers the discovery, least-privilege, rotation, and offboarding guidance in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.