Notifications
Clear all
Topic starter
24/06/2026 9:28 pm
TL;DR: NHIs are created faster than most teams can inventory, with Gartner cited in the source article as estimating more than 45 non-human identities for every human identity in a company. Broad permissions, exposed API keys, and weak lifecycle controls make product development environments especially hard to govern.
NHIMG editorial — based on content published by Entro Security: The challenges of securing NHIs throughout the Product Development Lifecycle
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Entro Security's analysis of NHI security across the product development lifecycle →
NHI lifecycle management in product development: what breaks?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 6:42 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Securing NHIs across the product development lifecycle
