Identity-level impersonation: what does it break for IAM teams?

TL;DR: Identity-level impersonation lets support staff act as users, which breaks auditability, undermines Zero Trust, and can create compliance failures under SOC 2, GDPR, HIPAA, and PCI DSS, according to Ory. The safer pattern is permission shadowing, where operators keep their own identity while receiving time-bound, policy-scoped access that preserves attribution.

NHIMG editorial — based on content published by Ory: Stop Impersonating Your Users: Why Identity-Level Impersonation Is Dangerous and What to Do Instead

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.

Questions worth separating out

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

A: Login-as-user breaks the link between identity and accountability.

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.

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.

Practitioner guidance

• 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.

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.

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

Identity-level impersonation: what does it break for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →