Identity-level impersonation breaks auditability and Zero Trust controls

At a glance

What this is: This is an analysis of why identity-level impersonation is a security and compliance anti-pattern, and why permission shadowing preserves accountability while enabling support work.

Why it matters: It matters because IAM teams need support workflows that preserve attribution, enforce least privilege, and avoid turning operational convenience into an audit and access-control failure.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.

👉 Read Ory's analysis of identity-level impersonation and permission shadowing

Context

Identity-level impersonation is when one operator acts inside a user session as though they were that user. In IAM terms, it breaks the link between identity, permission, and accountability, which is why it collides with Zero Trust and audit requirements rather than simply creating a convenience trade-off.

The article argues that support teams should keep their own identity and receive permission-level access instead of taking over the user’s identity. That is a human IAM problem, but the governance pattern is familiar across NHI and autonomous systems too: preserved attribution, scoped access, and time-bound elevation are what keep operations defensible.

The practical question for security teams is not whether support needs visibility. It is whether that visibility can be granted without destroying non-repudiation, traceability, and least privilege in the same workflow.

Key questions

Q: What breaks when support teams use login-as-user access?

A: Login-as-user breaks the link between identity and accountability. The platform can no longer prove who performed the action, so audit trails become unreliable, policy enforcement can be bypassed, and investigations lose evidentiary value. The safer alternative is to keep the support agent’s identity intact and grant scoped permissions instead.

Q: Why do inaccurate identities create compliance risk?

A: Because compliance depends on proving who had access, why they had it, and when it changed. If identity records are stale or groups are misaligned, auditors see weak control over entitlement lineage. That turns access reviews into paperwork instead of evidence.

Q: How should teams implement support access without impersonation?

A: Use permission shadowing with RBAC or ABAC, add JIT elevation for support sessions, and tie every grant to a ticket or reason code. Keep the support operator’s own identity visible, limit the scope to the minimum required action, and set automatic expiry so the access cannot outlive the task.

Q: Who is accountable when an impersonated session causes a security incident?

A: The accountable party is usually unclear if the system hid the true actor. That ambiguity is exactly why impersonation is so risky. Governance should require a design where the operator identity, approved scope, and session metadata remain visible, so accountability is assigned to the person who actually performed the action.

Technical breakdown

Why identity-level impersonation breaks access control boundaries

Identity-level impersonation collapses two separate trust objects into one session. The platform can no longer distinguish the real user from the internal operator, so authentication context and authorization context become misaligned. That means policy decisions, entitlement checks, and audit logs all operate on a false identity. In a Zero Trust model, where every action should be attributable to a verified principal, this is a structural failure, not a logging weakness.

Practical implication: eliminate any workflow that changes the principal rather than the permissions.

Permission shadowing and session-scoped support access

Permission shadowing keeps the operator’s identity intact while granting temporary, fine-grained access to the resources needed for support. This is usually implemented with RBAC or ABAC plus JIT elevation, reason codes, and explicit expiry. The important shift is that access is modelled as an authorization change, not an identity substitution. That preserves traceability while still letting support teams troubleshoot effectively.

Practical implication: design support workflows around scoped permissions and short-lived sessions, not shared or borrowed identities.

Audit trails, attribution, and compliance evidence

When an operator uses another user’s identity, the audit trail becomes misleading at best and invalid at worst. Investigations lose the ability to prove who accessed what, when, and why, which directly affects SOC 2, GDPR, HIPAA, and PCI DSS evidence. Modern auditability depends on structured events that record actor, action, scope, and expiration, so the control design has to preserve provenance from the start.

Practical implication: require immutable logs that retain the operator identity alongside the affected resource and approved scope.

Threat narrative

Attacker objective: The objective is to perform actions inside another user’s account without leaving a trustworthy attribution trail.

1. Entry occurs through administrative support features such as login-as-user, forced session swaps, shared credentials, or backdoor admin access.
2. Escalation happens when the internal operator inherits the target user’s permissions and the platform can no longer enforce identity boundaries accurately.
3. Impact is loss of attribution, unreliable audit evidence, and a broader blast radius if a single support account can reach many customer tenants.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity-level impersonation is an accountability failure, not a support feature. The security model assumes that identity and action remain linked, and that assumption breaks the moment one person can become another inside the system. Once that happens, every downstream control that depends on a stable principal, including audit, approval, and investigation, becomes unreliable. The practitioner conclusion is simple: do not treat impersonation as an access pattern.

