Identity-level impersonation is a major security and compliance risk (SOC2, GDPR). Learn why legacy admin access is dangerous, and the new industry standard: Permission Shadowing.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
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 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:
The problem: your security model assumes identity = accountability, but impersonation breaks that link completely.
When someone “becomes” another user, several issues arise:
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.
Identity impersonation introduces systemic vulnerabilities:
Identity impersonation is not only dangerous, it often violates compliance controls outright.
Every modern compliance framework requires demonstrable attribution, which impersonation cannot provide.
Impersonation doesn't merely weaken logs, but in many cases invalidates them.
If you cannot prove who did what, you cannot pass an audit.
Despite the risks, identity impersonation remains common in customer support workflows. Why?
This problem is solvable.
Instead of impersonating who a user is, grant support staff the permissions needed to view or interact with user resources.
With permission shadowing:
A policy engine like Ory Keto can model this pattern by defining fine grained relationships between objects in your application.
To prevent overreach, permission shadowing should be:
This ensures that elevated access is both controlled and auditable.
Permission-level access is only effective with visibility:
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.
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:
The company redesigned support workflows:
Results:
The support experience is just as fast but far safer.
Here’s a migration path:
This approach gives support teams the access they need without compromising trust or compliance.
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.
