Who should be accountable for stale or unowned service accounts in AD?

Why This Matters for Security Teams

Stale or unowned service account are not just housekeeping issues. They are an accountability failure that weakens access review, offboarding, incident response, and auditability. When no business owner is named, identity teams cannot tell whether the account still supports a live workload, a forgotten integration, or an abandoned project. That ambiguity creates standing privilege, hides secret sprawl, and makes it harder to prove whether access is still justified under NIST Cybersecurity Framework 2.0 governance expectations. NHIMG’s research shows only 5.7% of organisations have full visibility into their service accounts, which explains why ownership gaps persist until a review, outage, or breach forces the issue, as discussed in the Ultimate Guide to NHIs — What are Non-Human Identities.

The real risk is that an “orphaned” account often behaves like a permanent backdoor: it remains valid, rarely rotates, and is usually excluded from normal joiner-mover-leaver processes. In practice, many security teams encounter the exposure only after a privileged access review or outage has already surfaced the problem.

How It Works in Practice

Accountability should sit with the business or application owner because they control the use case, funding, and risk acceptance for the service account. Identity and infrastructure teams should own the control plane: discovery, lifecycle enforcement, privileged access management, rotation, and deprovisioning. That split is consistent with current guidance in NIST Cybersecurity Framework 2.0, where governance and access control are operational responsibilities, not abstract security goals.

A practical model usually looks like this:

• Every service account has a named business owner and a technical custodian.
• The owner must define the service purpose, renewal date, and required privileges.
• Identity teams enforce review cadences, disablement thresholds, and secret rotation.
• Unowned accounts are quarantined as exceptions until an owner is assigned or the account is removed.

This is where NHI governance becomes concrete. NHIMG’s 52 NHI Breaches Analysis and the Dropbox Sign breach both show how weak ownership and poor lifecycle discipline can turn a routine account into a high-impact exposure. Under the Ultimate Guide to NHIs — What are Non-Human Identities, service accounts should be treated as governed identities with explicit lifecycle controls, not as static directory entries. These controls tend to break down in legacy AD environments where applications share one account across multiple teams because no one can prove who actually benefits from the access.

Common Variations and Edge Cases

Tighter ownership rules often increase operational overhead, requiring organisations to balance security clarity against legacy complexity. There is no universal standard for this yet, but best practice is evolving toward explicit accountability even when the implementation is messy.

Shared service accounts are the hardest case. Some teams argue that infrastructure or platform groups should own them because they created the account, while application teams argue they merely consume it. The safer answer is to require a single accountable business owner and allow delegated technical administration. If that cannot be done, the account should be marked as an unresolved exception, not left in a grey zone.

There are also short-lived integration accounts, disaster recovery accounts, and vendor-operated accounts. Those should be covered by the same governance model, but with risk-based exceptions, documented expiry, and stronger monitoring. NHIs are often overprivileged and poorly visible, so the Ultimate Guide to NHIs — What are Non-Human Identities remains the clearest reference point for defining lifecycle ownership, while zero-trust programmes use it to reduce standing access and move toward NIST Cybersecurity Framework 2.0 aligned governance.

In mature environments, the question is not whether infrastructure teams can reset the password. It is whether anyone is willing to own the business risk when that account is still active next quarter.

Related resources from NHI Mgmt Group

• What breaks when stale Snowflake service accounts are left in place?
• Why do unowned service accounts create more security risk?
• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?