Service account ownership fails when the owner leaves

At a glance

What this is: NHI Mgmt Group's analysis, drawing on C1.ai's blog post: Service account ownership breaks down when organisations treat creators as owners, leaving orphaned non-human identities after turnover.

Why it matters: IAM, IGA, and PAM teams need an ownership model that survives personnel change, because every downstream control depends on knowing who can answer for a service account.

👉 Read C1.ai's analysis of service account ownership and orphaned NHIs

Context

Ownership is the control that keeps non-human identities governable after people move on. In practice, many organisations confuse who created a service account with who is still accountable for it, and that difference becomes visible only when someone leaves. NHI ownership and accountability is the governance problem underneath the inventory problem.

When turnover breaks the human link to a service account, the account does not stop existing. The result is orphaned access, unclear escalation paths, and controls that cannot be executed because no one can confidently say what the identity is for or who should act on it.

Key questions

Q: What breaks when service account ownership is tied to the person who created it?

A: The model breaks at turnover. Creators leave, change teams, or lose context, while the identity keeps running. That leaves organisations unable to answer basic questions about purpose, privilege, and revocation authority, which is why ownership must be current, not historical.

Q: Why do orphaned service accounts create a governance problem, not just an inventory problem?

A: Because inventory tells you what exists, but governance requires someone who can approve rotation, revoke access, and explain business impact. When no owner exists, the account may remain active by default, and every downstream control loses its decision point.

Q: How should organisations structure NHI ownership so it survives staff turnover?

A: Use role- or team-backed ownership with a named individual attached to the role, then make reassignment a mandatory step in offboarding. That preserves continuity when people leave while still leaving one accountable person who can act on the identity.

Q: How do teams know if NHI governance is actually working?

A: Look for complete inventory coverage, clear ownership, enforced rotation, and reliable decommissioning. If new credentials appear faster than they are classified, or if stale secrets stay valid after workload changes, the programme is not governing machine identities effectively.

Technical breakdown

Creator history is not ownership

A creator record captures who provisioned an identity at a point in time, but it does not establish ongoing accountability. Ownership is operational, not historical: the owner must know what the service account does, what systems depend on it, and whether it still needs its current access. Without that distinction, organisations end up with inventories full of names that no longer map to active responsibility. That is why ownership fails at turnover, not because the account disappears, but because the governance relationship does. Practical implication: treat creator metadata as evidence, not as control ownership.

Practical implication: Separate creation history from accountable ownership in every NHI inventory and lifecycle workflow.

Team or role ownership survives personnel churn

A durable model assigns the service account to a team or role, then ties that role to a named individual who can answer for it. The role preserves continuity when people leave, while the named owner preserves day-to-day accountability and knowledge. This is the governance pattern that prevents turnover from becoming an orphaning event. It also aligns with lifecycle management, because reassignment can be triggered automatically when the human owner departs. Practical implication: make ownership transferable by design so offboarding changes the accountable person without breaking the control. See the Service Account Security Guide.

Practical implication: Use role-backed ownership so offboarding can reassign rather than orphan service accounts.

Offboarding must transfer NHI ownership before departure closes

If a leaver can walk out while their service accounts remain attached to them, the organisation has already lost control of those identities. The better pattern is to make ownership transfer part of the offboarding gate, so departure is not complete until every associated NHI has a new accountable owner. That turns turnover into a control checkpoint instead of a blind spot. It also reduces the chance that rotation, revocation, or incident response stalls because no one knows who can approve the next action. Practical implication: block offboarding closure until ownership is reassigned.

Practical implication: Add NHI ownership transfer to the offboarding gate before departure is marked complete.

Threat narrative

Attacker objective: The attacker objective is to exploit orphaned service accounts that no longer have an accountable human to detect, revoke, or explain them.

1. Entry occurs when an employee departs and leaves service accounts behind without a reassigned owner, creating orphaned identities.
2. Credential access persists because the service accounts, API keys, and automation credentials remain active after the human operator is gone.
3. Impact follows when no one can confidently revoke, rotate, or explain the remaining access, leaving unattended identities in production.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Ownership is the control plane for every other NHI control: revocation, rotation, incident response, and offboarding all fail when there is nobody accountable to act. C1.ai's example is useful because it shows the operational truth that discovery alone does not create governance. The real question is not whether the account exists, but whether someone can still answer for it after personnel change. The practitioner lesson is to make accountability a live control, not a directory field.

