Who is accountable when dormant access or orphaned accounts remain active?

Why This Matters for Security Teams

dormant access and orphaned accounts are not just cleanup issues. They are evidence that identity ownership has broken down across business, system, and governance functions. When an account stays active after a role change, departure, or workload retirement, the real risk is not the account itself but the fact that no one can prove who should have removed it. The OWASP Non-Human Identity Top 10 treats this as a control failure, not an administrative miss.

In NHI programs, the same pattern shows up in service accounts, API keys, and automation identities that outlive the team or system that created them. NHIMG research on the Ultimate Guide to NHIs frames this as an ownership problem because identities become dangerous when they are no longer tied to a named accountable party. If the owner is unclear, recertification becomes ceremonial and offboarding becomes inconsistent. In practice, many security teams only discover dormant access after a review, incident, or audit has already exposed the gap.

How It Works in Practice

Accountability should be assigned at three layers: the business owner who approves the need for access, the system owner who provisions and maintains it, and the governance function that verifies reviews, expirations, and removal. That division matters because a single owner rarely sees the full lifecycle. The business owner can answer whether access is still needed, the system owner can remove it, and the governance team can confirm it happened on schedule.

Effective programs make that accountability visible in the control plane. Most mature teams use one or more of the following:

• Named ownership fields in IAM, CMDB, or secret inventory records.
• Periodic access recertification tied to the asset or service owner, not only the user manager.
• Offboarding workflows that disable both human and non-human identities when a role, service, or integration ends.
• Escalation paths for stale ownership, including automatic reassignment when teams reorganize.

This is especially important for secrets and automation credentials, where a dormant token can remain usable long after the original owner has left. The NIST control family in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this model through accountability, access review, and revocation expectations. NHIMG’s 52 NHI Breaches Analysis shows why this is operationally relevant: unmanaged identities are often discovered only after misuse has started. The practical standard is simple, but enforcement is not, because ownership data often lives in different systems than the access itself. These controls tend to break down when identity records are created manually and never reconciled with HR, CMDB, or automation inventory sources.

Common Variations and Edge Cases

Tighter ownership control often increases operational overhead, requiring organisations to balance cleaner accountability against faster change velocity. That tradeoff becomes more visible in DevOps, platform engineering, and vendor-integrated environments, where one service can be touched by several teams over its lifetime. Current guidance suggests that ownership should move with the system, but there is no universal standard for how often that reassignment must be validated.

Edge cases also matter. A dormant account may be intentionally retained for forensic access, break-glass recovery, or legal hold. In those cases, the account still needs a named owner, an expiry condition, and compensating controls such as monitoring and restricted use. Orphaned accounts created by contractors, acquisitions, or third-party integrations are even riskier because the original approver may no longer exist. In those scenarios, governance should not guess; it should force reassignment or removal before the account is allowed to persist.

Where teams get into trouble is assuming “system owner” means the platform team automatically owns the risk. In reality, accountability must be explicit enough to survive reorganizations, tool changes, and employee turnover. NHIMG’s Microsoft SAS Key Breach is a reminder that lingering access paths are not theoretical. The most resilient programs treat dormant access as a lifecycle failure and demand one accountable owner per identity, even when several groups participate in the workflow.

Related resources from NHI Mgmt Group

• Who is accountable when orphaned university accounts remain active?
• How should security teams govern Active Directory service accounts?
• Who is accountable when orphaned accounts or stale access contribute to a breach?
• Who is accountable when stale accounts remain active after role changes?