Who should be accountable for reassigning ownership when a service account is tied to a departed employee or a changed application team?

Why Accountability Must Follow the Service, Not the Person

When a service account outlives the employee who originally touched it, the real ownership problem is organisational, not technical. The account may still authenticate, still automate, and still hold access to production systems even after the human name attached to it has changed. In NHI governance, that makes stewardship a business control issue: someone must be responsible for confirming who now owns the service, what it is allowed to do, and whether it should remain active at all. The NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which is why ownership drift so often survives routine offboarding.

That is why the accountable party should be the business service owner or delegated application owner, with security coordinating the process and forcing closure when ownership is unclear. A technical team can execute the change, but it cannot invent business accountability after the fact. In practice, many security teams discover broken stewardship only after a departed employee’s account has remained active long enough to become a hidden production dependency.

How Reassignment Should Work in Practice

Ownership reassignment should be treated as a lifecycle event tied to business change triggers, not as an ad hoc ticket. The moment an employee leaves, an application moves teams, or a managed service changes hands, the question is not merely “who has the password?” but “who now owns the access decision, the risk, and the cleanup?” That means the process should connect HR records, application inventory, and platform administration so the stewardship claim can be verified rather than assumed.

In a healthy model, security or identity operations runs the workflow, but the business side confirms the new owner and the intended use of the account. That confirmation matters because service accounts often span more than one control plane: the application team may understand the workload, while infrastructure owns the host or pipeline that executes it. If either side can deny responsibility, the account becomes effectively orphaned.

Practitioners should also distinguish between reassignment and mere notification. Notification tells teams that something changed; reassignment establishes who must act, approve, and be held to account if the account is overprivileged, stale, or no longer needed. For context on the underlying NHI lifecycle problem, NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is useful because it frames service accounts, rotation, offboarding, and visibility as one governance chain, not separate chores. Where ownership is reassigned cleanly, the team can decide whether to rotate secrets, narrow scope, or retire the account entirely.

Security control frameworks also support this separation of duties. NIST SP 800-53 Rev. 5 emphasises account management, access enforcement, and accountability as distinct control concerns, which is why ownership cannot remain ambiguous once a business service changes hands. In practice, this guidance breaks down in fast-moving environments where application teams change frequently and service accounts are embedded in CI/CD, because the technical dependency is visible long before the responsible owner is.

Common Variations and Edge Cases

Tighter ownership controls often increase coordination overhead, requiring organisations to balance speed against traceability. The most common edge case is a shared platform account used by several teams, where no single group wants the operational burden of stewardship. Another is a legacy service account with no clear business sponsor because the original system owner has left and the current team only “inherited” it informally. In both cases, the control question is not whether the account still works, but whether anyone can make a defensible decision about its continued existence.

There is also a genuine tradeoff between centralising reassignment in security and preserving business accountability. Security can maintain the process, enforce deadlines, and stop orphaned access from lingering, but it should not become the de facto business owner of every stale service account. The owner of the business service must remain the decision-maker because only that group can judge whether the access is still needed, whether the workload has changed, and whether decommissioning is now the safer option.

For large estates, the important exception is not the departed employee itself but the absence of a replacement owner. When the change cannot be mapped to a current service steward, the account should be treated as high risk until a named owner is assigned. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that unresolved ownership and stale credentials frequently sit at the centre of avoidable identity failures.

Risk and Threat Considerations

Orphaned service-account ownership creates a classic exposure pattern: access persists after the business context has changed, but no one feels responsible for reviewing, rotating, or revoking it. That risk grows when employees leave or applications move teams because the account can retain production reach even though the original steward is gone.

Failure mechanism: an attacker or insider benefits from stale stewardship by exploiting long-lived credentials, excessive privilege, or weak review discipline. If ownership is unclear, the account is less likely to be rotated or retired, and the control gap can persist unnoticed across multiple change cycles.

Impact: the organisation may retain unreviewed access to sensitive systems, lose accountability for remediation, and delay decommissioning decisions that should have reduced blast radius. In the worst case, the account becomes an enduring backdoor whose legitimacy is assumed simply because no one can prove it no longer belongs.

Practitioner Guidance

What to verify: verify that every service account has a current business-service owner, not just a technical custodian. If the named owner cannot confirm the account’s purpose, intended lifespan, and replacement steward, treat the account as unresolved rather than merely undocumented.

Decision rule: if ownership changes because of a departed employee or an application team transfer, force a stewardship re-approval before the next access review closes. Do not let “still functioning” become the reason the account survives without a responsible owner.

What practitioners underestimate: the hard part is not finding the account but proving who has authority to decide its fate. The strongest control signal is not a completed ticket; it is a named owner who can justify continued use, approve rotation, or accept decommissioning.

Practitioner takeaway: accountability must stay with the service owner because only that role can make a defensible business decision about whether the account should exist, be reduced, or be retired.

Related resources from NHI Mgmt Group

• Why do application permissions for Mail.Send create higher risk than a traditional service account in Exchange Online?
• What problem does ownership attribution solve for service accounts and API keys?
• When does a service account become a compliance problem?
• Who is accountable when a departed user or service account still has access?