The device stops behaving like a controlled access point and starts behaving like a lingering trust boundary. Credentials, sessions, and access context can survive the handoff, which weakens accountability and makes it harder to prove that each user only saw what their role allowed.
Why a Shared Workstation Stops Being Safe
A shared workstation depends on the handoff between users being real, not cosmetic. If the browser, desktop session, token cache, or application state survives that handoff, the device is no longer a neutral access point. It becomes an extension of the previous user’s authority, which creates continuity where the workflow assumes separation.
That distinction matters because shared devices often sit in high-trust environments such as clinics, trading floors, call centers, and service desks. When state remains behind, the next person can inherit more than convenience: they may inherit active access paths, recent context, or visible data that was never meant to persist.
What State Leakage Changes for Access Control
The main break is not just privacy leakage, it is access-control failure. A lingering session can let the next user act under the previous user’s authenticated context, which undermines role boundaries and makes attribution unreliable. Even when the next user is legitimate, the system can no longer prove that each action came from the right person at the right time.
This is why shared-workstation design has to treat logout, cache clearing, and session teardown as security controls, not cleanup tasks. The workstation should forget enough state that the next login starts from a clean trust boundary. Where it does not, the device creates a hidden shortcut around ordinary authentication and authorization checks.
The practical result is that organizations lose confidence in two things at once: who accessed the system and what that person could see or do. That is especially damaging in environments where multiple users share the same physical terminal but have different roles, shift boundaries, or data access limits.
Why Shared Devices Become Hard to Govern
Shared-state failures are difficult to govern because they are intermittent and user-dependent. One user may leave behind only harmless UI state, while another leaves an authenticated browser session, a cached bearer token, or an active remote desktop connection. That variability makes the workstation look compliant until the exact moment a handoff goes wrong.
In regulated or high-sensitivity workflows, the break also affects auditability. If the device cannot reliably clear prior context, then logs, screenshots, and session records may not line up with the actual person at the keyboard. That weakens investigations, recertification, and any control that assumes a clean start for each user.
For healthcare teams, the issue is especially sharp because the same workstation may be reused across many clinicians during a shift. Healthcare identity security guidance for shared workstations shows why tap-and-go, session teardown, and workstation re-locking have to be treated as part of clinical access control, not optional convenience features.
Risk and Threat Considerations
When state is not cleared, the workstation can expose prior sessions, cached credentials, and application context to the next user. That creates a direct opportunity for accidental data disclosure, unauthorized actions, and impersonation-by-continuity, especially when applications trust the local session more than the current person.
Failure mechanism: The device preserves authenticated or semi-authenticated state across users, so the next person inherits trust that was intended to expire at handoff.
Impact: A subsequent user can view sensitive data, continue a prior task, or perform actions that appear to belong to the previous user, which breaks accountability and increases the blast radius of a compromised or careless session.
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 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers credential and token lifecycle on shared workstations. |
| IA-2 — Identification and Authentication (Organizational Users) | Shared workstations rely on strong user re-authentication at every login. | |
| AC-6 — Least Privilege | Lingering sessions can silently expand privilege beyond the current user. | |
| Recommendation — Enforce timely invalidation and rotation of authenticators after each user handoff. Require each user to authenticate independently before accessing the workstation. Limit workstation sessions so no user inherits more privilege than required. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared workstation state directly affects who can access what and when. |
| Recommendation — Define and enforce access rules that prevent inherited access between users. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Control | State clearing is part of maintaining controlled access at handoff. |
| Recommendation — Implement managed access controls that end prior-user access before the next login. | ||
Practitioner Guidance
What to verify: Test the full handoff path, not just the logout button. Verify that the browser, local application cache, remote session, and any device-specific credentials are all invalidated before the next user can begin work.
What good looks like: A new user should reach a fresh authentication step, see no prior user context, and have no access to prior files, queues, messages, or open transactions unless the workflow intentionally preserves them through an approved transfer process.
Common mistake: Teams often equate screen locking with state clearing. A locked screen protects against casual access, but it does not guarantee that the underlying session, token, or application context is gone.
Practitioner takeaway: Treat shared workstations as security boundaries that must be reset between users; if the reset is incomplete, the problem is not inconvenience, it is a broken trust boundary.
Related resources from NHI Mgmt Group
- What breaks when shared mobile devices stay signed in between users?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?