Who is accountable when orphaned access leads to unauthorised use?

Accountability sits with the identity governance process, not just the last administrator who touched the account. Organisations need named ownership for each identity class, clear removal triggers, and audit evidence that access was revoked when the relationship changed.

Why This Matters for Security Teams

orphaned access is not just an administration error. It is an identity governance failure that can turn a departed contractor, retired service account, or stale API key into an active path for unauthorised use. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why access often lingers after the business relationship ends.

The accountability question matters because the last person to touch the account is rarely the right place to assign blame. Security teams need named ownership for each identity class, documented removal triggers, and evidence that revocation happened when a workload, vendor, employee, or integration changed state. That aligns with the control intent in OWASP Non-Human Identity Top 10 and the broader access control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, many security teams encounter orphaned access only after a vendor dispute, a compromised key, or a post-incident review has already exposed the gap.

How It Works in Practice

Accountability should follow the lifecycle owner of the identity, not the individual administrator who provisioned it. For human users, that may be HR-triggered joiner-mover-leaver workflows. For NHIs, it is usually the application owner, platform team, or service owner who is responsible for the identity from creation through retirement. The governance layer should define who approves access, who validates that access is still needed, and who can prove revocation when the relationship ends.

A practical model uses three layers of control:

• Ownership: every identity has a named business and technical owner.

• Triggering: offboarding events, contract expiry, system decommissioning, and key rotation schedules automatically start removal.

• Evidence: logs, ticket history, and vault records show when access was removed and by whom.

This is especially important for secrets and API keys, where stale credentials are often still valid long after the original purpose has changed. The NHI Management Group research on Ultimate Guide to NHIs — Key Challenges and Risks highlights that 91.6% of secrets remain valid five days after the organisation is notified, which shows how slowly revocation can occur when ownership is unclear. NIST’s security control baseline supports this by requiring accountable access enforcement, review, and auditability.

The operational goal is to make revocation predictable, not discretionary. That means tying identities to asset inventories, setting clear removal SLAs, and ensuring the person who owns the workload is accountable for its access state. These controls tend to break down in decentralised environments where service accounts are created ad hoc by engineers and never mapped back to a formal owner.

Common Variations and Edge Cases

Tighter revocation workflows often increase operational overhead, requiring organisations to balance speed of delivery against the risk of stale access. That tradeoff becomes sharp when orphaned access spans shared platforms, inherited cloud subscriptions, or third-party integrations with weak ownership records.

There is no universal standard for this yet, but current guidance suggests a few common patterns. In shared infrastructure, accountability should sit with the platform owner plus the consuming application owner, because either one may need to prove why the access existed. In vendor-managed environments, the business sponsor is usually accountable for ensuring offboarding requests are issued, while the security team validates completion. For automated workloads, the service owner must own both the secret lifecycle and the decommissioning path.

Edge cases often appear when an account is technically active but functionally abandoned, such as a CI/CD token left behind after a pipeline migration or a cloud role that survived an acquisition. NHI Management Group’s 52 NHI Breaches Analysis and Meta AI Instagram Account Takeover both underscore the same point: failure is often procedural before it is technical. The right accountability model is the one that can show who owned the identity, who approved the access, and who verified removal when it should have ended.

Related resources from NHI Mgmt Group

• Who is accountable when middleware bypass leads to unauthorised access?
• Who is accountable when an exposed DevOps secret leads to unauthorised access?
• Who is accountable when a control failure leads to fraud or unauthorised access?
• Who is accountable when push MFA fatigue leads to unauthorised access?