What should teams do first when users share the same workstation?

Why the first control is to split the session from the workstation

The core problem is that a shared workstation can preserve too much of the previous person’s state. The first move is to make the device behave like a neutral terminal, not a personal endpoint. That means the user logs in as themselves, the session is bounded to them, and nothing persists across handoffs unless the business has explicitly designed it to do so.

This is not just about convenience. Browser state, local files, cached tokens and unlocked applications can all carry over between users if the device session and the user session are treated as the same thing. The practical goal is to make the next login start from a clean trust boundary, not from the last person’s active state.

In practice, that usually means per-user profiles or virtual desktops, plus automatic screen lock and forced logout when the user switches. If the shared workstation is only a way to reach a personal or multi-session environment, the device should hold little or no sensitive state itself. The fewer local assumptions the workstation carries, the less one user can inherit from another.

What this protects against on a shared workstation

Shared endpoints fail when people assume the application or browser will “just reset itself.” In reality, many workstations keep authenticated sessions, cached credentials, clipboard contents, recent files or local application state long enough for the next user to see or reuse them. That turns a normal shift change, hot desk handoff or call-centre switch into an avoidable exposure point.

A second failure mode is privilege bleed. If a privileged user leaves an unlocked or still-authenticated session behind, the next person may inherit administrative reach without ever proving who they are. The right control is not to trust the device to sort that out later, but to ensure the workstation re-verifies the user and clears the old session before the next person starts.

For teams that want a broader view of session separation and related browser-state controls, Fetch Metadata and Resource Isolation Policy Guide is useful background on how isolation boundaries are enforced across request flows and user contexts.

How to make the handoff safe in day-to-day operations

The safest pattern is simple: a new person must authenticate as a distinct user, the old session must end cleanly, and any residual device state must be stripped away or isolated. If the organisation allows shared logons, the workstation will almost always become a shared trust problem as well as a shared device problem.

Where privileged access is part of the workflow, treat the workstation as a staging point, not as the authority itself. Use PAM checkout for elevated access and session recording when the user is doing sensitive work, so the elevated activity is both time-bounded and attributable. That keeps the shared device from becoming a hidden persistence layer for privileged actions.

When identity, access, and session control are involved, teams should align their operating model with the basic access-control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially the controls around authentication, access enforcement and session handling. Shared workstations are a practical test of whether those controls are actually enforced, not just documented.

Risk and Threat Considerations

Shared workstations create a real exposure when user state persists beyond the intended handoff. The main risk is not the device itself, but the trust the next user can inherit through open sessions, cached credentials or residual application state.

Failure mechanism: A previous user remains authenticated, or their browser and local profile retain enough state for the next person to reuse active access, view data or continue a session without re-authenticating.

Impact: Confidential data exposure, unauthorized action, privilege misuse and false attribution become much more likely, especially where the workstation is used for customer service, shared operations or admin workflows.

Practitioner Guidance

What to prioritise: Make the login handoff, not the physical workstation, the security boundary. If the device cannot reliably clear sessions and profiles between users, treat that as a control gap rather than a usability issue.

What to verify: Confirm that switching users really ends the old session, removes access to previous browser state, and prevents the next person from inheriting tokens, open documents or unlocked applications. If privileged work is allowed, verify that elevation requires a fresh checkout and that recording is enabled for the full session.

Common mistake: Relying on auto-lock alone. Locking the screen helps, but it does not solve leftover authentication state, local data persistence or browser session reuse.

Practitioner takeaway: On a shared workstation, the first objective is to break continuity of access between people, because session continuity is what turns a convenience setup into an exposure path.

Related resources from NHI Mgmt Group

• Why does kubectl access become risky when multiple clusters or users share the same workstation?
• How should security teams handle authentication when users, digital IDs, and AI agents share the same trust model?
• What breaks when multiple users share the same privileged AWS login?
• How should security teams reduce cloud data breach risk when users and applications share the same environment?