Who is accountable when impersonation leads to unauthorised access?

Accountability sits with the organisation that approved access without enough assurance. Security, IAM, help desk, and risk teams all share responsibility for defining when proofing is required, especially for onboarding, lockouts, and privileged actions. Frameworks such as identity assurance and Zero Trust place that responsibility on the control owner, not the attacker.

Why This Matters for Security Teams

Impersonation is not just a user training problem. It becomes a governance failure when an identity proofing step, help desk override, or privileged reset grants access to the wrong party. Under the OWASP Non-Human Identity Top 10, and the control structure in NIST SP 800-53 Rev 5 Security and Privacy Controls, accountability sits with the organisation that designed and approved the access process, not the attacker who abused it.

This matters because impersonation often succeeds through routine operations: onboarding exceptions, account recovery, vendor support, or a rushed privileged reset. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows how quickly weak assurance turns into real access exposure. In practice, many security teams discover the accountability gap only after the access path has already been abused, rather than during the approval process itself.

How It Works in Practice

Operational accountability usually starts with defining who owns the proofing standard for each access path. Security owns the policy, IAM owns enforcement, the help desk owns recovery workflows, and risk or compliance owns the control expectations. If any of those groups allow impersonation-prone actions without strong identity assurance, the organisation is accountable for the resulting unauthorised access.

The practical control is not perfect detection after the fact. It is prevention through assurance. For human identities, that means binding recovery and privileged access to documented proofing, step-up verification, and audit trails. For NHI and agentic workloads, the same logic applies through workload identity, short-lived credentials, and runtime policy checks. NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privileges and poor visibility make impersonation far more damaging once access is granted.

• Require a named control owner for identity proofing and recovery.
• Use just-in-time access for privileged actions instead of standing access.
• Separate help desk verification from approval authority for resets and overrides.
• Log every recovery event, token issuance, and privilege elevation for review.
• Apply Zero Trust assumptions so a successful login does not equal broad trust.

These controls tend to break down in high-volume service desks and federated environments because identity proofing becomes fragmented across tools, vendors, and exception paths.

Common Variations and Edge Cases

Tighter identity proofing often increases friction, requiring organisations to balance recovery speed against impersonation resistance. That tradeoff is real, especially for executive accounts, break-glass access, and third-party support channels where business pressure pushes teams toward weaker checks.

There is no universal standard for every recovery scenario, so current guidance suggests risk-based proofing rather than one fixed process for all access. For low-risk workflows, lighter verification may be acceptable if the blast radius is limited. For privileged access, lockout recovery, and delegated admin actions, stronger proofing is the safer default. The same principle applies to NHI operations: if a service account, token, or API key can act with broad authority, impersonation of that identity becomes an organisational responsibility issue, not just a technical one.

One useful way to frame accountability is to ask who could have prevented the unsafe grant. If the answer is the organisation that approved the access path, the root cause is control design. If the answer is a third-party operator, the organisation still remains responsible for setting assurance requirements and monitoring compliance. That is why frameworks like identity assurance and Zero Trust place emphasis on control ownership, evidence, and enforcement rather than blame assignment after the incident.

Related resources from NHI Mgmt Group

• Who is accountable when privileged login controls fail to block unauthorised access?
• Who is accountable when middleware bypass leads to unauthorised access?
• Who is accountable when an exposed DevOps secret leads to unauthorised access?
• Who is accountable when a control failure leads to fraud or unauthorised access?