Who is accountable when an attacker persists through trusted infrastructure for months?

Accountability usually sits with the teams that own the management plane, identity controls, and incident validation process, not only the endpoint or SOC teams. Frameworks such as NIST CSF and NIST SP 800-53 place responsibility on access control, audit, and continuous monitoring, which is where long-dwell campaigns are decided.

Why This Matters for Security Teams

When an attacker persists inside trusted infrastructure for months, the failure is rarely a single control. It is usually a breakdown across ownership of identity, management access, logging, and incident validation. That makes accountability a governance problem as much as a detection problem. The question matters because long-dwell campaigns thrive in the space between platform teams, identity administrators, and SOC workflows, especially when privileged access is inherited rather than tightly bound to purpose.

NHIMG research shows how badly this can go in practice: the The 2026 Infrastructure Identity Survey found that 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic and infrastructure-heavy workloads. That is a warning sign for any environment where an attacker can blend into trusted automation, not just human logins. External guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that access control, auditability, and monitoring are control-owner responsibilities, not just SOC activities.

In practice, many security teams only discover this gap after the attacker has already used legitimate management access to move laterally, disable visibility, or persist through routine change windows.

How It Works in Practice

Accountability should be mapped to the control plane that allowed persistence, not only to the team that eventually found the intrusion. If the attacker lived off trusted infrastructure, then the critical questions are: who owned the privileged path, who approved or inherited that access, who monitored it, and who could revoke it quickly. That usually means shared responsibility across identity engineering, cloud or platform operations, and incident response, with the system owner holding final accountability for risk acceptance.

Practitioners should trace the campaign through the identity layer first. Did the attacker abuse standing admin rights, stale service accounts, over-broad API tokens, or automation credentials? The right answer often depends on whether access was human-issued, machine-issued, or delegated through an orchestration layer. NHIMG’s 52 NHI Breaches Analysis is useful here because it shows how persistent abuse often starts with identities that were never treated as continuously governed assets.

Operationally, a mature accountability model includes:

• clear ownership for privileged infrastructure identities and break-glass paths
• time-bound review of standing access, especially for automation and service accounts
• central logging for administrative actions, token minting, and policy changes
• continuous validation that monitored events match expected maintenance and deployment activity
• incident playbooks that assign decision authority for revocation, containment, and evidence preservation

This is consistent with the direction in MITRE ATT&CK Enterprise Matrix, where persistence and privilege abuse are tied to specific tactics, not vague “security failures.” Where attackers live inside trusted systems for months, the accountability gap usually sits in environments where management access is decentralized, service identities are long-lived, and no one is explicitly accountable for validating that privileged activity is still legitimate.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, so organisations have to balance rapid administration against stronger control ownership. That tradeoff becomes visible in managed cloud environments, MSP-operated platforms, and agentic automation pipelines, where multiple teams can legitimately touch the same infrastructure. Current guidance suggests naming one accountable owner per privileged control domain, even when execution is shared, because shared execution without named accountability makes post-incident attribution too slow to matter.

There is no universal standard for this yet, especially when autonomous systems can generate or consume access on the fly. In those cases, the accountable party may be the team that approved the policy for machine access, not the team that executed the task. That is why NHI governance discussions increasingly intersect with workload identity and policy enforcement, as reflected in NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks.

For incident response, the edge case is evidence gaps. If logging was incomplete, the accountability should expand to include the team responsible for telemetry coverage and retention, not just the responder who could not reconstruct the timeline. External advisories such as CISA cyber threat advisories reinforce the same practical lesson: long-dwell persistence tends to survive where identity, monitoring, and operational ownership are fragmented. In mature environments, the accountable owner is the one who could have prevented, detected, or revoked the trusted path sooner.

Related resources from NHI Mgmt Group

• Who is accountable when exposed edge infrastructure stays vulnerable after disclosure?
• Who is accountable when internal-only resources are exposed through SSRF?
• Who is accountable when an AI agent reads restricted files through a bypass?
• Who is accountable when an update infrastructure breach exposes users to malicious code?