Topic starter
11/11/2026 2:22 pm
TL;DR: Application-connected non-human identities can keep ownership visible through mover and leaver events, but disconnected ones can stay invisible when the application is never connected, according to Klyro. That makes offboarding depend on capturing requester context before the person leaves.
Editorial analysis by NHI Mgmt Group, based on content published by Klyro: “Your NHIs outlive the people who created them”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The main risk is not simply undocumented access, but access that persists after the only person who understood it has left.
Glossary terms: Requester Ownership, Application Coverage, Joiner-Mover-Leaver Process, Service Account
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 44 minutes ago by NHI Mgmt Group
11/11/2026 2:22 pm
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.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Application-connected NHIs keep ownership visible before leavers go
This post was modified 44 minutes ago by NHI Mgmt Group