Notifications
Clear all
Topic starter
20/08/2026 5:21 pm
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
20/08/2026 6:12 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity-level impersonation breaks auditability and Zero Trust controls
