Notifications
Clear all
Topic starter
28/08/2026 12:04 pm
TL;DR: Service accounts, API keys, certificates, bots, and AI agents need a distinct identity model because human IAM processes break down when ownership, lifecycle, and runtime behaviour are machine-driven, according to Unosecur. The practical shift is to govern discovery, ownership, short-lived credentials, privilege, and behavioural monitoring together, not secrets alone.
NHIMG editorial — based on content published by Unosecur: Best practices for securing non-human identities: A practical guide for service accounts and machine identities
By the numbers:
- CyberArk's 2025 Identity Security Landscape study reported 82 machine identities per human identity across the surveyed organizations.
- The same study found that 42% of machine identities held privileged or sensitive access.
- CyberArk's 2025 State of Machine Identity Security research found that 50% of surveyed security leaders reported security breaches linked to compromised machine identities.
Questions worth separating out
Q: What breaks when organisations manage service accounts like human users?
A: Service accounts do not behave like people, so human IAM controls miss the real risks.
Q: Why do cloud environments increase non-human identity risk?
A: Cloud environments increase non-human identity risk because automation, APIs, and service accounts multiply faster than manual review can keep up.
Q: How do security teams know if NHI governance is working?
A: Good NHI governance shows up in fewer shared credentials, shorter secret lifetimes, clear ownership for every machine identity, and offboarding that actually removes unused accounts.
Practitioner guidance
- Inventory every non-human identity with relationship context Map each service account, API key, certificate, bot, workload identity, and agent to its creator, workload, environment, and accountable owner.
- Eliminate long-lived credentials where federation is available Replace persistent passwords and static API keys with short-lived credentials, workload identity, or federated access.
- Review privilege as effective access, not assigned role Audit inherited permissions, wildcard entitlements, trust relationships, and cross-account access for every high-value NHI.
What's in the full article
Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step discovery coverage across cloud IAM, SaaS, CI/CD, Kubernetes, databases, and secrets stores
- Practical examples of ownership mapping for service accounts, workload identities, and AI agents
- Guidance on how to baseline normal machine behaviour and flag abnormal authentication or privilege use
- Examples of how to tie decommissioning and credential revocation to workload retirement
👉 Read Unosecur's guide to securing non-human identities and AI agents →
Non-human identity security: what IAM teams need to tighten now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
28/08/2026 12:04 pm
Identity programmes fail when they treat machine accounts like people. Human IAM assumes a natural owner, a joiner-mover-leaver lifecycle, and a person who can explain why access exists. That assumption breaks for service accounts, workload identities, and bots that outlive teams and applications. The implication is that NHI governance must be built around workload context, not employee process.
A few things that frame the scale:
- 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
- 57% of organisations lack a complete inventory of their machine identities, which means ownership and exposure are still being inferred rather than governed.
A question worth separating out:
Q: What is the difference between managing secrets and governing NHIs?
A: Secrets management protects the credential itself, while NHI governance manages the identity behind it. That means defining ownership, allowed access, lifecycle, runtime behaviour, and retirement. A well-managed secret can still represent unacceptable risk if the account behind it is overprivileged or unowned.
👉 Read our full editorial: Best practices for securing non-human identities and AI agents
