What happens when impersonation is not clearly flagged inside the application?

When impersonation is not clearly flagged, support staff can accidentally take risky actions as the user, including changing data they should only inspect. That creates a higher chance of mistakes, makes audit reviews harder, and can confuse both users and internal teams about who performed a given action. A visible banner or warning helps prevent those errors.

Why clearly flagging impersonation changes the outcome

Impersonation is safe only when the person acting understands they are operating in a borrowed context. Without a clear banner or warning, the interface makes ordinary administrative actions look like they are being performed under the support user’s own authority, which increases the chance of accidental edits, missed verification, and disputed actions.

This is not just a usability issue. The application is shaping the operator’s mental model of authority. When that model is wrong, even careful staff can approve or change the wrong record, follow the wrong workflow, or overlook the fact that their action will be attributed to the impersonated user.

Where the control fails in practice

Clear impersonation signalling works because it separates inspection from action. A visible banner, strong page-level cue, or persistent status indicator tells the operator that every click, save, and approval is being made in a sensitive context, not a normal session. Without that cue, the application encourages trust in the wrong identity context and hides the boundary that should slow the user down.

That failure becomes more serious when the impersonated account has broader access than the support agent expects. In that case, the interface is not only masking context, it is also making high-impact actions feel routine. The result is a higher likelihood of unintended data changes, confused approvals, and poor traceability during review.

For teams testing this behaviour, OWASP ASVS is a useful reference point because this issue sits at the intersection of authentication context, session handling, and authorization clarity. In environments that expose application or service accounts to interactive use, PCI DSS v4.0 also reinforces the need to restrict access by business need and to control account use carefully.

How teams should design and review impersonation flows

Impersonation should be treated as a high-risk mode, not a convenience feature. The best implementations make the state impossible to miss, keep the cue visible across navigation, and make exit from impersonation obvious. If the operator can switch contexts without losing the visual reminder, the control is too weak.

Reviewers should verify three things: first, that the impersonation state is persistent across the full workflow; second, that action logs clearly show both the acting user and the impersonated subject; and third, that privileged operations require an extra checkpoint when context changes. That combination reduces accidental misuse and makes later audit work defensible.

Where the application supports delegated access or on-behalf-of actions, the underlying model should be explicit enough that the operator can tell whether they are inspecting data, changing data, or acting as another user. RFC 8693: OAuth 2.0 Token Exchange is relevant here because it formalises delegation-style token exchange patterns that should be paired with clear user-facing signalling. For broader control design, NIST SP 800-53 Rev. 5 provides the access control, audit, and session-management discipline that underpins safer impersonation handling.

Risk and Threat Considerations

Unclear impersonation creates both operational risk and abuse potential. Internally, staff may edit records they meant only to inspect, and externally, a poorly signposted impersonation path can make it easier to hide who actually performed a sensitive action.

Failure mechanism: the interface fails to separate “acting as” from “looking at”, so the operator applies the wrong level of trust to the screen and proceeds with changes that should have triggered hesitation or a second check.

Impact: unauthorized or unintended data modification, weaker audit confidence, disputed accountability, and a higher chance that a security review cannot reconstruct the real decision path cleanly.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while PCI DSS v4.0 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP ASVS	V6 — Authentication	Impersonation depends on clear authentication context and session state.
	V7 — Session Management	Impersonation changes session context and must stay visible through navigation.
Recommendation — Verify that the UI always shows when the operator is in an impersonated session. Persist the impersonation indicator across the full session lifecycle.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Impersonation can expose broader authority than the operator should use.
	AU-3 — Content of Audit Records	Audit logs must show who acted and whose context was used.
Recommendation — Limit what actions are available while impersonating another user. Record both the acting user and impersonated subject in audit events.
PCI DSS v4.0	7.0 — Restrict access to system components and cardholder data by business need to know	Impersonation increases the need to tightly constrain when elevated context is usable.
Recommendation — Restrict impersonation capability to justified business cases and approved roles.

Practitioner Guidance

What to verify: confirm that impersonation is visible in every page state where action is possible, not only on the first screen after switching users. If the banner disappears during navigation, modal dialogs, or embedded views, the control is not dependable.

Decision rule: if the impersonated context can perform write, approve, or admin actions, treat the session as high risk and require stronger logging, explicit attribution, and an obvious exit path. If the context is read-only, the warning should still remain persistent, but the operational risk is lower.

Common mistake: teams often assume that a small badge, subtle colour change, or one-time popup is enough. In practice, the reminder must be unmistakable and durable, because the point is to prevent humans from drifting into the wrong authority model.

Practitioner takeaway: impersonation is only safe when the application continuously reminds the operator that authority has been borrowed, because the main failure mode is not malicious misuse, it is preventable confusion about who is really acting.