Who is accountable when orphaned accounts or stale access contribute to a breach?

Why This Matters for Security Teams

Orphaned accounts and stale access are not just cleanup issues. They are evidence that identity lifecycle ownership is weak, and that risk has been allowed to accumulate beyond the point where a simple password reset or alert can contain it. NHIs make this worse because machine access often outlives the project, the owner, and sometimes the system that created it. The breach path is frequently simple: an unused account remains enabled, a secret is reused, and an attacker finds a persistent foothold.

This is why the OWASP Non-Human Identity Top 10 treats lifecycle and secret hygiene as core controls, not optional hardening. NHIMG’s 52 NHI Breaches Analysis shows how often identity failures become operational incidents once access is left unowned or unreviewed. The accountability question matters because breach response usually exposes a chain of missed ownership decisions, not a single technical defect. In practice, many security teams encounter stale access only after an attacker has already used it to move laterally or exfiltrate data.

How It Works in Practice

Accountability for stale access is usually distributed across three functions: identity governance, application ownership, and HR or workforce operations. Security can set standards, but it cannot revoke what it does not own. The practical control is a lifecycle process that ties every account to a named owner, a business justification, and a review cadence. For non-human identities, that means secret inventory, workload registration, and automatic expiration where possible. For human accounts, it means joiner-mover-leaver workflows with evidence that access was actually removed.

Current guidance suggests treating stale access as a control failure that must be measurable. That includes:

• assigning an accountable owner for every account and secret
• reviewing privileged and dormant access on a fixed cadence
• automating revocation when a role ends, a system is retired, or a secret is rotated
• logging who approved the access, who reviewed it, and who removed it
• escalating exceptions when application teams cannot prove ownership

This aligns with the operational model described in NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks, where unmanaged identity sprawl and stale secrets create durable exposure. It also matches the control emphasis in the OWASP Non-Human Identity Top 10, which pushes teams to treat lifecycle hygiene as part of attack surface reduction. Accountability becomes auditable when the organisation can show who approved access, when it was last reviewed, and what evidence proves revocation occurred. These controls tend to break down when applications create ad hoc service accounts outside central IAM because no team can reliably prove ownership.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance revocation speed against application stability and support burden. That tradeoff is real, especially in legacy environments where shared accounts, hard-coded secrets, or embedded credentials are difficult to replace quickly. Best practice is evolving, but there is no universal standard for how much exception tolerance is acceptable before stale access becomes negligent.

One common edge case is contractor or partner access. A business owner may approve it, but the platform team still owns enforcement, and security still owns oversight. Another is service-to-service access in CI/CD or production automation: if the application team cannot rotate or retire secrets cleanly, accountability shifts from a single person to the engineering group that controls the workload. A third case is M&A or cloud migration, where shadow accounts survive cutover because no authoritative inventory exists.

NHIMG’s 2024 ESG Report: Managing Non-Human Identities shows how frequently organisations experience NHI compromise when governance is weak, which is why incident review should always trace stale access back to a named control owner, not just a technical system. The practical test is simple: if no one can prove who approved, reviewed, and removed the access, accountability has failed before the breach did.

Related resources from NHI Mgmt Group

• Who is accountable when orphaned accounts and stale NHIs keep showing up in audits?
• Who should be accountable for stale service accounts and nested group access?
• Who is accountable when third-party access stays active too long?
• How should teams handle stale Active Directory objects before access reviews?