06.03 · Concept
Impersonation, Audit Logs & Privileged Access
Let support see what a user sees without creating an invisible super-admin, and make every privileged action attributable after the fact.
Support impersonation should preserve two identities: the support agent performing the action and the user or tenant being affected. Safe designs use scoped, temporary access with visible context, reason capture, and audit records that make privileged actions reviewable, attributable, and distinct from normal user activity.
What this lesson answers
- how should support impersonation be audited
- how to avoid hidden super admin access
- what should privileged access logs contain
Notes
Support impersonation should be designed as delegated, temporary access, not as a hidden master password. The support agent keeps their own identity, requests or is granted a narrow ability to view or act as a specific user, and the system carries both identities through every request: the real actor and the affected user. That lets support reproduce user-specific state while preserving accountability.
A useful mental model is a signed visitor badge. The badge says who the employee is, which customer account they may enter, what rooms they may access, why they are there, and when the badge…
References
Common questions
- Why is logging in as the user a bad support pattern?
- It erases attribution. If support and the customer share the same effective identity, later logs cannot reliably show who performed an action. That weakens incident response, compliance review, and abuse detection. A better design keeps the agent identity attached to every impersonated request.
- What should an impersonation session include?
- An impersonation session should be scoped to a specific user or tenant, limited by permissions, tied to a clear reason, and expire automatically. The interface should make the mode obvious to the agent. Sensitive operations should require stronger controls, such as explicit approval or separate authorisation.
- What belongs in an audit log for privileged access?
- The log should record the real actor, the affected user or tenant, the action taken, the authorisation result, the reason, request context, and relevant state changes. The goal is to reconstruct what happened after the fact without confusing customer behaviour with support activity.
Short definition: what is Impersonation, Audit Logs & Privileged Access?