An impersonating account is an account used to act as another identity for a session or transaction. Practitioners use the term for delegated or proxy access where one account can assume another account's privileges, often with audit logging, scope limits, and approval controls to preserve accountability.
What the term means in practice
An impersonating account is a controlled proxy identity: one account can act on behalf of another for a specific session or transaction without collapsing the two identities into one. That distinction matters because the proxy must preserve accountability, scope, and traceability while still enabling legitimate delegated action.
In practice, organisations use impersonation when a user, service desk operator, administrator, or automated process needs to perform work as someone else, but only under approved conditions. The key security question is not whether access is possible, but whether the resulting activity can still be attributed, bounded, and reviewed.
How impersonation differs from shared or generic access
Impersonation is not the same as a shared account, because the proxy relationship should remain explicit and temporary. A shared account removes ownership clarity; an impersonating account should preserve the originator, the actor, and the effective identity in logs and downstream controls.
It is also different from ordinary delegation in systems that simply pass a token or session to another component. Here, the important feature is that one principal is deliberately allowed to assume another principal's privileges, which creates a stronger need for policy checks, bounded scope, and clear authorization rules.
Where impersonation is used and why it exists
Impersonation is common in support workflows, privileged administration, customer service operations, and system-to-system activity where direct access would be too coarse or disruptive. It reduces operational friction by avoiding password sharing or manual workarounds, while still allowing the organisation to keep a tighter control boundary around who can act, when, and for what purpose.
Used well, it supports just enough access for a bounded task without permanently transferring the underlying privileges. That makes it useful in environments that need continuity of service, emergency access, or controlled delegation, especially where every action must later be explained to auditors or investigators.
Security implications and control expectations
The security value of an impersonating account depends on whether the environment preserves attribution, approval, and scope limits. Strong implementations log both the initiating account and the impersonated account, restrict which actions can be assumed, and make it obvious when the effective identity changes during a session.
Without those controls, impersonation can become indistinguishable from privileged misuse. The same mechanism that enables legitimate delegation can also hide excessive access, blur accountability, or let an operator perform actions that were never intended to be fully transferred.
Risk and Threat Considerations
Impersonating accounts concentrate trust, so failures usually show up as accountability loss, privilege overreach, or abuse of an approved proxy path. The main danger is that the organisation may believe it can reconstruct "who did what" when the session trail is incomplete or when the impersonation scope is broader than intended.
Failure mechanism: Attackers or insiders exploit the proxy relationship, weak approvals, or poor logging to carry out actions under a more trusted identity, then blend those actions into normal administrative or support activity.
Impact: Misuse can lead to unauthorized transactions, data access, privilege escalation, and delayed detection because investigators must untangle the actor, the proxy account, and the effective account after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Impersonation should limit assumed privileges to the minimum necessary. |
| IA-5 — Authenticator Management | Proxy access depends on controlled credentials or tokens that must be managed securely. | |
| AU-2 — Event Logging | Impersonation requires audit events that preserve actor and effective identity. | |
| Recommendation — Constrain impersonation to the smallest permitted privilege set. Protect and rotate the credentials or tokens used for impersonation. Log initiator, proxy use, target identity, and scope for each impersonated session. | ||
| OWASP ASVS | V8 — Authorization | Impersonation is an authorization decision about acting on behalf of another user. |
| V16 — Security Logging and Error Handling | The term depends on traceable records for accountability and investigation. | |
| Recommendation — Verify that delegated actions are explicitly authorized and scope-limited. Record impersonation events with enough context to support review and incident response. | ||
Practitioner Guidance
Governance implication: Treat impersonation as a privileged capability, not a convenience feature. Define who may impersonate whom, what actions are allowed, how long the proxy state can last, and which approvals are required before the session starts.
What to watch for: Pay close attention to gaps in audit logging, missing session attribution, and impersonation paths that bypass normal approval or step-up controls. A proxy model is only defensible when review teams can clearly see both the initiator and the effective actor.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org