Securing NHIs across the product development lifecycle

At a glance

What this is: This is an analysis of why non-human identities become harder to secure as products mature, with emphasis on inventory, privilege, lifecycle, and governance gaps.

Why it matters: It matters because IAM teams must govern machine identities with the same lifecycle discipline they apply to humans, while also accounting for broader privileges, secret exposure, and fragmented ownership.

By the numbers:

• Gartner estimates that more than 45 non-human identities are created for every human identity in a company.

👉 Read Entro Security's analysis of NHI security across the product development lifecycle

Context

Non-human identity security in product development means controlling the service accounts, API keys, tokens, and certificates that software uses to talk to other software. The core problem is not that these identities exist, but that they spread across code, cloud, SaaS, secret stores, and on-prem systems faster than teams can govern them.

As products mature, the operational model often breaks before the security model does. Ownership becomes decentralized, privileges remain broad, and lifecycle steps such as provisioning, rotation, and retirement are handled inconsistently. That is why NHI governance has to be treated as a programme discipline, not a point-in-time scan.

For teams building that discipline, the NHI Lifecycle Management Guide is the clearest starting point because it connects inventory, rotation, offboarding, and review into one lifecycle view.

Key questions

Q: How should security teams inventory NHIs across product development environments?

A: Teams should inventory NHIs across source code, CI/CD pipelines, collaboration tools, cloud platforms, vaults, and on-prem systems, then normalize each identity by owner, purpose, and privilege. A useful inventory is not just a list of secrets, but a map of where each credential exists and what it can reach.

Q: Why do service accounts with broad access increase breach impact?

A: Service accounts with broad access increase impact because a single exposed credential can inherit the permissions of the workload it represents. If that identity can move across systems or environments, compromise is no longer local. The risk is the reachable blast radius, not just the initial secret exposure.

Q: What do security teams get wrong about NHI lifecycle management?

A: Teams often treat lifecycle management as a provisioning task instead of an end-to-end governance process. That leaves identities orphaned, rotated inconsistently, and retired too late. Lifecycle control has to cover creation, monitoring, privilege change, and deprovisioning, or the identity remains usable after its business purpose ends.

Q: Who should own NHI offboarding when development teams change?

A: NHI offboarding should be owned by a named control function, not left to whichever team used the credential last. Shared use without accountable ownership is how access survives project changes, team moves, and vendor transitions. A clear owner is the only practical way to prove revocation happened.

Technical breakdown

Why NHI inventory fails across product development environments

Inventory is difficult because NHIs are not confined to one control plane. The same credential can appear in source code, CI/CD pipelines, collaboration tools, vaults, cloud services, and on-prem systems. That means a scanner only sees part of the lifecycle unless it can correlate creation, storage, exposure, and usage context. Without that context, teams may know a secret exists but still not know which application depends on it, who owns it, or whether it is safe to rotate. In practice, incomplete discovery becomes a governance blind spot rather than a tooling gap.

Practical implication: build discovery that spans code, pipelines, collaboration tools, vaults, and runtime systems before attempting policy enforcement.

Excessive permissions and blast radius in NHI governance

Many NHIs are born with broad access because engineers optimise for functionality first and governance later. In machine environments, that creates standing privilege, which is especially dangerous because compromise does not need a human to approve further action. Once a service account or API key is exposed, the attacker inherits whatever the identity can reach. The security failure is not merely over-permissioning, but the assumption that the identity’s access will remain harmless because it is non-human. In reality, non-human access often reaches deeper into infrastructure than a typical user account.

Practical implication: map each NHI to its functional purpose and remove access that is not required for that purpose.

Lifecycle management for service accounts and secrets

NHI lifecycle management has to cover birth, use, change, and retirement. If provisioning is ad hoc, rotation is inconsistent, or offboarding is missing, identities become orphaned and secrets remain valid after the original need has passed. That is a classic governance problem because the identity persists longer than the business context that justified it. Product development teams often accumulate credentials during experimentation and integrations, then forget them when features move on. The result is avoidable exposure that is invisible until an incident forces the review.

Practical implication: enforce onboarding, rotation, and retirement workflows for every NHI with an accountable owner and expiry condition.

Threat narrative

Attacker objective: The attacker wants to turn a single exposed machine credential into wider access across development, cloud, or production systems.

1. Entry occurs when attackers find exposed API keys, service account secrets, or certificates in source code, collaboration tools, or other shared systems.
2. Escalation follows when those credentials carry broad permissions, allowing the attacker to move from one application or service into adjacent resources.
3. Impact occurs when the abused NHI enables lateral movement, unauthorized access, or compromise of systems that were never meant to be reachable from the original credential.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

Excessive NHI privilege is not a tuning issue, it is a design flaw in product development governance. The article shows how machine identities are often created with more access than their task requires, then left to persist across environments and teams. That pattern turns ordinary compromise into broad lateral movement, because the identity itself becomes a reusable access path. The implication is that privilege design has to start from business function, not from convenience.

