Who is accountable when orphaned Active Directory access is not removed?

Why This Matters for Security Teams

Orphaned active directory access is not just an admin cleanup issue. It is an accountability failure that often survives role changes, project exits, and system handoffs. When no owner can revoke access, the account effectively becomes standing privilege. That is the opposite of the traceable, reviewable governance expected by NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, both of which emphasise clear ownership and revocation discipline.

NHI Management Group has documented that only 20% of organisations have formal offboarding and revocation processes for API keys and similar identities, and 71% of NHIs are not rotated on time, which shows how quickly “temporary” access becomes permanent. That same pattern appears in directory services when access reviews are delayed or ownership is unclear, especially across service accounts, delegated admin roles, and application-linked accounts. The risk is not merely dormant access; it is unowned access that can be abused long after the original business need has ended. In practice, many security teams discover this only after an audit, incident, or failed deprovisioning test, rather than through intentional governance.

How It Works in Practice

Accountability for orphaned Active Directory access usually spans three parties: the identity owner, the system owner, and the business approver. The identity owner should know why the access exists, the system owner should maintain the technical control to remove it, and the business approver should confirm whether the access is still justified. If any one of those links breaks, access tends to persist.

In mature environments, access removal is tied to joiner-mover-leaver workflows, periodic certification, and compensating controls for exceptions. That means the directory team does not decide entitlement validity in isolation. Instead, it executes a revocation decision that comes from a business-backed process. This is where lifecycle discipline matters: the Ultimate Guide to NHIs highlights how poorly managed identities accumulate excessive privileges, while the 52 NHI Breaches Analysis shows how neglected credentials and access paths frequently become the entry point for broader compromise.

• Assign a named owner to every privileged or application-linked AD account.
• Require a business approver for any exception that keeps access alive past role change or project close.
• Use time-bound approvals where possible, and log the rationale for extension.
• Reconcile AD group membership against HR, CMDB, or application ownership records on a fixed schedule.
• Escalate unresolved orphaned access as a governance exception, not a routine cleanup ticket.

For control design, align the review cadence with least privilege and revocation evidence, then verify the ability to remove access without relying on manual tribal knowledge. These controls tend to break down when legacy AD groups are shared across multiple applications, because ownership becomes ambiguous and no single workflow can prove who is authorized to remove the access.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance faster cleanup against business continuity and application fragility. That tradeoff is real in Active Directory environments with legacy integrations, shared service accounts, or hard-coded group dependencies. Current guidance suggests treating those cases as exceptions with explicit expiry dates, not as permanent waivers.

One common edge case is when an application team claims ownership of an account but cannot produce a current business justification. In that situation, the system owner may keep technical custody, but accountability still sits with the business approver who allowed the access to persist. Another case is delegated admin access used by multiple support teams. There is no universal standard for this yet, but best practice is evolving toward documented ownership chains, short review windows, and evidence that the access can be removed without breaking production.

Where orphaned access is tied to identity systems outside the directory team’s direct control, the risk becomes organisational rather than technical. That is why access governance should reference both the lifecycle controls in the Ultimate Guide to NHIs — Key Challenges and Risks and the access accountability expectations in the OWASP NHI guidance. In practice, unresolved orphaned AD access becomes hardest to eliminate when ownership is split across IT, security, and application teams and nobody has the authority to sign off on revocation.

Related resources from NHI Mgmt Group

• What breaks when Active Directory access reviews are not tied to effective access?
• What breaks when Active Directory access reviews are run from spreadsheets?
• Active Directory access review
• How should security teams govern Active Directory service accounts?