Who should be accountable when a dormant service account needs to be revoked?

Why This Matters for Security Teams

Revoking a dormant service account is not just an access cleanup task. It is a decision about ownership, operational continuity, and blast radius. If nobody can explain what breaks when the identity disappears, revocation becomes guesswork, and guesswork is where orphaned access survives. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why dormant identities often linger far past their useful life.

The accountability question matters because service account sit at the intersection of application ownership, infrastructure operations, and security governance. Security teams may identify the dormant identity, but they usually do not know the dependency graph well enough to judge impact alone. The right model separates discovery and enforcement from business ownership, so the team that understands the workload owns the risk decision while governance enforces the control. That aligns with the broader lifecycle view in the NHI Lifecycle Management Guide and the control emphasis in the OWASP Non-Human Identity Top 10.

In practice, many security teams discover that “nobody owns it” only after a dormant account has stayed active long enough to become a hidden dependency.

How It Works in Practice

The operational model is straightforward, but it only works when accountability is explicit. Discovery should identify the dormant service account, its last use, its permissions, and the systems that depend on it. The governing function should then apply policy, notify the accountable owner, and start a fixed objection window. During that window, the owner must either approve revocation, document a legitimate dependency, or request a bounded extension with a remediation plan.

If the account is confirmed unnecessary, disabling should be the default first action rather than immediate deletion. That preserves rollback options if an undocumented integration appears. Once the objection window closes, revocation can proceed with evidence retained for audit. This pattern maps well to control families in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where least privilege, access review, and configuration management intersect.

• The accountable owner is usually the application or platform team that can name the dependency.
• Security or identity governance runs discovery, policy enforcement, and evidence capture.
• Operations executes the technical disable or revoke step when the decision is final.
• Unresolved objections should escalate to a named executive, not remain in a ticket queue.

For service-account hygiene, NHI Mgmt Group’s Top 10 NHI Issues is useful because it frames dormant identities as a lifecycle failure, not a one-time admin task. These controls tend to break down when ownership is shared across multiple teams and no one can confidently trace which system will fail first.

Common Variations and Edge Cases

Tighter revocation controls often increase coordination overhead, so organisations have to balance speed against outage risk. That tradeoff is real, especially when a dormant account supports batch jobs, legacy middleware, or vendor-managed integrations that are poorly documented.

Current guidance suggests that exception handling should be time-bound and evidence-driven. A short-lived extension may be justified if the owner can show active dependency and a remediation date, but “unknown impact” is not a durable reason to keep access alive. In very mature environments, teams pair revocation with automated dependency scanning and secret rotation so the risk window stays small. In less mature environments, the practical first step may be to disable, observe, and then remove once no breakage appears.

This is also where many organisations underestimate secret sprawl. A service account may be revoked in the identity system while copies of its credentials remain in code, CI/CD variables, or configuration files. The Guide to the Secret Sprawl Challenge is relevant here because revocation only works when credential copies are removed at the same time. There is no universal standard for this yet, but best practice is evolving toward accountable ownership plus governance-enforced deactivation, backed by rollback-ready operational controls.

Related resources from NHI Mgmt Group

• When does a service account become a compliance problem?
• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern Active Directory service accounts?