Creator-based models are structurally brittle: they encode history instead of responsibility, so they appear to work until the first significant turnover event. A service account can outlive the engineer who created it by years, which means ownership must be attached to an ongoing function, not a past event. service account security becomes materially easier when ownership is designed to survive reorganisation, resignation, and role change.

Team-backed ownership is the only model that scales with turnover: individual ownership gives accuracy but not continuity, while department ownership gives continuity but often kills accountability. The middle path, role-backed ownership with a named individual, preserves both. That is the named concept here: ownership continuity debt: the growing governance gap between who created an identity and who can still be held responsible for it after staff movement. The practical conclusion is to treat turnover as the moment when ownership either proves itself or fails.

NHI lifecycle governance is the same discipline as human offboarding, but the failure mode is different: human access can be terminated, yet service accounts and API keys keep running unless the ownership model explicitly moves with them. That means JML-style processes need to govern the identity, not just the person. The implication is that NHI programmes should stop treating ownership as documentation and start treating it as a lifecycle control.

Orphaned identities are not an inventory issue first, they are an accountability issue first: the inventory can be complete and still be ungoverned if no one is responsible for each record. C1.ai's framing is important because it ties this directly to operational follow-through, not abstract policy. The practitioner conclusion is straightforward: if a service account cannot be assigned, reviewed, and transferred, it is not governed.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Ownership and Accountability Guide

What this signals

Ownership continuity debt: the longer an organisation relies on creator history instead of accountable ownership, the more service accounts accumulate responsibility gaps that only appear during turnover. That debt does not show up as a single incident until a leaver event exposes it, which is why ownership transfer has to be part of the control itself, not a manual follow-up.

NHI programmes should expect the ownership question to become more operational, not less, as machine identities continue to outnumber human identities. The programme signal to watch is simple: if offboarding can close while attached service accounts remain unresolved, the identity lifecycle is not yet governing the real estate it claims to cover.

For practitioners

• Define accountable ownership for every service account Assign each NHI to a team or role with a named individual responsible for review, escalation, and lifecycle decisions.
• Make ownership transfer part of offboarding Do not close a departure until all identities tied to the leaver have been reassigned and validated by the receiving owner.
• Separate creator fields from owner fields Keep creation history, technical steward, and accountable owner as distinct attributes so turnover does not blur responsibility.
• Review orphan risk at scale Prioritise service accounts created by departed staff, because those are the identities most likely to retain access without oversight.

Key takeaways

• Service account ownership fails when organisations record who created an identity instead of who remains accountable for it.
• The scale problem is already material, with NHIs outnumbering human identities and visibility into service accounts still limited.
• The practical fix is continuity of ownership, with reassignment built into offboarding so identities do not outlive responsibility.

Related NHI Mgmt Group resources: NHI Ownership and Accountability Guide · Service Account Security Guide · Ultimate Guide to NHIs

Key terms

• NHI Ownership: NHI ownership is the accountable assignment of a non-human identity to a specific business or technical owner. It defines who approves creation, reviews access, rotates secrets, monitors use, and retires the identity. Strong ownership links each service account, token, certificate, or AI agent to clear governance, risk, and remediation responsibility.
• Orphaned Identity: An orphaned identity is a service account, token, or other machine credential that no longer has a clear owner, purpose, or retirement path. These identities create compliance and security risk because they are easy to forget, difficult to review, and often remain active long after they should have been removed.
• Ownership Continuity: The ability to show that a phone number still belongs to the same user over time. It is stronger than reachability because it includes disconnects, reassignment, tenure, and churn signals, which are essential for trustworthy authentication and recovery decisions.
• Creator Versus Owner: Creator versus owner distinguishes who first provisioned an identity from who is currently responsible for it. In NHI governance, the creator is historical evidence, while the owner is the living control point that should survive turnover, reorganisation, and staff departure.

What's in the full article

C1.ai's full blog post covers the operational detail this post intentionally leaves for the source:

• The three ownership models discussed for service accounts and how each behaves under turnover
• The offboarding pattern that reassigns NHIs before a departure is considered complete
• The distinction between creator history and accountable ownership in NHI governance
• The way teams can keep service accounts, API keys, and automation linked to a responsible owner

👉 C1.ai's full post covers the ownership models, turnover failure mode, and lifecycle reassignment pattern in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.