TL;DR: Non-human identities now outnumber employees by 25x to 50x in modern enterprises, and the article argues that service accounts, OAuth tokens, API keys, certificates, and AI agents sit outside the lifecycle assumptions built into traditional IAM, according to Obsidian Security. The governance gap is now operational, not theoretical, because machine credentials bypass MFA and persist without human-style oversight.
At a glance
What this is: This guide explains why traditional IAM controls miss non-human identities and highlights how machine credentials, service accounts, OAuth tokens, and AI agents create a governance gap.
Why it matters: IAM, PAM, and IGA teams need to treat non-human identities as a distinct governance domain because human lifecycle controls do not cover machine-speed credential creation, privilege, and offboarding.
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
Context
Traditional IAM was designed around people, not machine identities. It assumes managers, HR events, MFA prompts, and predictable working hours, while non-human identities operate continuously through tokens, keys, certificates, service accounts, and integrations that never follow those human patterns.
That mismatch creates an identity governance gap across NHI programmes, especially when developers, SaaS integrations, and AI agents can create or consume credentials faster than access reviews can certify them. The article's central claim is that the problem is not visibility alone, but the failure of lifecycle assumptions built into legacy IAM.
In practice, the blind spot is the credential itself and the trust paths it opens across SaaS and cloud environments. Once a machine identity is created, it can persist long after the person or vendor relationship that introduced it has changed.
Key questions
Q: What breaks when non-human identities are managed outside the IAM operating model?
A: What breaks is accountability. Without IAM ownership, non-human credentials drift into fragmented secrets tools, inconsistent review cycles, and orphaned access that persists after the workload changes. That is how machine identities become invisible trust dependencies.
Q: Why do service accounts and tokens create more risk than many teams expect?
A: Because they often carry standing privilege, operate quietly, and remain valid long after the business need changes. That combination increases blast radius when a credential is exposed and makes detection harder than with human accounts. The risk is not the token itself. It is the duration and breadth of access it enables.
Q: What are the signs that non-human identity governance is starting to slip?
A: Warning signs include reliance on manual upgrade paths, ad hoc secret handling, and fragmented access management across tools and environments. The article mentions caveats, dispatch limits, SSO support, and automated update channels, all of which point to the need for controlled operational discipline. When teams cannot explain how identities are provisioned, updated, and constrained, governance is already weaker than it should be.
Q: Should teams prioritise NHI inventory or behavioural detection first?
A: Behavioural detection should move up the list as soon as the environment contains active SaaS integrations or reused credentials. Inventory is necessary, but it cannot show abuse, lateral movement, or unexpected trust-path changes on its own. Teams need both, with detection covering the blind spots that inventory cannot see.
Technical breakdown
Why human IAM assumptions fail for NHI authentication
Human IAM systems assume an interactive subject with a manager, a working schedule, and a lifecycle tied to hire, transfer, and termination events. Non-human identities do not fit that model. Service accounts, API keys, and OAuth tokens authenticate without MFA, often without a clear owner, and can be created by developers, vendors, or other systems at machine speed. That means policy controls built around human sign-in patterns and quarterly certification cycles miss the real control point: issuance, scope, and revocation of machine credentials.
Practical implication: move governance from human login events to credential issuance, ownership, and offboarding for every NHI.
How token persistence creates standing access risk
OAuth access tokens and refresh tokens are bearer credentials, which means possession is effectively authorization until the token expires or is revoked. Refresh tokens are especially risky because they can mint new access tokens without reauthentication, extending trust beyond the original user action. The same pattern appears in service accounts and API keys that are copied into pipelines, repositories, or SaaS integrations. In NHI terms, the control problem is not just secret leakage. It is the persistence of valid trust after the original business context has moved on.
Practical implication: track token lifetime, revocation pathways, and downstream reuse as part of NHI governance.
Why behavioral detection matters more than static inventory
A static inventory can tell you that an NHI exists, but not whether it is being used in an unexpected way. The article's strongest technical point is that NHIs do not generate the human signals many security tools rely on, such as strange login times or geolocation changes tied to a person. Instead, detection has to look for anomalous access patterns, toxic permission combinations, and unusual use of trusted connections across SaaS environments. That shifts security from periodic review to continuous behavioural monitoring.
Practical implication: supplement inventory and review with continuous detection of anomalous NHI activity and trust-path changes.
Threat narrative
Attacker objective: The attacker aims to use trusted non-human access to move laterally through SaaS and cloud environments without triggering human-centric controls.
- Entry occurs through legitimate NHI trust, such as a service account, OAuth token, or API key that is already authorised in the environment.
- Credential access is not taken by force; attackers use valid machine credentials or compromised third-party tokens to inherit existing permissions.
- Escalation happens when those credentials expose overprivileged scopes, reused secrets, or downstream SaaS connections that widen the blast radius.
- Impact follows through lateral movement across trusted integrations, data access, and operational disruption that looks like normal automation.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Traditional IAM is now a partial control plane, not a complete identity model: Human lifecycle governance still matters, but it no longer covers the identities that actually drive modern access paths. Service accounts, OAuth tokens, and machine credentials create authority without the human ownership assumptions IAM was built around. The implication is that identity architecture has to separate person governance from machine governance instead of treating them as one programme.
Ephemeral-looking access can still behave like standing privilege: Short-lived tokens do not eliminate governance risk if refresh mechanisms, copied secrets, or inherited SaaS scopes keep access alive across systems. The article shows that the trust window often extends far beyond the initial authentication event. Practitioners should treat token persistence and downstream reuse as first-class governance issues.
Service account sprawl is a lifecycle failure, not just a visibility problem: The article's examples show that credentials often outlive the business reason for their creation, especially when vendor relationships, integrations, or development teams change. That is an offboarding problem before it is a detection problem. The practical conclusion is that NHI lifecycle governance must be explicit, owned, and revocation-driven.
Behavioral detection is the only durable control when static review cannot see intent: Quarterly access review assumes access can be certified after the fact, but non-human identities often act continuously and without human-like baselines. That makes behavioural anomalies, unexpected ASN changes, and unusual SaaS trust paths more valuable than static inventory alone. The implication is that security teams need evidence of use, not just records of existence.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Service Account Security Guide
What this signals
Credential issuance is becoming the real control boundary: As machine identities multiply, the decisive question is no longer who signed in, but who created the credential, what scope it received, and how it will be revoked. NHI programmes that cannot answer those questions will keep inheriting hidden access paths.
Identity reviews must shift from snapshots to trust-path monitoring: Static inventory can confirm existence, but it cannot expose inherited SaaS permissions, reused secrets, or token chains that keep access alive after business changes. The operational signal of maturity is whether teams can see and interrupt those paths before they are abused.
For practitioners
- Define an NHI ownership model Assign a named business or technical owner to every service account, token, key, certificate, and AI agent credential so no machine identity exists without accountable stewardship.
- Map credential lifecycles end to end Track issuance, scope, rotation, reuse, revocation, and offboarding for machine identities across SaaS, cloud, CI/CD, and third-party integrations.
- Replace human-style reviews with NHI-specific controls Stop relying on quarterly access certification alone and add continuous monitoring for unused credentials, overprivileged scopes, and inherited third-party access.
- Contain SaaS supply-chain trust paths Inventory which external apps can reach sensitive data through OAuth scopes and revoke integrations whose permissions exceed their current business purpose.
Key takeaways
- The article frames non-human identities as a structural mismatch for traditional IAM, not a niche exception to be absorbed into human processes.
- Machine credentials become risky when they persist beyond the business relationship or system context that created them, which is why ownership and revocation matter.
- Continuous behavioural monitoring and explicit NHI lifecycle controls are the controls most likely to narrow the blind spot the article describes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article repeatedly shows credentials outliving the people, vendors, and systems that created them. |
| NHI-04 — Insecure Authentication | Bearer tokens, service accounts, and keys bypass the interactive authentication model IAM expects. | |
| NHI-05 — Overprivileged NHI | The article highlights admin-like scopes and inherited SaaS permissions that widen blast radius. | |
| Recommendation — Tie every machine credential to an offboarding trigger and revoke it when the business relationship ends. Reduce reliance on bearer-style authentication and require stronger controls around machine credential use. Review machine scopes against actual use and remove privileges that exceed the workload's purpose. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's breach examples rely on valid credentials being reused to move across trusted systems. |
| Recommendation — Map NHI abuse to credential access and lateral movement patterns so detection can target trusted-path abuse. | ||
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
- OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
- Behavioral Detection: A monitoring approach that looks for unusual activity rather than relying only on static inventories. For SaaS integrations, it detects drift in token use, data movement, timing, and endpoint behavior so teams can spot compromise, misuse, or automation that no longer matches its expected pattern.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 27, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org