Who is accountable when a compromised service account causes an incident?

Why This Matters for Security Teams

A compromised service account is rarely just an IAM issue. It is usually an operational ownership problem, a secrets hygiene problem, and an entitlement review problem that all converge at once. The practical question is not only who can reset the credential, but who understood the workload, approved the access, and accepted the risk when the account was created. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why accountability has to follow the identity lifecycle, not just the incident ticket.

That distinction matters because service accounts often outlive the teams that requested them, accumulate excess privilege, and remain embedded in automation long after the original use case changed. When an incident happens, teams that treat the account as “owned by security” usually slow down containment because they lack workload context. Teams that treat it as “owned by engineering” without identity governance often miss the broader blast radius. Current guidance suggests accountability must be shared, but responsibility for action should still be explicit and testable.

In practice, many security teams only discover the ownership gap after the service account has already been used to pivot into production systems.

How It Works in Practice

The cleanest model is to separate accountability into three layers. The account owner is responsible for the technical lifecycle of the service account, including rotation, decommissioning, and proving that the account still has a valid purpose. The workload owner is responsible for the system or application that depends on the account and for validating whether the permissions are still appropriate. The identity team is responsible for the control plane that issued or approved the entitlement, including policy enforcement, review cadence, and escalation when the account drifts from policy.

This split works because service accounts are not static assets. They are machine identities that can be copied into CI/CD, embedded in code, reused by automation, and over-permissioned over time. NHIMG’s 52 NHI Breaches Analysis is useful reading here because it shows how quickly non-human identity failures become breach pathways rather than isolated configuration mistakes.

Operationally, the incident process should define:

• Who can revoke or disable the credential immediately.
• Who confirms what the account was used for and what it touched.
• Who approves re-issuance, if the workload still needs it.
• Who records the entitlement gap so it is not reintroduced in the next deployment.

Framework guidance aligns with that split. The NIST Cybersecurity Framework 2.0 emphasizes access governance, asset management, and response coordination, while CISA service account guidance reinforces the need to inventory, restrict, and monitor these identities. For organisations dealing with higher autonomy or machine-to-machine chaining, SPIFFE overview is often the right reference point because workload identity should be tied to cryptographic proof of what the workload is, not just to a password or token. These controls tend to break down when service accounts are shared across multiple applications because no single team can prove ownership fast enough during containment.

Common Variations and Edge Cases

Tighter ownership controls often increase operational overhead, requiring organisations to balance faster incident containment against more rigorous change management. That tradeoff is especially visible when a service account supports multiple pipelines, legacy jobs, or vendor-managed integrations. In those cases, there is no universal standard for a single accountable owner, so the best practice is evolving toward named primary ownership plus clearly documented secondary approvers.

One common edge case is a shared account used by several workloads. In that environment, accountability should usually sit with the team that controls the most sensitive dependency, while the identity team enforces split review and shorter credential TTLs. Another edge case is outsourced administration, where a vendor may operate the workload but the enterprise still owns the risk. In those scenarios, the enterprise cannot outsource accountability even if the execution is delegated.

Agentic and autonomous systems make this harder. As highlighted in Anthropic’s report on an AI-orchestrated cyber espionage campaign, automated systems can chain actions quickly once a credential is exposed, which means response speed matters as much as ownership clarity. Current guidance suggests using policy-as-code, short-lived secrets, and workload identity to reduce ambiguity before an incident occurs, rather than trying to assign blame after lateral movement has already started. When service accounts are shared, long-lived, and embedded in unattended automation, accountability frameworks tend to fail because no team can safely assert full control over the identity’s actual use.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised non-human identity causes major outage or data loss?
• Who should be accountable when a leaked service account exposes production data?
• Who is accountable when privileged access causes a production incident?
• Who is accountable when an unmanaged SSH key causes an incident?