Stop Impersonating Your Users: Why Identity-Level Impersonation Is Dangerous and What to Do Instead

Introduction

For years, many platforms have relied on a simple but risky mechanism when handling support requests: an admin clicks a button to “log in as the user.” It’s fast, convenient, and often built into legacy systems. But in 2025, this practice is outdated and it's recognized as a direct violation of modern security principles, compliance frameworks, and audit requirements.

Identity-level impersonation has played a role in several high-profile security incidents. The 2020 Twitter breach, where attackers gained access to an internal admin tool and posted messages from VIP accounts, demonstrated the impact of admin-level impersonation capabilities. RobinHood has faced similar internal-access controversies where support and admin tools granted direct access to customer accounts.

The pattern is always the same: when employees can assume another user’s identity, you lose the ability to enforce access boundaries and verify who actually performed an action. It’s a silent failure mode that becomes visible only when something goes wrong.

Fortunately, there's a better, safer, and fully compliant approach and it’s not only practical, it's becoming the new industry standard.

Identity-Level Impersonation

Identity-level impersonation occurs when a support agent, administrator, or internal operator gains access to a user’s account as if they were that user. This typically happens through:

• “Login as user” features in admin dashboards
• Forced session swaps or session hijacking
• Shared credentials
• Backdoor admin-mode access in authentication systems

The problem: your security model assumes identity = accountability, but impersonation breaks that link completely.

When someone “becomes” another user, several issues arise:

• Security boundaries dissolve. The system can no longer distinguish between the real user and the internal actor.
• Zero Trust becomes impossible. Zero Trust requires continuous identity verification. Impersonation muddies identity to the point where trust decisions are flawed.
• Audit trails become unreliable. You cannot prove who actually performed an action, which becomes a liability during investigations.

Identity impersonation may have been acceptable a decade ago. Today it’s an anti-pattern and one that violates core IAM principles and undermines security architecture.

Security & Compliance Risks

Security Risks

Identity impersonation introduces systemic vulnerabilities:

• Loss of audit trail integrity When support agents act under another user’s identity, logs no longer represent reality.
• IAM enforcement points cannot see privilege escalations Policies, checks, and entitlements assume the identity is correct. Impersonation bypasses all of it.
• Accountability gaps If a data deletion or configuration change occurs, there is no attribution.
• Multi-tenant architectures amplify the risk A single compromised support account can unlock entire customer organizations.
• Real world failures
  • Twitter 2020 breach: attackers exploited internal impersonation tools to post from celeb accounts.
  • RobinHood internal access issues: employees had direct access to customer accounts without audit controls.

Compliance Risks

Identity impersonation is not only dangerous, it often violates compliance controls outright.

• SOC2: breaks least privilege, accountability, and auditability requirements.
• GDPR: constitutes unauthorized access to personal data if the user did not consent to the session.
• HIPAA: violates minimum necessary access and requires detailed audit trails for every access event.
• PCI DSS: mandates strict separation of responsibilities and traceability. Impersonation cannot satisfy this.

Every modern compliance framework requires demonstrable attribution, which impersonation cannot provide.

Auditability Problems

Impersonation doesn't merely weaken logs, but in many cases invalidates them.

• Logs become misleading (“admin acted as user X”).
• You cannot reconstruct incident timelines.
• Legal and forensic review becomes impossible.

If you cannot prove who did what, you cannot pass an audit.

Why Teams Still Do It

Despite the risks, identity impersonation remains common in customer support workflows. Why?

• Operational convenience: easy to implement if the IDP allows it.
• Legacy systems: built long before Zero Trust principles.
• Support workflows: teams need visibility into user issues.
• Time pressure: solving tickets fast often overrides security rigor.
• Weak permissioning models: product teams lack fine-grained access control tooling.

This problem is solvable.

Permission-Level Impersonation

Instead of impersonating who a user is, grant support staff the permissions needed to view or interact with user resources.

Permission Shadowing

With permission shadowing:

• The support agent keeps their own identity.
• They temporarily receive fine-grained, user-equivalent permissions.
• The system consistently knows “Alice the support agent did X,” not “User123 did X.”

A policy engine like Ory Keto can model this pattern by defining fine grained relationships between objects in your application.

Time-Bound & Context-Aware Access

To prevent overreach, permission shadowing should be:

• Ephemeral: auto-expire after minutes or hours.
• Just-in-time (JIT): granted only when actively needed.
• Context-aware: tied to ticket references or explicit reason codes.
• Governed: through approver workflows or automation.

This ensures that elevated access is both controlled and auditable.

Strong Audit Logging

Permission-level access is only effective with visibility:

• Who requested access
• Who approved it
• What operations were performed
• Why access was needed

Systems like Ory Kratos (for identity) and Ory Hydra (for OAuth2/OIDC tokens with explicit scopes) can maintain verifiable audit logs and session metadata. Combined with structured events, this gives auditors what they expect.

A Better Support Workflow

Imagine a B2B SaaS platform where a customer cannot see certain dashboard data. Historically, support teams used a “log in as user” button to reproduce the issue: easy, but risky.

One SOC2 audit later, the team discovers:

• They can't prove which internal user accessed which customer accounts.
• GDPR rules classify impersonation sessions as unauthorized access.
• Their internal tool provided blanket admin read/write access.
• Multi-tenant data boundaries were far too permissive.

Permission-Level Access

The company redesigned support workflows:

• Ory Kratos handles user identity and support agent authentication.
• Ory Hydra issues an OAuth token containing a “support-session” scope, reason code, and maximum TTL.
• Ory Keto grants the agent least-privileged access to the customer’s data model.

Results:

• SOC2 passed without exceptions.
• GDPR compliance improved.
• Audit logs now show exactly which support agent performed each action.
• No identity impersonation required.

The support experience is just as fast but far safer.

Practical Steps to Move Away from Identity Impersonation

Here’s a migration path:

1. Map existing impersonation workflows Identify where and why your teams impersonate users today.
2. Define RBAC/ABAC models Layer permissions, attributes, or relationships based on actual business needs.
3. Model support permissions in a policy engine Replace impersonation with scoped, user-equivalent permissions.
4. Enable “support mode sessions” Session metadata records the reason, ticket reference, and duration.
5. Implement structured, immutable audit logs Include actor, action, scope, and expiration.
6. Introduce JIT and break-glass processes Keep elevated privileges rare, temporary, and observable.

This approach gives support teams the access they need without compromising trust or compliance.

Conclusion

Identity-level impersonation is a legacy pattern with modern consequences. It breaks fundamental security assumptions, undermines compliance requirements, and destroys auditability.

Instead of turning employees into your users, give them permission-based access that reflects the actions they need to perform while preserving their own identity. This aligns with Zero Trust principles, modern security frameworks, and the expectations of auditors and enterprise customers.

A modern, secure architecture separates identity from permissions. Platforms like Ory Kratos, Ory Hydra, and Ory Keto demonstrate how open-source components can help teams adopt these patterns with minimal friction.

The takeaway is simple: Stop impersonating identities. Start modeling permissions.

It’s safer, cleaner, and the way forward for secure support operations.

How can Ory help?

• Learn how Ory can help in your IAM journey - https://www.ory.com/ory-ecosystem
• Learn how Ory has helped other customers - https://www.ory.com/case-studies
• Learn how Ory compares to other alternatives - https://www.ory.com/comparisons