Permission shadowing is the correct governance model because it separates what the operator is from what the operator can do. That distinction matters across human IAM, NHI, and autonomous access patterns. In all three cases, the system has to preserve provenance while granting only the minimum necessary scope. The field should therefore treat permission-scoped access as the norm and identity substitution as the exception that modern governance should retire.

Zero Trust cannot coexist with hidden identity substitution at the session layer. Zero Trust requires continuous verification of the actual principal, not a borrowed one. When the system silently swaps identity context, policy enforcement and telemetry both lose fidelity. The implication for architects is that support access must be modeled as explicit authorization on top of authentic identity, not as an alternate identity state.

Identity substitution without attribution: This article exposes the governance assumption that an operator can safely assume a user identity without weakening accountability. That assumption was tolerable in legacy admin models, but it fails under modern audit and compliance expectations because the actor and the action are no longer provably linked. The practitioner conclusion is to redesign around preserved identity and scoped permission instead of borrowed identity.

Support workflows need JIT, reason-coded, and expiring access because standing admin pathways create a permanent trust gap. The article’s permission shadowing model shows the right direction: preserve operator identity, scope the action, and expire the privilege. That pattern is relevant beyond support tooling because the same governance logic applies to service accounts and agentic systems. The practitioner conclusion is to make ephemeral authorization the default for any high-risk assistance workflow.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how weak revocation discipline extends exposure windows.
• Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right next step for teams formalising offboarding and revocation controls.

What this signals

Identity substitution without attribution is a useful concept for security architects because it describes a class of workflow that looks operationally efficient but destroys non-repudiation. The same pattern appears in NHI and agentic AI programmes whenever one principal is allowed to inherit another principal’s permissions without preserving provenance. Teams should align support workflows with NIST Cybersecurity Framework 2.0 and keep identity and authorization separately observable.

The broader programme signal is that access models built around convenience features will keep failing audit scrutiny unless they record actor, scope, and expiry together. In practice, that means support operations need the same discipline as privileged machine access: explicit grants, short duration, and clear ownership. The lesson generalises well beyond support desks because any hidden delegation chain becomes a governance blind spot.

For teams maturing identity governance, the issue is not only impersonation itself but the governance tolerance for invisible delegation. A workflow that lets one principal speak and act as another without an auditable boundary will keep colliding with compliance, incident response, and forensic reconstruction. That is why support access should be designed as a governed entitlement, not a hidden identity state.

For practitioners

• Remove identity-substitution features from support tooling Replace login-as-user, forced session swaps, and shared credentials with permission-scoped support workflows that preserve the operator’s own identity and session.
• Model support access with RBAC and ABAC Define the exact resource, operation, and context the support team needs, then express that access as scoped permissions rather than account takeover.
• Add ticket-bound JIT elevation Require a reason code, ticket reference, and automatic expiry for any elevated support session so the access can be reviewed and revoked cleanly.
• Log actor, action, scope, and expiry together Use immutable audit events that record the operator identity, the target resource, the approved scope, and the session duration in one record.

Key takeaways

• Identity-level impersonation breaks the core IAM assumption that the actor and the action remain linked.
• Permission shadowing preserves attribution while giving support teams the scoped access they actually need.
• The control that changes the outcome is not more admin power, but time-bound, ticket-bound, and fully attributable authorization.

Key terms

• Identity-Level Impersonation: A support or administrative pattern where one internal operator acts inside another user’s session as if they were that user. It breaks attribution and weakens access control because the system no longer sees the real actor behind the action.
• Credential Shadowing: Credential shadowing is the state where a secret or connector credential continues to work while sitting outside the normal ownership, review, or rotation process. It creates hidden operational trust. In identity programmes, the risk is not just exposure, but the loss of clear governance over an active credential.
• Non-Repudiation: Non-repudiation is the ability to prove what an identity did, when it did it, and under what authority. For autonomous agents, that evidence must include context, approvals, and tool usage so later review can reconstruct the decision path.
• JIT — Just-in-Time Access: A security approach that grants access permissions only for the duration needed to complete a specific task, then automatically revokes them. JIT access eliminates standing privileges for NHIs, dramatically reducing attack surface.

What's in the full article

Ory's full article covers the operational detail this post intentionally leaves for the source:

• A concrete migration pattern from login-as-user workflows to permission shadowing in support tooling.
• The role of Ory Kratos, Ory Hydra, and Ory Keto in separating identity, token scope, and fine-grained permissions.
• How to structure support-session metadata so auditors can trace who approved access, what scope was granted, and when it expired.
• The practical steps for layering JIT access and break-glass controls into existing support processes.

👉 Ory's full article covers the support workflow redesign, audit controls, and compliance implications in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.