Who is accountable when lateral movement reaches backups or identity systems?

Accountability sits across IAM, PAM, NHI governance, infrastructure, and incident response. If privileged paths were left open, or if service accounts were not scoped and reviewed, those are governance failures as much as technical failures. Frameworks such as NIST-CSF and ZT-NIST-207 help assign ownership for containment and trust reduction.

Why This Matters for Security Teams

When lateral movement reaches backups or identity systems, the incident stops being a single-host problem and becomes a trust collapse problem. Backup repositories, directory services, and identity providers sit on the path to recovery and privilege. If an attacker can tamper with those layers, containment, restoration, and accountability all become harder at the same time. The practical question is not just who detected it, but who owned the access paths that made it possible.

That is why NHI governance cannot be separated from infrastructure ownership and incident response. The NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain how backup admins, service accounts, and automation tokens often become the pivot point in real breaches. Attack patterns documented in the MITRE ATT&CK Enterprise Matrix show why defenders must assume privilege chaining, not isolated misuse.

In practice, many security teams encounter backup and identity compromise only after restore points are unreliable or directory trust has already been altered, rather than through intentional control testing.

How It Works in Practice

Accountability should follow control ownership, not just system ownership. If an attacker reaches backups, the first question is whether backup access was protected by PAM, scoped by RBAC, and isolated from routine administrative pathways. If they reach identity systems, the question expands to who owns directory tiering, who approves privileged service accounts, and who can revoke trust quickly. NIST guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it maps accountability to access control, auditability, incident handling, and recovery responsibilities.

Operationally, this usually breaks down into four accountable domains:

• IAM owns authentication, directory policy, conditional access, and review of privileged entitlements.
• PAM owns elevation paths, break-glass use, session recording, and privileged approval workflows.
• NHI governance owns service accounts, API keys, certificate lifecycle, and secret rotation.
• Infrastructure and IR own backup isolation, restore integrity, immutable copies, and containment playbooks.

The most important detail is that accountability must be written before the incident. If backup systems can authenticate with the same directory trust as production admin accounts, or if service accounts can read both workload data and recovery infrastructure, then the blast radius crosses ownership lines immediately. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce the same point: identity-related compromise is rarely confined to the first system touched, because stolen or over-scoped credentials tend to fan out into adjacent control planes.

Current guidance suggests organisations should define restore authority separately from daily administrative authority, and test whether an attacker who owns one identity plane can also alter recovery evidence. These controls tend to break down when legacy backup tooling still trusts domain admin paths because the recovery stack becomes another privilege bridge.

Common Variations and Edge Cases

Tighter separation of duties often increases operational overhead, requiring organisations to balance faster recovery against stronger trust boundaries. There is no universal standard for this yet, but best practice is evolving toward isolated backup identities, offline or immutable recovery copies, and separate approval chains for directory recovery actions. That is especially important where backup software, hypervisors, and identity services share the same administrative domain.

Edge cases are usually where accountability becomes disputed. In a managed service model, the provider may operate the backup platform while the customer still owns identity policy and recovery authorization. In hybrid environments, one team may own on-prem directory services while another owns cloud identity and secrets management. In both cases, the incident should be traced to the control that failed, not simply the console that showed the alert. The NHI Mgmt Group’s What are Non-Human Identities section is a useful reminder that service identities, not just human admins, often hold the keys to both restoration and escalation.

Teams should also be careful with “break-glass” access. If emergency accounts are not time-bound, monitored, and separately reviewed, they can become standing privilege under a different label. In environments with shared domain admin, weak backup segmentation, or long-lived automation tokens, accountability quickly blurs because the same credential path can touch both recovery and identity control planes.

Related resources from NHI Mgmt Group

• Who is accountable when a public SAP exploit leads to lateral movement into identity systems?
• Who is accountable when lateral movement reaches sensitive systems?
• Who is accountable when a platform breach reaches campus identity systems?
• Who is accountable when a false identity reaches critical business systems?