Accountability usually sits with the programme owner who governs the exposed identities, the control owner responsible for detection coverage, and the business leader who accepted the residual risk. For regulated sectors, that also extends to board-level oversight of resilience testing and access governance, because persistent access is a control failure, not just an intelligence event.
Why This Matters for Security Teams
When a state-linked intrusion succeeds through trusted access, the failure is rarely a single bad login. It usually reflects weak identity governance, incomplete detection coverage, or a risk decision that allowed standing access to persist longer than it should have. For security teams, the accountability question matters because it determines whether the issue is treated as an intelligence anomaly or as a control breakdown that requires remediation, evidence, and escalation.
Current guidance suggests that accountability should follow control ownership, not just incident chronology. If an account, token, service identity, or privileged workflow was abused, the owner of that access path must be able to explain why it existed, who approved it, and how it was monitored. That is especially important in environments that rely on machine-to-machine trust or delegated automation, where identities are often overlooked until after compromise. The NIST SP 800-53 Rev 5 Security and Privacy Controls framework makes that control ownership expectation explicit across access and monitoring disciplines.
In practice, many security teams encounter this question only after persistence has already been established, rather than through intentional review of the identities that made the intrusion possible.
How It Works in Practice
Accountability for trusted-access compromise should be mapped across three layers: identity governance, security monitoring, and business risk acceptance. The identity layer owns the existence and lifecycle of the account or secret. The security layer owns the ability to detect anomalous use, privilege escalation, or lateral movement. The business layer owns the decision to accept residual exposure when controls are not immediately remediated.
For non-human identities, the same logic applies to API keys, workload credentials, certificates, automation accounts, and federated trust relationships. The operational question is not simply “who logged in,” but “who approved the trust path, who monitored it, and who could revoke it.” That is why the OWASP Non-Human Identity Top 10 is relevant here: it highlights how unmanaged secrets, excessive privileges, and poor lifecycle controls create a durable access surface that attackers can reuse.
A practical accountability model usually includes:
- an identity or platform owner for lifecycle and revocation
- a control owner for logging, alerting, and detection tuning
- a system or application owner for business justification and access approval
- a risk owner or executive sponsor for residual risk acceptance
- board or audit oversight when the environment is regulated or material to resilience
Evidence collection should show the approved purpose of the access, the last review date, rotation or expiration status, and whether monitoring covered expected behaviour. Where identity is federated, shared, or delegated across suppliers, accountability also extends to contract and assurance mechanisms, because the control failure may sit outside the organisation that first detected the intrusion. These controls tend to break down when service identities are created ad hoc for automation or emergency access, because ownership becomes unclear and revocation is delayed.
Common Variations and Edge Cases
Tighter access governance often increases operational overhead, requiring organisations to balance rapid delivery against traceable control ownership. That tradeoff becomes more difficult in incident response, where teams may want to preserve access for investigation while also limiting attacker dwell time.
One genuine edge case is shared accountability in managed services or supply-chain environments. If a third party held the trusted access, accountability does not disappear, but it becomes split between the provider’s control obligations and the customer’s oversight duty. Another common exception is emergency or break-glass access. Best practice is evolving here, and there is no universal standard for this yet, but current guidance favours short-lived access, strong logging, and post-use review rather than permanent exceptions.
Where privileged automation is involved, the question often turns to whether the organisation treated the identity as a first-class asset. If a workload credential was never inventoried, never rotated, or never tied to an owner, accountability becomes hard to reconstruct after the fact. That is why identity governance should be treated as an operational resilience issue, not only an IAM administration task. For control design, security teams should align trusted-access reviews to the monitoring and audit expectations in NIST control families, then make sure every exception has a named owner and a review date.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA | Trusted access failures map to identity assurance and access governance. |
| OWASP Non-Human Identity Top 10 | Non-human identities often create the trusted access path used in these intrusions. | |
| NIST SP 800-53 Rev 5 | AC-2 | Accountability depends on formal account lifecycle control and assignment. |
Assign owners for each trusted access path and review whether it can be revoked, monitored, and justified.
Related resources from NHI Mgmt Group
- Who is accountable when identity-based attacks move through trusted access paths?
- Who is accountable when a BEC attack succeeds through a trusted mailbox?
- Who is accountable when lateral movement succeeds through approved access paths?
- Who is accountable when an AI agent causes production access through a trusted proxy?
