TL;DR: Non-human identities often remain documented but not understood, according to Klyro research, because audits can confirm owners, reviews and rotation policies while leaving app-level service accounts, API keys and tokens effectively invisible when the application is never connected. That makes lifecycle control depend on catching ownership context before the requester leaves.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Klyro's blog post: application-connected non-human identities can be handed off before ownership knowledge disappears, but disconnected apps leave NHIs invisible and unmanaged.
Why it matters: IAM and IGA teams need application-level visibility to preserve ownership, offboarding and reviewability for NHIs that are otherwise present but uncorrelated.
Context
The core governance problem is not whether a non-human identity exists, but whether anyone still knows what it does when ownership changes. Audits can show that an owner field is filled in and a review was completed, yet that only proves documentation, not durable accountability.
Service accounts, API keys and integration users become harder to govern when the application that hosts them is never connected to IAM. In that state, the identity may still work, but it sits outside the lifecycle processes that would normally preserve context and offboarding responsibility.
Key questions
Q: How do orphaned service accounts happen in connected applications?
A: Orphaned service accounts happen when the person who requested the account leaves or changes role, but the application identity remains active. The account still has access, yet the business context disappears. That gap usually appears when ownership is documented without a lifecycle process that preserves knowledge through mover and leaver events.
Q: Why do application owners struggle to retire non-human identities safely?
A: Application owners struggle to retire non-human identities safely because service accounts, API keys, tokens and certificates are often shared across scripts, integrations and pipelines, so no one knows every dependency. Safe retirement needs inventory, ownership mapping, secret revocation, replacement credentials, staged cutover and monitoring for failed calls after decommissioning. Without that, teams either leave dormant access behind or break the application.
Q: What is the difference between requester ownership and application ownership?
A: Requester ownership is the person or team that asked for the access or credential, while application ownership is the person or team accountable for the system that uses it. The requester may know the business need, but the application owner is responsible for runtime use, scope, rotation, offboarding and removal when the service account or token is no longer required.
Q: What should IAM teams do when a service account is no longer needed?
A: They should retire the account as part of the application or service offboarding process, revoke associated secrets and tokens, and confirm that no downstream systems still depend on it. Leaving the credential in place after the service changes creates avoidable residual privilege and audit exposure.
Technical breakdown
Why disconnected applications hide non-human identities
A connected IAM view only discovers NHIs that are already in scope for integration and aggregation. If an application is never connected, its local service accounts, integration users and API credentials remain outside the inventory, even when they are fully active. That means the problem is not just hidden privilege, but hidden existence: the identity can be live, used regularly and still absent from governance workflows that rely on central visibility. See the Non-Human Identity (NHI) Guide.
Practical implication: Treat application coverage as a visibility control, not a convenience project, because unconnected systems cannot participate in NHI governance.
Why requester ownership breaks when people leave
Requester ownership works while the person who asked for the account still remembers its purpose. Once that person leaves, the account remains but the context does not. The app owner may hold permission authority, yet they often lack operational knowledge about downstream dependencies, which turns a review into a guess. In practice, the identity outlives the human memory that justified it, and the review process loses the evidence needed to make a safe decision. See the NHI Ownership and Accountability Guide.
Practical implication: Model requester ownership as time-bound context that must be transferred before mover and leaver events erase it.
How lifecycle handoff replaces exception-based retention
The useful control is not a broader exception process, but a lifecycle handoff that runs while the requester is still available. When a person changes role or exits, the associated NHI can be reassigned, documented and revalidated before the purpose is lost. That is ordinary joiner-mover-leaver discipline applied to machine credentials. The mechanism only works if the account is visible to IAM early enough to be tied to a human owner and carried forward through change. Read Human vs Non-Human Identity.
Practical implication: Bind NHI review triggers to people events so handoff happens before an orphaned account becomes an enduring exception.
Threat narrative
Attacker objective: The objective is not a single exfiltration event but long-lived, unowned access that survives the people who can explain it.
- Entry occurs through ordinary approval of an application account, API key or service credential that is created for a legitimate integration need.
- Credential access persists because the identity remains valid after the requester leaves, while the purpose and operating knowledge disappear.
- Escalation takes the form of unmanaged persistence: the account stays active, reviewed as an exception and left in place because nobody can safely explain its use.
- Impact is governance failure, with invisible NHIs retaining access that cannot be confidently reassigned, retired or challenged.
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
Application coverage is the real NHI governance boundary: a filled-in owner field does not matter if the account lives in an application IAM never sees. The governance programme can only manage what it can inventory, correlate and review, so disconnected applications create a structural blind spot rather than a simple backlog. That makes coverage the prerequisite for every later control, from offboarding to recertification.
Requester knowledge is a perishable control: the person who asked for the account usually knows the purpose better than anyone else, but that knowledge has an expiration date. Once the requester leaves, the identity remains while the rationale collapses, and the organisation is left with an exception that records uncertainty instead of resolving it. The implication is that ownership is really an information preservation problem, not a paperwork problem.
The leaver event should govern the non-human identity, not the exception queue: when a person departs, the associated service account should move through the same lifecycle discipline that applies to their human access. Repeated exception approval shows the control is arriving too late, after context has already been lost. That is why lifecycle design must shift left to the moment the account is created.
Orphaned NHI persistence is a governance debt, not an audit surprise: the account stayed and the knowledge left, which means the organisation has accumulated access it cannot confidently explain. That is the specific failure mode this pattern illustrates, and it is exactly the kind of hidden residue that NHI lifecycle guidance is meant to surface. Practitioners should treat every unconnected application as a future orphan generator.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Read next: NHI Ownership and Accountability Guide
What this signals
Ownership transfer has to happen before context expires: the useful control point is the mover or leaver event, not the next audit cycle. When the requester is still present, the organisation can confirm purpose, dependency and retirement options before the account becomes a permanent exception.
Invisible NHIs will keep accumulating where application coverage lags: every disconnected system can still create service accounts, API keys and integration users that never enter central governance. That makes application onboarding a lifecycle control, not just an inventory exercise. If the environment already spans many business systems, the visibility gap will widen faster than manual review can close it.
For practitioners
- Connect the long tail of applications first Prioritise the systems that are most likely to host service accounts, integration users and API credentials outside central visibility, then bring those identities into the same lifecycle process as the applications themselves.
- Capture requester context at creation time Record what the account does, why it exists and who requested it before the requester can leave or rotate roles, so later reviews have a human answer to work from.
- Trigger handoff on mover and leaver events Use human lifecycle events to reassign ownership, validate dependencies and decide whether the associated non-human identity still has a business purpose. Read Human vs Non-Human Identity.
- Remove exception drift from NHI reviews Track every repeated exception on an orphaned account as a sign that the review process is arriving after context has already been lost, then reset the workflow around earlier visibility.
Key takeaways
- The main risk is not simply undocumented access, but access that persists after the only person who understood it has left.
- Application-level visibility determines whether non-human identities can participate in ownership transfer, review and offboarding.
- Lifecycle controls fail late when organisations wait for audits; they work better when requester context is captured at creation and carried through mover and leaver events.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs · Non-Human Identity (NHI) Guide · NHI Ownership and Accountability Guide · Human vs Non-Human Identity
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 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Requester departure leaves NHIs behind, which is the offboarding failure this post centers on. |
| NHI-05 — Overprivileged NHI | Unreviewed orphaned accounts retain access that nobody can justify or safely narrow. | |
| NHI-09 — NHI Reuse | Disconnected applications encourage accounts to persist beyond their original purpose and context. | |
| Recommendation — Tie NHI ownership transfer to leaver events so credentials do not outlive the people who understand them. Review orphaned NHIs for excess access and reduce permissions before they become enduring exceptions. Track reused NHIs across applications and retire identities that no longer have a single accountable owner. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about preserving and reviewing NHI entitlements as people leave and applications change. |
| Recommendation — Apply PR.AA-05 to validate that each NHI entitlement still has an accountable owner and business purpose. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle, ownership and orphan handling are central account-management issues in this analysis. |
| Recommendation — Use CIS-5 to find orphaned application accounts and retire those without a current business owner. | ||
Key terms
- Requester Ownership: Requester Ownership is the assignment of accountability to the person or team that asked for an access grant, credential or service account. In identity governance, it records who initiated the need, but it does not replace application ownership, which covers ongoing use, rotation, review and retirement of the non-human identity.
- Application Coverage: Application coverage is the share of an application portfolio that has been tested within a defined period. It helps security leaders see whether testing reaches only a small set of crown jewels or extends across the broader estate, including lower-tier apps and APIs that can still create meaningful risk.
- Joiner-Mover-Leaver Process: The joiner-mover-leaver process manages identity changes across the full employee lifecycle. In IAM, it provisions access when someone joins, adjusts privileges when roles or responsibilities change, and removes accounts, credentials, and permissions when they leave, reducing orphaned access and supporting least privilege, auditability, and governance.
- 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.
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 November 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org