Accountability sits with the business owner, IAM team, and application owner together, because the failure crosses identity, application, and spend governance. If nobody owns the app, nobody can revoke it cleanly. Organisations need a named steward for every application before offboarding can be reliable.
Why This Matters for Security Teams
When an employee leaves, the obvious concern is account disablement, but orphaned applications create a broader accountability gap. The application may still hold API keys, service credentials, scheduled jobs, or delegated admin access that continue to run long after the human owner has departed. That makes this an identity, application, and financial governance issue at the same time. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys in the Ultimate Guide to NHIs, which is why these risks so often survive routine HR offboarding.
Security teams usually discover the problem only after a failed renewal, an unexpected bill, or a suspicious call from an auditor. The real issue is that nobody is clearly accountable for the app’s runtime access, so IAM can disable the employee while the application continues operating under inherited trust. That is why NIST’s NIST Cybersecurity Framework 2.0 emphasis on governance and asset visibility matters here: ownership has to be explicit before access can be reliably removed. In practice, many security teams encounter orphaned apps only after the former employee has already departed and the app has kept running unnoticed.
How It Works in Practice
Accountability is shared, but it must be assigned with precision. The business owner is accountable for whether the application should continue to exist, the application owner is responsible for its technical operation and dependency map, and the IAM team is responsible for removing human and non-human access that the app no longer needs. If the application uses service accounts, API keys, certificates, or delegated OAuth grants, those secrets must be tied to a named steward and a documented lifecycle. The Ultimate Guide to NHIs is clear that visibility and offboarding are foundational, not optional controls.
Practically, reliable offboarding needs a few control points:
- Maintain an owner record for every application, including a backup steward.
- Link each app to the NHIs, secrets, and cloud resources it depends on.
- Use joiner, mover, leaver workflows to trigger access review and credential revocation.
- Separate human account disablement from application continuity decisions.
- Require periodic recertification so dormant apps are retired, not left to drift.
This is also where NIST CSF 2.0 helps operationalise accountability, because asset inventory, access control, and governance must be tested together rather than as separate tickets. Organisations that cannot map an app to an owner usually cannot revoke it cleanly, and they also struggle to prove whether a running workload is legitimate or just forgotten. These controls tend to break down in environments with decentralised SaaS sprawl and undocumented automation because the application owner is unknown before the employee exits.
Common Variations and Edge Cases
Tighter offboarding control often increases administrative overhead, requiring organisations to balance clean revocation against the need to avoid breaking production systems. That tradeoff is real when an employee owns a business-critical workflow, because immediate shutdown may interrupt revenue or customer operations. Current guidance suggests treating the application as a managed asset with a named steward, but there is no universal standard for who must approve continuation in every environment.
Some edge cases need special handling. Shared service accounts may survive employee departure even when no one remembers why they exist. Contractor-built automations may be owned by a vendor contract rather than an internal team. Cloud-native workloads may depend on tokens, certificates, or federation settings that are invisible to the HR offboarding process. In each case, the accountability model should make the business owner answerable for continuation, the application owner answerable for technical cleanup, and IAM answerable for revocation execution. NHI Mgmt Group’s research shows why this matters: organisations with weak visibility into service accounts cannot reliably prove what still runs after offboarding.
Best practice is evolving toward continuous ownership review, not one-time leaver checklists. That means orphan detection, secret inventory, and entitlement recertification should be part of normal operations, not emergency cleanup. When those controls are missing, orphaned apps keep running because the system treats ownership as optional instead of as a condition of access.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Ownership and lifecycle gaps create orphaned NHIs after offboarding. |
| NIST CSF 2.0 | GV.OV-01 | Governance and ownership oversight are central to orphaned app accountability. |
| NIST AI RMF | AI RMF governance principles apply to accountable operation of autonomous workloads. |
Use governance processes to name stewards and review ongoing operational responsibility.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
