Who is accountable when a service account or pipeline identity is misused?

Why This Matters for Security Teams

When a service account or pipeline identity is misused, the problem is rarely just the incident itself. It usually signals a governance gap: no named owner, no review cadence, and no clear offboarding path. That matters because operational identities often hold broad access, and in practice they are harder to monitor than human users. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which makes accountability difficult to enforce after misuse.

Security teams often assume the last person to touch the pipeline or trigger the workflow is the accountable party. That assumption breaks down fast in CI/CD, automation, and delegated OAuth flows, where identities persist beyond individuals and continue operating after staff changes, role shifts, or vendor handoffs. The better question is who approved the identity, who maintained its permissions, and who was responsible for retirement when it was no longer needed. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls provides the control language for ownership, access review, and lifecycle management, but organisations still have to assign that responsibility in practice. In practice, many teams discover this only after a leaked key or abused pipeline token has already been used to move laterally.

How It Works in Practice

Accountability should follow the identity lifecycle, not the individual who happened to invoke it. For service accounts, OAuth grants, and CI/CD identities, the minimum workable model is: a named business owner, a technical custodian, a defined purpose, a review schedule, and a retirement trigger. That makes it possible to trace who approved the access, who maintained the secrets or certificates, and who must revoke the identity when the workload ends.

For autonomous or highly automated pipelines, current guidance suggests pairing ownership with runtime controls. That usually means short-lived credentials, scoped permissions, and just-in-time issuance rather than static secrets that linger for months. The Guide to the Secret Sprawl Challenge highlights why long-lived credentials create hidden exposure, especially when they are embedded in build systems, config files, or deployment jobs. NIST control families around access enforcement and account management are relevant here, but they do not remove the need for clear operational ownership.

• Assign every non-human identity to one accountable team, even if several teams use it.
• Record the identity’s purpose, allowed systems, and expiration or review date.
• Use CI/CD and cloud logs to show who approved, rotated, or disabled the identity.
• Revoke access when the pipeline, integration, or vendor relationship ends.
• Escalate misuse as an ownership failure if the identity had no maintainer.

Where possible, map the identity to a control owner in the access review process so that exceptions are visible and actionable. The operational test is simple: if no one can answer who owns the credential, no one can safely attest that it is still needed. These controls tend to break down when identities are reused across multiple pipelines or shared between environments because ownership becomes ambiguous and revocation can disrupt unrelated workloads.

Common Variations and Edge Cases

Tighter identity accountability often increases administrative overhead, requiring organisations to balance fast delivery against review discipline. That tradeoff is especially visible in build systems, third-party integrations, and ephemeral automation where teams want frictionless access but still need a responsible owner. Best practice is evolving, but there is no universal standard for how much shared access is acceptable before accountability becomes too diluted to enforce.

One common edge case is a shared service account used by several squads. In that model, the accountable party should still be explicit, even if multiple teams are operational users. Another is vendor-managed automation, where the internal team remains accountable for approving the access and confirming retirement, even if the vendor executes the workflow. A third is inherited identity sprawl after mergers or platform migrations, where old pipeline tokens remain valid long after the original owner is gone. NHI Management Group’s CI/CD pipeline exploitation case study is a useful reminder that pipeline identities can become high-impact attack paths when ownership is unclear.

For organisations formalising governance, the most practical approach is to treat misuse as a lifecycle defect, not just a security alert. That shifts the response from blaming the last operator to fixing ownership, review, and offboarding. This is also where the 52 NHI Breaches Analysis is instructive: repeated incidents often follow the same pattern of orphaned, over-privileged, or poorly supervised identities.

Related resources from NHI Mgmt Group

• When does a service account become a compliance problem?
• Who is accountable when a shared service account is misused?
• Who is accountable when an authorised cloud identity service is misused?
• When does a machine identity become a compliance problem?