Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Non-human identity security strategy: where teams keep falling short


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

TL;DR: NHIs are often over-privileged, poorly visible, and managed with weaker controls than human identities, and Cerbos cites examples spanning service workloads, OAuth apps, and AI agents alongside CyberArk findings that 50% of organisations saw machine-identity-linked breaches in the past year. The real issue is not simply more automation, but governance that assumes machines can be trusted without the same lifecycle, scoping, and audit discipline as people.

NHIMG editorial — based on content published by Cerbos: securing non-human identities in modern tech stacks

By the numbers:

Questions worth separating out

Q: How should security teams inventory non-human identities across the stack?

A: Start with a single discovery process that covers service accounts, API keys, certificates, OAuth apps, CI/CD secrets, and AI agents.

Q: When do short-lived credentials reduce NHI risk most effectively?

A: They help most when an organisation also has fast revocation, narrow scoping, and clean ownership for every identity.

Q: What do security teams get wrong about workload identity standards?

A: They often treat standards like SPIFFE or OIDC machine-to-machine support as a finished solution.

Practitioner guidance

  • Map every NHI domain into one inventory Include production service accounts, CI/CD secrets, OAuth applications, certificates, and AI agents in the same discovery process so owners, scopes, and runtime locations are visible in one place.
  • Set lifecycle metrics that expose weak controls Track percentage of scoped short-lived credentials, time-to-revoke for compromised identities, orphaned account cleanup, and rotation coverage so governance decisions are based on measurable exposure.
  • Replace static secrets with standards-based workload identity Use SPIFFE, OIDC machine-to-machine patterns, or equivalent cryptographic identity approaches where platforms support them, and reserve shared secrets for the smallest possible exception set.

What's in the full article

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

  • A six-step NHI security framework with practical sequencing from discovery through ownership
  • Examples of standards selection, including SPIFFE, WIMSE, SPICE, OIDC M2M, and FDO
  • The specific metrics Cerbos recommends for tracking rotation, revoke speed, and orphaned identities
  • A breakdown of how security, IAM, DevOps, and application teams split NHI responsibilities

👉 Read Cerbos' guide to securing non-human identities in modern enterprises →

Non-human identity security strategy: where teams keep falling short?

Explore further

View Full Forum →  |  NHI Foundation Course →



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

Blind trust in NHIs is now a programme design flaw, not a tuning issue. The article is right to frame over-privilege and invisible machine activity as a governance problem, because NHIs are now spread across production, development, user domains, and AI workflows. Once identity is granted to systems that move faster than human review cycles, the old assumption that machine access can be trusted by default stops holding. Practitioners should treat NHI visibility as the prerequisite to every other control decision.

A few things that frame the scale:

  • 1.5 million customers, 40,000 partners, 2,500 internal users, and more than 4,500 services and workloads illustrate how quickly identity sprawl can outpace visibility, according to The State of Non-Human Identity Security.
  • Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.

A question worth separating out:

Q: Who should own NHI lifecycle governance in an enterprise?

A: Ownership should be shared, but explicit. Security should define risk and audit requirements, IAM should govern issuance and policy, platform teams should implement and operate controls, and application teams should surface misuse. The important part is that every stage of the NHI lifecycle has a named accountable owner rather than an implied one.

👉 Read our full editorial: Best practices for non-human identity security in modern stacks



   
ReplyQuote
Share: