Notifications
Clear all
Topic starter
06/06/2026 1:57 am
TL;DR: Identity-based vulnerabilities account for 4 in 5 publicly known breaches, and Oasis Security argues that the rapid expansion of non-human identities is forcing IAM teams to rethink monitoring, lifecycle control, and governance across service accounts and APIs. Legacy human-centric identity models no longer cover the operational reality of machine identities.
NHIMG editorial — based on content published by Oasis Security: How NHIs Are Reshaping the Responsibilities of Identity Security Professionals
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams handle service accounts with standing privilege?
A: Security teams should treat service accounts with standing privilege as a lifecycle and exposure problem, not just an access review problem.
Q: Why do non-human identities complicate IAM governance?
A: Non-human identities complicate IAM governance because they do not behave like people.
Q: What breaks when API keys are not rotated and revoked on time?
A: When API keys are not rotated and revoked on time, old access continues to work even after ownership changes, vendor offboarding, or application updates.
Practitioner guidance
- Inventory all non-human identities and their owners Build a complete register of service accounts, API keys, tokens, and certificates across cloud, code, and automation systems.
- Move lifecycle events into automated workflows Link provisioning, rotation, renewal, and de-provisioning to application change, deployment events, and ownership handoffs.
- Reduce excessive privilege on machine identities Review service accounts and API keys for permissions they do not actively need, then narrow scopes to the smallest stable set that still supports the workload.
What's in the full article
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The full breakdown of each identity security job responsibility and how NHI pressure changes the work.
- The article's own framing of visibility, security, and governance as the three-step model for NHI management.
- The vendor's explanation of why policy-based automation is needed across provisioning, rotation, and de-provisioning.
- The closing view on how modern NHI management fits into hybrid-cloud identity architecture.
👉 Read Oasis Security's analysis of how NHIs are reshaping identity security roles →
NHI responsibility shifts: what IAM teams need to change now?
Explore further
06/06/2026 3:20 am
Service account governance has become an enterprise identity discipline, not a back-office admin task. Once applications, integrations, and automation rely on non-human identities, IAM ownership extends beyond user directories into code, pipelines, and cloud services. That changes the operating model for access control, review, and remediation. Practitioners should treat NHI governance as a core identity programme requirement, not an adjunct to PAM or secrets management.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: How do IAM teams know whether NHI monitoring is actually working?
A: NHI monitoring is working when teams can reliably see who owns each credential, where it is used, and whether its behaviour matches the workload it supports. Good monitoring produces alerts on unusual privilege use, unexpected cross-environment access, and stale credentials that still authenticate. If none of that is visible, the programme is blind.
👉 Read our full editorial: How NHIs are reshaping identity security responsibilities
