Home / Knowledge hub / Impersonation feature
Knowledge hub
Impersonation feature
A support tool that acts as a customer, and the controls it needs around it.
What it means
An impersonation feature lets a support agent or administrator use your product as if they were a particular customer, so they can see what the customer sees and reproduce a problem. It is usually a button in an admin screen that swaps the agent's session for one tied to the customer's account.
It is a deliberate form of privilege escalation. That is acceptable when it is controlled. The danger is that the power to reach any customer's data now sits behind one switch, so the controls around that switch matter as much as the feature itself.
Why it matters
If an attacker, a careless employee or a compromised support account reaches the button, they reach customer data without needing a password. Impersonated sessions can also look like the customer's own activity, so a customer may be blamed for actions they never took, and an audit log that cannot tell the two apart is little use in an investigation.
Customers and auditors ask the same questions: who can use it, for how long, and what did they do. If you cannot answer from records, security questionnaires and contract reviews get awkward. And a flaw that lets an ordinary account trigger impersonation is a full account takeover of any customer.
How it shows up
You meet it as an Impersonate button in an admin panel, a support token passed in a URL, or an internal API that mints a session for a given account id. The usual weaknesses are checks made only in the interface, so the endpoint underneath accepts a request from any signed-in account, and support sessions that never expire.
Good controls are plain. Limit the feature to named roles, ask for a reason or ticket number, show a banner while it is active, cap the session length, block sensitive actions such as changing a password or payment details, and log both the agent and the customer. Then test the endpoint directly, not just the button.
Questions people ask
Impersonation feature, answered
Is impersonation the same as account takeover?
No, but a flaw in it can become one. Impersonation is a feature you built on purpose, for staff, with limits. Account takeover is an outsider ending up in someone else's account.
If a normal user can call the impersonation endpoint, the feature has turned into a takeover tool for anyone who finds it.
Should support staff be able to impersonate customers at all?
Many products do allow it, because it speeds up support. The question is how narrowly. Many teams prefer a read-only view, or the customer's explicit consent, over a full session.
If you do allow it, treat the control as a privileged function and review it as often as your admin panel.
What should an impersonation log record?
At minimum: who started it, which customer, when it began and ended, the reason given, and every action taken during the session. Tag those actions so they cannot be confused with the customer's own.
Keep these records somewhere support staff cannot edit, and make them easy to export for a customer who asks.
Can the customer be told when it happens?
Yes, and it is good practice. A notice or a visible entry in the customer's own activity history turns a hidden power into an accountable one.
Some products ask for consent first, with a time limit. That is the strongest version, though it can slow urgent support.
How do we test an impersonation feature?
Try the underlying request with accounts that should be refused, not just the staff interface. Check that the session expires, that blocked actions stay blocked, and that the log is accurate.
This is cross-account access testing, applied to one of the most sensitive functions you have.
Sources
Where this comes from
Related
Terms that sit next to this one
Privilege escalation
Gaining rights you were never given, sideways or upwards.
Audit log
A record of who did what and when, kept so you can answer later.
Broken function-level authorisation
Calling an API function your account was never meant to use.
Role escalation
Changing your own role, or another's, through a flaw in how roles are assigned.
Admin panel exposure
A management page left reachable by the public or by ordinary accounts.
Who can press the switch?
Support and admin functions are where cross-account access often hides. We check what each signed-in account can reach that it should not, and report the exact request that proves it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.