Who is accountable when a compromised machine identity causes a breach?

Why This Matters for Security Teams

When a machine identity is compromised, accountability is often misassigned to the engineer who deployed the workload instead of the team that owns the identity lifecycle. That confusion matters because service accounts, API keys, certificates, and workload tokens can outlive the code that created them. NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities, and that most organisations still lack full visibility into service accounts.

The practical question is not who clicked the wrong button last. It is who approved the identity, who defined its privilege, who monitored its use, and who is responsible for revocation when the trust relationship changes. Security teams often miss this because machine identities cross platform, application, cloud, and DevOps boundaries, so ownership is fragmented across multiple groups. That fragmentation turns a breach into a governance failure, not just a technical incident. The 52 NHI Breaches Analysis shows how repeatable these failures become when ownership and lifecycle control are unclear. In practice, many security teams discover the missing owner only after a compromised identity has already been used to move laterally or exfiltrate data.

How It Works in Practice

Accountability should follow the identity lifecycle, not the incident timeline. That means one team, usually platform security, identity engineering, or the application owner with delegated authority, must be named as the control owner for issuance, scope, rotation, monitoring, and revocation. This is consistent with the identity governance model reflected in NIST guidance on digital identity and with Zero Trust principles that treat every workload credential as a distinct, auditable trust object rather than a reusable convenience token.

In practice, the accountable owner should be able to answer four questions without searching through tickets:

• Why does this identity exist, and what business process depends on it?
• What systems, secrets, APIs, or data can it reach?
• How is it authenticated, rotated, and revoked?
• What alerts or compensating controls exist if it is abused?

That ownership should be backed by inventory and policy, not memory. Current guidance suggests tying NHI records to an owner, a purpose statement, an expiry condition, and an escalation path. For higher-risk identities, use short-lived credentials, secrets managers, and workload identity standards such as SPIFFE rather than long-lived shared keys. NIST SP 800-207 Zero Trust Architecture is useful here because it reinforces continuous verification and least privilege at request time. The operational lesson is simple: if the owner cannot revoke it quickly, they do not really own it. These controls tend to break down in legacy batch systems and third-party integrations because the identity is embedded in code, cron jobs, or vendor-managed tooling that no single team can rotate safely.

Common Variations and Edge Cases

Tighter identity ownership often increases operational overhead, requiring organisations to balance clear accountability against deployment speed and legacy compatibility. That tradeoff is real, especially where shared service accounts support dozens of jobs or where a vendor insists on static credentials. In those cases, best practice is evolving rather than settled: some environments can move to per-service ownership, while others need a temporary exception register with compensating controls and a hard retirement date.

There are also situations where accountability is shared, but not blurred. For example, a platform team may own the identity mechanism, while the application team owns the business use case and approval to access a specific resource. What should not happen is diffuse responsibility where everyone can change the identity but no one is accountable for its misuse. That is how compromised credentials persist across incident response cycles and why lifecycle ownership matters more than after-the-fact blame. NHIMG’s 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of non-human identities, which shows how often weak accountability becomes a repeat issue. The same pattern appears in broader incident reporting, including Anthropic’s report on AI-orchestrated cyber espionage, where autonomous abuse escalated quickly once tool access was available.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised non-human identity causes major outage or data loss?
• Who is accountable when a supplier identity is used in a breach?
• Who is accountable when a recovery identity is compromised?
• Who is accountable when help desk bypass leads to an identity breach?