Who is accountable when a compromised identity is used for intrusion and exfiltration?

Accountability sits with the teams that own identity lifecycle, access governance, and incident response, because they control the evidence needed to confirm abuse and the controls needed to limit it. Frameworks such as MITRE ATT&CK, NIST incident handling guidance, and zero trust principles all assume identity events can be observed and acted on.

Why This Matters for Security Teams

When a compromised identity is used for intrusion and exfiltration, the accountability question is really about control ownership: who issued the identity, who approved the access, who monitored the activity, and who can revoke it fast enough to stop damage. In NHI environments, that often spans IAM, platform, security operations, and the application team. NHIMG notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why the failure is rarely just “someone got phished.” See the broader context in Ultimate Guide to NHIs and the pattern of real-world abuse in 52 NHI Breaches Analysis.

The practical risk is that teams often treat identity compromise as a downstream incident instead of a lifecycle failure. Once an attacker uses a valid secret, the actor appears legitimate to logging, network, and cloud control planes unless those systems are tuned to detect abnormal use. That means ownership must be explicit before an incident occurs, not negotiated during one. In practice, many security teams discover this only after the exfiltration path has already used a credential that was never clearly assigned, rotated, or monitored.

How It Works in Practice

Accountability should follow the control surface, not the attacker. The team that owns identity lifecycle is responsible for issuance, rotation, and offboarding. The team that owns access governance is responsible for least privilege, approvals, and periodic review. The incident response function is responsible for detection, containment, forensic preservation, and notification. In mature programs, these responsibilities are documented in a RACI, tied to control evidence, and exercised through incident playbooks.

For compromised NHIs, the operational question is not only “who is at fault?” but “who can prove what happened?” That is where log coverage, token provenance, secret inventory, and workload identity matter. Current guidance suggests pairing identity controls with zero trust principles so that a valid credential does not equal permanent trust. NIST’s zero trust model and incident handling guidance both assume rapid revocation and continuous verification, while agentic and machine identities require stronger workload-level proof. For implementation context, see NIST Zero Trust Architecture, NIST Computer Security Incident Handling Guide, and SPIFFE workload identity overview.

• Identity lifecycle teams should own secret issuance, rotation SLAs, and revocation paths.
• Access governance teams should enforce least privilege, approvals, and periodic entitlement review.
• Incident response should preserve evidence from identity providers, cloud control planes, and application logs.
• Platform teams should reduce standing access and prefer short-lived credentials for sensitive workloads.

Where this breaks down is in environments with shared service accounts, hard-coded secrets in pipelines, or third-party integrations that cannot be cleanly attributed to a single owner.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance rapid containment against developer autonomy and uptime expectations. That tradeoff becomes sharper when many systems share one credential, when a vendor manages part of the workflow, or when an API key is embedded in legacy automation. In those cases, accountability may be formally assigned to one team, but remediation depends on several.

Best practice is evolving for delegated and multi-party environments. If a compromised identity belongs to a third-party service, the internal owner still retains accountability for approving the integration, constraining privileges, and monitoring usage, while the supplier may hold operational responsibility for its own side of the incident. If the identity is an AI agent or autonomous workflow, the answer becomes more complex because static role-based access often fails against unpredictable behaviour. Emerging guidance from CISA Zero Trust Maturity Model supports stronger identity assurance, but there is no universal standard yet for agent-specific accountability. For that reason, controls should align to the evidence trails in Why NHI Security Matters Now and the compromise patterns documented in JetBrains GitHub plugin token exposure.

Where organisations still lack clear ownership, the first failure is usually not technical detection but delayed revocation and disputed responsibility after the fact.

Related resources from NHI Mgmt Group

• Who is accountable when DNS weaknesses disrupt access to identity services?
• Who is accountable when a hijacked subdomain is used for phishing or malware?
• Who is accountable when cloud identity gaps lead to audit findings or breaches?
• What breaks when identity fabric is used as a substitute for IAM cleanup?