Notifications
Clear all
Topic starter
09/07/2026 3:30 pm
TL;DR: Machine identities now outnumber human identities in many environments, and Commvault argues that governance, visibility, and auditability have not kept pace with how applications, services, APIs, and automated workloads actually operate. The result is persistent privilege sprawl, weak accountability, and a security model that still assumes human-paced lifecycle controls are enough.
NHIMG editorial — based on content published by Commvault: machine identity governance and the changing identity model
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: What breaks when machine identities are not governed like other identities?
A: Visibility, ownership, and retirement all fail at the same time.
Q: Why do machine identities increase lateral movement risk?
A: Because they often carry persistent access and can be embedded in trusted workflows, which makes them attractive pivot points after an initial compromise.
Q: How do security teams know if machine identity governance is working?
A: They should be able to answer basic questions quickly: how many machine identities exist, who owns each one, what systems each one can reach, and whether its access is still required.
Practitioner guidance
- Build a machine identity inventory Enumerate applications, services, APIs, and automation accounts with owner, purpose, authentication method, and downstream dependencies so you can see the real access surface.
- Tie every identity to an accountable owner Require a named human or system owner for each service account or token, and make ownership part of access review and offboarding decisions.
- Reduce persistent privilege in automation Review long-lived access used by workloads and remove permissions that are not strictly necessary for runtime operation, especially where access survives deployment changes.
What's in the full article
Commvault's full article covers the operational detail this post intentionally leaves for the source:
- The STRIVE discussion on how machine identities are created inside development and deployment flows.
- The practical questions Commvault uses to assess permissions, ownership, and auditability across workloads.
- The examples of how compromised human accounts can be used to impersonate machine identities.
- The closing guidance on where organisations should begin when inventory and governance are still immature.
👉 Read Commvault's discussion of machine identity governance and privilege sprawl →
Machine identities and privilege sprawl: what IAM teams need now?
Explore further
09/07/2026 3:51 pm
Machine identity governance is now a core IAM problem, not a niche cloud issue. The article correctly shows that applications, services, APIs, and automated workloads now shape access at least as much as people do. When identity programmes remain anchored to human workflows, machine identities become the hidden layer where privilege accumulates without review. The practitioner conclusion is simple: if machine identities are outside the operating model, the operating model is incomplete.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to NHI Mgmt Group research.
A question worth separating out:
Q: Who should be accountable for machine identities?
A: A human owner or clearly defined system owner should be accountable for each machine identity, because accountability cannot be inferred from the application alone. Without that mapping, access reviews, incident response, and offboarding become guesswork instead of governance.
👉 Read our full editorial: Machine identity governance is lagging behind operational reality
