Who is accountable when a compromised account is used to cause harm?

Why This Matters for Security Teams

A compromised account is rarely just a technical incident. It is an identity failure, an access governance failure, and often a monitoring failure that exposes gaps in ownership. When secrets are weakly protected or service account are over-privileged, the blast radius expands quickly. NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows how often the accountable path leads back to governance, not just alerting.

Security teams are expected to answer who owned the identity, who approved the access, who monitored the misuse, and who can revoke or rotate the credential set. That matters because attacker activity often follows legitimate trust paths, not obvious malware patterns. The harm may appear as data theft, fraudulent transactions, privilege escalation, or lateral movement long before a control fails closed. In practice, many security teams encounter accountability disputes only after the compromise has already produced business impact, rather than through intentional ownership design.

How It Works in Practice

Accountability is usually shared, but not vague. The identity owner is accountable for the lifecycle of the account, the access owner for what it can reach, and the security owner for detection, response, and evidence preservation. Good practice is to map those duties into explicit control points: ownership registration, access approval, periodic review, alert triage, and revocation authority. The operational question is not only who is blamed after harm, but who had the authority to prevent or contain it.

For compromised accounts, practitioners should be able to answer four questions immediately:

• Who owns the identity and is responsible for its business purpose?
• Who approved the permissions, and were they justified by least privilege?
• Who monitors anomalous use, session behavior, and token activity?
• Who can suspend, rotate, or revoke access without delay?

This is especially important for NHIs because many environments still place secrets in code, CI/CD pipelines, or shared vaults. NHI Management Group reports that 79% of organisations have experienced secrets leaks, with 77% resulting in tangible damage, which is why ownership must extend beyond the credential itself to the systems that issue, store, and consume it. Frameworks such as NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture both reinforce the need for clear access control, verification, monitoring, and response. Where human oversight is involved, the lesson from the 52 NHI Breaches Analysis is that recovery is faster when ownership, logging, and revocation are already documented. These controls tend to break down when identities are shared across teams but no single group has revoke authority or evidence ownership.

Common Variations and Edge Cases

Tighter accountability often increases administrative overhead, requiring organisations to balance faster response against cleaner ownership boundaries. That tradeoff becomes more visible in outsourced operations, platform teams, and shared service environments where one account may support multiple products or business units.

There is no universal standard for this yet, but current guidance suggests that accountability should follow control, not convenience. If a team can approve access but cannot revoke it, accountability is incomplete. If a security team can detect misuse but cannot change entitlements, containment is delayed. If a business owner can demand action but cannot define the identity purpose, governance becomes reactive.

Edge cases include break-glass accounts, third-party integrations, and automated workloads. Those identities often need exceptional access, but exceptions should still have named owners, expiry rules, and documented review. The same principle applies when compromise is caused by stolen tokens or API keys rather than password misuse: the incident still traces back to lifecycle decisions, not just an attacker event. NHI Management Group’s Ultimate Guide to NHIs is clear that offboarding and rotation gaps are common failure points, so accountability should include revocation and rotation readiness, not only access approval.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised identity is used for intrusion and exfiltration?
• Who is accountable when compromised cloud identities are used for fraud?
• Who is accountable when a compromised machine identity is used to reach sensitive systems?
• Who is accountable when payroll fraud succeeds through a compromised account?