Secret sprawl is the named concept that best captures this failure mode. NHIs are created, stored, shared, and reused across too many places for manual oversight to keep up. When the same identity material lives in code, tickets, chat, and vaults, the problem is no longer just exposure but uncontrolled replication of trust. Practitioners should treat duplication as a governance signal, not a housekeeping issue.

Lifecycle governance for NHIs breaks when ownership is fragmented across DevOps, IT, and development teams. The article’s model depends on different teams handling provisioning, monitoring, and retirement without a single accountability chain. That structure may work for fast delivery, but it fails as a control model because the identity outlives the person or project that introduced it. The implication is that lifecycle ownership must be explicit, durable, and auditable.

Human IAM controls do not transfer cleanly to machine identities. The source notes that MFA and typical authentication patterns are not a fit for NHIs, which means the common human assumption that a user can be challenged at login does not hold here. Instead, risk sits in how the credential is issued, where it is stored, and how long it remains valid. Practitioners should stop treating machine access like a human login problem.

OWASP NHI guidance and NIST CSF both point to the same operational truth: visibility is only useful if it leads to action. Discovery, monitoring, and retirement have to be connected, otherwise teams simply create a larger inventory of unmanaged risk. The field should measure NHI governance by control closure, not by the count of discovered secrets. Practitioners need a lifecycle model that actually reduces reachable access.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
• That same lifecycle problem is explored in NHI Lifecycle Management Guide, which connects provisioning, rotation, and offboarding into one governance model.

What this signals

Secret sprawl: when credentials are copied into code, chat, tickets, and vaults, the governance problem shifts from discovery to control closure. Teams should expect their NHI programme to become a data-correlation exercise unless they can assign each identity to one owner, one purpose, and one retirement path.

The practical signal for programme owners is that NHI risk will keep accumulating wherever lifecycle ownership is diffuse. The right benchmark is not how many secrets you found, but how many you can prove are rotated, revoked, and no longer reachable through OWASP Non-Human Identity Top 10 aligned controls.

As development pipelines expand, machine identity governance will increasingly converge with broader identity controls in NIST Cybersecurity Framework 2.0 terms, especially around identify, protect, detect, and recover. Practitioners should prepare for a world where NHI inventory, privilege scope, and deprovisioning evidence are audit artefacts, not optional operational data.

For practitioners

• Map every NHI creation and storage location Inventory service accounts, API keys, OAuth tokens, certificates, and secrets across source code, CI/CD, collaboration tools, cloud platforms, secret managers, and on-prem systems. Use that inventory to assign a business owner and a functional purpose to each identity.
• Reduce standing access to the minimum functional scope Review each NHI against the task it performs, remove permissions that are not required, and test whether the application still works after each reduction. Focus first on identities that can reach production systems or cross-environment resources.
• Automate rotation and retirement workflows Set rotation schedules for exposed or high-value secrets and define a retirement step for identities whose original purpose has ended. Make offboarding part of the same workflow so dormant credentials do not remain active after a project or relationship changes.
• Create a single accountable owner for each machine identity Assign lifecycle responsibility to a named team or control owner, then require review evidence for provisioning, change, and deprovisioning. Shared responsibility without explicit ownership is what allows orphaned NHIs to persist.

Key takeaways

• NHIs become hardest to secure when they are allowed to spread across development, cloud, SaaS, and on-prem systems without a single governance view.
• Broad, always-on permissions convert routine secret exposure into a larger blast radius, which is why least privilege matters more than the identity label itself.
• Lifecycle management is the control that closes the gap between creation and retirement, especially when multiple teams share responsibility for machine credentials.

Key terms

• Non-Human Identity: A non-human identity is a digital credential used by software, services, or workloads to authenticate and communicate with other systems. It includes service accounts, API keys, tokens, certificates, and similar machine credentials that need lifecycle control, ownership, and monitoring.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, tickets, chat tools, vaults, and cloud systems. It creates duplication, weakens visibility, and makes it harder to know which secret is active, where it is stored, or whether it has already been exposed.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being issued only when needed. For NHIs, it is especially risky because the credential can be reused immediately by an attacker once exposed, and there may be no human approval step to interrupt misuse.
• Lifecycle Governance: Lifecycle governance is the set of controls that manage an identity from creation through change, review, rotation, and retirement. For NHIs, it ensures machine credentials are owned, monitored, and revoked when their business purpose ends, rather than left active by default.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for building a comprehensive NHI inventory across multi-cloud and on-prem environments.
• Specific platform capabilities for scanning CI/CD pipelines, collaboration tools, and cloud configurations.
• Operational workflow examples for enforcing least privilege, rotation, and deprovisioning across machine identities.
• Implementation detail on how to standardize NHI governance across DevOps, IT, and data science teams.

👉 The full Entro Security post covers the inventory approach, lifecycle controls, and platform capabilities in more detail.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.