Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Top 10 NHI risks: where identity controls still break down


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9439
Topic starter  

TL;DR: Non-human identities are growing far faster than human ones, with complex hybrid and multi-cloud estates making visibility, rotation, offboarding, and least privilege hard to enforce, according to Token Security. The core issue is not discovery alone but governance that still assumes static, human-paced access lifecycles.

NHIMG editorial — based on content published by Token Security: Top 10 Non-Human Identity Risks to Recognize and Mitigate

By the numbers:

  • As the number of non-human identities, such as service accounts, devices and API keys, grows faster than human ones (1:10 according to Microsoft research), organizations face a big challenge in keeping them secure.

Questions worth separating out

Q: How should security teams implement NHI lifecycle governance across service accounts and API keys?

A: Start by assigning each non-human identity a named owner, a documented business purpose, and a review cadence tied to usage.

Q: Why do stale non-human identities increase breach risk in hybrid and multi-cloud environments?

A: Because stale identities combine two problems at once: they are harder to notice and more likely to retain permissions nobody actively manages.

Q: What do security teams get wrong about secret rotation for non-human identities?

A: They often treat rotation as a standalone task instead of part of a larger lifecycle model.

Practitioner guidance

  • Build an authoritative NHI inventory Map service accounts, API keys, certificates, tokens, and automation identities to a single ownership record.
  • Remove secret duplication from user-controlled locations Find credentials in code repositories, chat systems, endpoints, and shared documents, then relocate them into governed storage with access boundaries that match the workload.
  • Shorten the lifetime of standing credentials Replace static keys where possible with temporary credentials, rotate long-lived secrets on a fixed schedule, and alert on credentials that have not been used or changed within expected windows.

What's in the full article

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

  • The article’s full risk-by-risk breakdown of the ten NHI failure modes and how they differ in practice.
  • Examples of insecure storage patterns across repositories, vaults, endpoints, and messaging tools.
  • The source’s concrete attack scenarios showing how leaked credentials become compromise paths.
  • Token Security’s product-specific remediation guidance for teams that want implementation detail.

👉 Read Token Security's analysis of the top 10 non-human identity risks →

Top 10 NHI risks: where identity controls still break down?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8923
 

Non-human identity sprawl is really lifecycle debt: The article correctly shows that the problem is not just the number of credentials, but the absence of reliable ownership, review, and offboarding. Service accounts, API keys, and automation identities outlive the people and projects that created them, which means access survives after the business reason has disappeared. The implication is that NHI programmes fail when they treat identities as static artefacts instead of governed lifecycle objects.

A few things that frame the scale:

  • 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
  • 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and they are 13% more likely to be categorised as critical than code-based leaks.

A question worth separating out:

Q: Who is accountable when a third-party non-human identity is compromised?

A: Accountability should be shared but explicit. The internal owner is responsible for governance, the provider is responsible for the integrity of its side of the integration, and both sides need a clear revocation path so old access does not survive a relationship change.

👉 Read our full editorial: Top 10 non-human identity risks and the controls that fail



   
ReplyQuote
Share: