Log both identities on every event, not just the user or just the support engineer. Record when impersonation starts and when it ends, because duration matters for incident review and governance. The customer should also have a visible record, since internal-only logs do not provide the independent confirmation needed to distinguish legitimate support activity from unauthorized access.
What should an impersonation log prove?
An impersonation record should make the event independently understandable after the fact: who acted, on whose behalf, when the switch started, when it ended, and what scope of access was used. That is the difference between a useful audit trail and a vague support note. If a record cannot support incident review, customer dispute handling, and governance review, it is not complete enough.
For auditors, the key question is whether the log can reconstruct the access path without relying on memory or side channels. For customers, the key question is whether the record clearly shows that a support or admin session was bounded and attributable, rather than hidden inside a generic account history. In practice, the log should answer both questions with the same event data.
Good impersonation logging also treats duration as a first-class fact. A short, time-bounded session is very different from a long-running delegated view, especially when the session can expose sensitive data or support a high-risk action. When organisations only log the destination account, they lose the context needed to judge whether the access was reasonable.
How should the log entry be structured?
The strongest pattern is to log both the original actor and the impersonated identity on every event, plus the transition points that mark the change in authority. That usually means a start event, an end event, and any material actions taken while impersonation was active. The record should be easy to correlate across systems, not trapped in a single console or ticket note.
Separate fields are better than free text because they can be searched, reviewed, and reconciled. A useful entry normally includes the initiating user, the impersonated customer or target identity, the support engineer or privileged operator, the reason or ticket reference, timestamps, and a unique session identifier. Where the platform supports it, preserve both the display identity and the stable internal identifier so naming changes do not break later review.
Visibility to the customer matters as much as internal retention. A customer-facing history, portal entry, or equivalent notification gives independent confirmation that the event occurred and helps resolve disputes about unauthorized access. Internal-only logging may satisfy a system owner, but it does not give the customer a practical way to verify what happened to their account.
What makes impersonation logging trustworthy?
Trustworthy logs are tamper-resistant, time-synchronised, and consistent across the workflow. If the start time comes from one system, the end time from another, and the actions from a third source, the organisation needs reliable correlation and retention so the session can still be reconstructed. Without that, the audit trail becomes fragile when someone needs it most.
The log also needs to reflect the actual authority used, not just the label attached to the session. In delegated access flows, the control question is whether the actor used impersonation, proxying, or a higher-privilege path to perform actions on behalf of another identity. The record should make that distinction visible so reviewers can tell normal support activity from privilege abuse.
When impersonation is used across customer support, admin operations, or cross-account troubleshooting, RFC 8693 token exchange is a useful reference point for thinking about delegated identity and on-behalf-of flows. If the platform can exchange or mint tokens for impersonation, the logs should show the delegation chain clearly enough to support review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Impersonation needs auditable events with actor, target, time, and action context. |
| AU-3 — Content of Audit Records | The question hinges on what details must be captured to reconstruct the session. | |
| AU-12 — Audit Record Generation | Impersonation logs require systematic generation at the point of access transition and use. | |
| Recommendation — Define impersonation events as auditable records with start, stop, actor, target, and ticket context. Record both identities, timestamps, reason, and session identifiers in each impersonation event. Generate audit records automatically when impersonation starts, ends, and when actions occur. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Impersonation requires logs that support later review, investigation, and accountability. |
| A.8.16 — Monitoring activities | Customer-visible and internal monitoring help detect and verify impersonation activity. | |
| Recommendation — Log impersonation with enough detail to reconstruct who acted, when, and under what authority. Monitor impersonation sessions and expose reviewable evidence to support verification and dispute handling. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | This topic is fundamentally about preserving high-value event evidence for review and accountability. |
| Recommendation — Centralize and retain impersonation logs with actor, target, start, end, and correlation data. | ||
| NIST Zero Trust (SP 800-207) | Verify Explicitly | Impersonation should be verifiable and bounded rather than assumed from internal-only records. |
| Recommendation — Require independent verification of delegated access before trusting the session as legitimate. | ||
Practitioner Guidance
What to prioritise: Capture the start, end, actor, target identity, and ticket or reason code as separate fields before you optimise the UI. If those elements are missing, you cannot reliably distinguish approved support access from silent account misuse.
What to verify: Confirm that customer-visible records exist and that they reflect the same session identifier as the internal audit trail. If the customer portal cannot independently confirm the event, the record is weak for dispute handling even if the backend log is detailed.
Common mistake: Logging only the impersonated account or only the operator account. That loses the relationship between the two identities and makes duration-based review, incident triage, and accountability much harder.
What good looks like: A reviewer should be able to answer, from the log alone, who initiated impersonation, why it started, when it stopped, and what access was exercised during the window.
Practitioner takeaway: Treat impersonation as a bounded identity relationship, not a generic admin action, and log it in a way that both auditors and customers can independently verify.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
