Who should be accountable for stale service accounts and nested group access?

Accountability should sit with the business or technical owner of the application, not with the directory team alone. Directory administrators can enforce the control, but they cannot determine whether an account is still required. The right model ties ownership, review, and revocation to the service that consumes the identity.

Why This Matters for Security Teams

Stale service account and nested group access create a classic accountability gap: the directory can show who has access, but it cannot tell whether the identity is still needed for a business process. That is why ownership must sit with the application or service owner, with directory teams acting as control enforcers rather than decision makers. This distinction matters because non-human identities are often overprivileged and under-observed; NHI Mgmt Group notes that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges.

Nested group membership makes the problem harder because effective access is rarely obvious from a single list. A user or service account may inherit rights through multiple layers, so review owners need a business-context view, not just a directory export. OWASP’s OWASP Non-Human Identity Top 10 treats weak lifecycle control and excessive privilege as core identity risks, which aligns with the way stale access turns into unauthorised lateral movement.

In practice, many security teams discover stale service accounts only after an audit, an incident, or a failed offboarding exercise, rather than through intentional ownership reviews.

How It Works in Practice

The practical model is simple: assign a named business or technical owner for every service account, group, and application-owned identity, then require that owner to attest necessity, approve changes, and confirm revocation when the service is retired. Directory admins should automate enforcement, but the owner must answer the key question: is this identity still required for this workload, integration, or batch process?

For nested groups, review the effective entitlement path, not just the first-level membership. That usually means combining access governance with relationship mapping so reviewers can see which direct accounts, nested groups, and inherited roles produce actual access. Current guidance suggests pairing this with PAM, RBAC hygiene, and just-in-time credential provisioning where possible, especially for privileged service accounts that should not hold standing access. The operational pattern is reinforced by 52 NHI Breaches Analysis, which shows how compromised non-human identities repeatedly appear in real incidents.

• Map each service account to one accountable owner and one backup owner.
• Require periodic attestation at the application or workload level, not only at the directory level.
• Use automated detection for dormant accounts, unused groups, and orphaned memberships.
• Revoke access through change control when the service, job, or integration is decommissioned.

For implementation detail, the Ultimate Guide to NHIs — Key Challenges and Risks is useful alongside the OWASP framework because both emphasise lifecycle control, visibility, and least privilege. These controls tend to break down in heavily delegated directory environments with deep group nesting and no authoritative application inventory, because no one can reliably determine the true owner of the effective access.

Common Variations and Edge Cases

Tighter access review often increases operational overhead, so organisations need to balance fast recovery and auditability against the cost of chasing every inherited entitlement. That tradeoff is real in large enterprises, especially where legacy applications, shared admin groups, and outsourced operations create long dependency chains.

There is no universal standard for how many nested layers is too many, but best practice is evolving toward fewer indirect entitlements and clearer ownership boundaries. In mature environments, the application owner approves access need, the IAM team validates policy, and the directory team executes the change. In less mature environments, that separation often collapses, and stale service accounts survive because everyone assumes someone else owns them.

For governance, the Ultimate Guide to NHIs — What are Non-Human Identities is helpful when explaining why service accounts should be treated as first-class identities rather than technical leftovers. The most important exception is emergency access: break-glass accounts and vendor-maintained integrations may need different review cycles, but they still need explicit ownership, expiry, and documented revocation steps. In the real world, nested group sprawl usually persists until a decommissioning event, migration, or privilege review forces the organisation to confront who actually owns the access.

Related resources from NHI Mgmt Group

• Who should be accountable for stale or unowned service accounts in AD?
• Why do service accounts and privileged access complicate banking compliance?
• How should security teams govern privileged access across service accounts and AI-driven systems?
• What breaks when stale Snowflake service accounts are left in place?