How Should Support Staff Impersonate a User Safely?

Should support staff be able to log in as a customer?

Usually yes, and almost never the way it gets built first. Impersonation solves a real problem: a customer describes a bug nobody can reproduce, and seeing their exact account settles it in seconds. The danger is that the fastest implementation is also the one with no visible boundary and no record.

We end up designing this feature on most B2B product work, and it is one of the few interfaces where the design decisions are mostly about restraint. What the support person cannot do matters more than what they can.

Here is the version we build, and the standards that decide the parts that are not a matter of taste.

Why do teams build impersonation at all?

Because the alternatives are slow and invasive. Without it, a support engineer asks the customer to screenshot their settings, walk through a flow on a call, or send credentials, which is the worst outcome of the three and happens more often than anyone admits.

It also solves the class of bug that only exists in one account: a permission combination, a legacy plan, a workspace with 4,000 records where a query times out. None of that reproduces on a test account.

So the question is not whether to build it. It is how to build it so that the capability does not quietly become the largest unaudited privilege in your product.

What does the interface need to make obvious?

That this is not a normal session, at every moment, on every screen. Our requirement is a persistent banner that cannot be dismissed, naming the customer being viewed and offering one click to exit.

Colour does a lot of work here. We give impersonation sessions a distinct treatment, typically a strong warning colour on the banner, because a support engineer with fourteen tabs open needs to know which one is somebody else's account before they click anything.

The failure mode this prevents is mundane and expensive: a support engineer writing an internal note, changing a setting, or sending a test message while inside a customer account, believing they are in their own. It happens because the interface looked the same.

Should the customer be told?

Our default is yes, and it changes the feature's character. A notification that support accessed the account, with a timestamp and the reason, turns a capability that feels like surveillance into one that reads as service.

The stronger version is consent: the customer grants access for a window, and the window expires. That is more work and it is the right design for anything handling sensitive data, because it means nobody can enter an account without a request that the customer approved.

The compromise we see most often is access without notification but with a full audit trail the customer can read. That is defensible. What is not defensible is a capability the customer cannot see at all, which is what almost every first implementation ships.

What should be read only?

More than teams expect. Our starting position is that an impersonated session can see everything and change nothing, and each write permission has to be argued for individually.

Some are easy to refuse. Nobody in support needs to delete a customer's data, change their billing plan, invite users, rotate their API keys or modify their security settings from inside their account. Those are administrative actions that belong in your own admin tool, with your own audit trail, not in a borrowed session.

The cases worth allowing are narrow and usually about unblocking: resending a verification email, clearing a stuck job, toggling a feature flag the customer asked about. Write those down as a list rather than granting write access broadly. This sits alongside the general permissions model, which we covered in designing roles and permissions in SaaS.

What has to be logged?

Everything, and OWASP's logging guidance gives you the shape. It says to always log "authentication successes and failures", "authorization (access control) failures", "user administration actions such as addition or deletion of users, changes to privileges", and the "use of systems administrative privileges or access by application administrators".

That last line is the one impersonation falls under. Each entry needs OWASP's four essentials, "when, where, who and what": a timestamped date in an international format, the application and location, the source address and user identity, and the event type with the object affected.

The identity field is where impersonation needs care, because there are two identities. The log has to record both the support person who acted and the customer account they acted in. A record showing only the customer is worse than no record, because it attributes your employee's action to your customer.

Is there a standard for this specifically?

Not that we could find, and that is worth saying plainly. OWASP's logging cheat sheet is thorough about administrative access and contains no specific guidance on logging actions taken on behalf of another user.

So the dual-identity requirement is our own design rule rather than a citation. We hold it anyway, because every incident review that involves impersonation starts with the question "who actually did this", and a single-identity log cannot answer it.

OWASP is clear on protecting the record itself: "build in tamper detection so you know if a record has been modified or deleted", store or copy log data to read-only media as soon as possible, and record and monitor all access to the logs. Impersonation logs are exactly the ones someone would want to edit.

How should the access itself be granted?

Narrowly, and by exception rather than by role. OWASP's authorization guidance is to assign users "only the minimum privileges necessary to complete their job" and to adopt a deny-by-default mentality, where the application "must always make a decision, whether implicitly or explicitly, to either deny or permit the requested access".

Applied here, that means impersonation is not a permission that comes with the support role. It is granted to named individuals, ideally for a period, and reviewed. A support team of thirty does not need thirty people who can enter any account.

Two more OWASP rules matter for the implementation. Permissions must be "validated correctly on every request, regardless of whether the request was initiated by an AJAX script, server-side, or any other source", and you must "never rely on client-side access control checks". A banner hiding the delete button is a user interface courtesy, not a control.

What should happen when the session ends?

A clean, deliberate exit and a record of it. The support person clicks exit, lands back in their own account, and the log gets a session end entry with a duration.

We also set a hard timeout, shorter than your normal session length, because the realistic failure is not malice but distraction. Somebody opens an account to check a setting, gets pulled into a call, and the tab sits open for six hours.

And the exit has to be genuinely clean. Nothing from the impersonated session should persist: no leftover workspace context, no cached permissions, no draft that saves into the wrong account later. That is the same class of bug as workspace switching, which we wrote about in designing workspace switching.

What are the alternatives worth considering?

Two, and both reduce how often impersonation is needed. The first is a support view: a read-only rendering of the customer's configuration and recent activity in your own admin tool, with no session in their account at all. This answers most support questions and carries none of the risk.

The second is customer-initiated screen sharing or a session replay the customer consented to. Slower for you, more comfortable for them, and appropriate for regulated customers who will not accept staff access at all.

Our advice is to build the read-only support view first and impersonation second, because teams that do it the other way round never build the support view, and impersonation becomes the default answer to every question. The audit surface that makes all of this legible is the same one we described in designing an audit log interface.

What would we build first?

The read-only support view, a permanent unmissable banner, dual-identity logging, a short timeout, and impersonation granted to named individuals rather than to a role. That is a week of work and it is the difference between a feature you can describe in a security review and one you hope nobody asks about.

The part teams skip is the customer-facing side, and it is the part that earns goodwill. Telling a customer that support entered their account, when, and why is a small act of transparency that no competitor is bothering with.

If you are designing this into a product now and want a second opinion on where the boundaries should sit, we are happy to go through it. Reach us at phoenix.studio.