Who is accountable when a known identity attack path is not addressed?

Why This Matters for Security Teams

When a known identity attack path remains open, the issue is rarely technical ambiguity. It is usually a failure to assign ownership for a risk that was already visible in threat modelling, incident review, or control testing. In identity security, attack paths such as credential stuffing, recovery abuse, session hijacking, and social engineering often persist because they sit between teams: IAM, fraud, SOC, application owners, and business leadership.

That ambiguity matters because accountability is what turns a known weakness into a funded fix. Without an explicit owner, controls can be “understood” but not implemented, or implemented in one system while the same exposure remains elsewhere. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this view: organisations need governance, not just tooling, to ensure risk decisions are traceable.

For boards and executives, the key question is not only whether the attack path is known, but whether someone accepted the risk with evidence, expiry, and review. In practice, many security teams encounter accountability failures only after an identity breach, rather than through intentional risk acceptance.

How It Works in Practice

Accountability should follow the decision chain, not the incident chain. If a known identity attack path is left unaddressed, the accountable party is the leader who approved the exception, the control owner who failed to enforce the safeguard, or the executive who accepted the residual risk without a documented review cycle. In mature environments, this is usually formalised through risk registers, control owners, and exception workflows tied to business systems rather than security ticket queues.

Practically, teams should map the attack path to the control that would have interrupted it, then assign one owner for remediation and one owner for acceptance. For example, if account recovery can be abused, the issue may span identity proofing, help desk process, and fraud monitoring. If privileged access can be obtained through a known path, the control owner may sit in IAM or PAM, but the operational risk owner may be in the application or platform team. Using the MITRE ATT&CK Enterprise Matrix helps teams describe the abuse pattern in a shared language, while CISA cyber threat advisories provide current context for how those patterns are exploited in the wild.

A workable process usually includes:

• Documenting the exact attack path and business impact.
• Assigning a control owner and a risk owner with named approval authority.
• Setting a remediation date or a time-bound exception with compensating controls.
• Recording review evidence for audit, board reporting, and incident retrospectives.

Where agentic AI is involved, the same logic applies to autonomous workflow ownership, tool access, and escalation paths. The emerging threat picture described in Anthropic — first AI-orchestrated cyber espionage campaign report shows why unchecked execution authority must be tied to a human decision owner. These controls tend to break down when identity, fraud, and platform teams each assume another group owns the recovery or privilege path because the weakness sits across multiple systems.

Common Variations and Edge Cases

Tighter accountability often increases governance overhead, requiring organisations to balance faster delivery against stronger decision traceability. That tradeoff is real, especially in high-change environments where exceptions are frequent and ownership changes often.

There is no universal standard for this yet, but current guidance suggests that known attack paths should never remain in an indefinite “accepted” state. A short-lived exception with compensating controls is defensible; a permanently open path with no named review is not. In regulated environments, the burden is heavier because the decision trail may be examined after a breach, not just during an audit.

Edge cases appear when the attack path is inherited from a third party, a legacy system, or a shared service. In those situations, the accountable party is still internal if the organisation chose to keep the exposure in production. Vendors may own a component, but the business owner still owns the residual risk. For AI-enabled systems, MITRE ATLAS adversarial AI threat matrix is useful where the attack path involves model manipulation, prompt injection, or tool misuse rather than classical account abuse. The practical test is simple: if the organisation can explain who approved the risk, how it is monitored, and when it will be revisited, accountability exists; if not, the gap is organisational, not technical.

Related resources from NHI Mgmt Group

• Who is accountable when a social engineering attack succeeds through support channels?
• Who is accountable when identity visibility is too weak to support resilience testing?
• What is the difference between attack surface management and NHI governance?
• When does a machine identity become a compliance problem?