Secure shared workstations by using short idle timeouts, automatic screen lock, and re-authentication before any privileged action. Presence-based locking can combine proximity signals, badge state, or local presence checks with the lock state, but it should never be the only control for protecting active sessions, cached credentials, or open admin tools.
Why shared workstations need stronger session controls
Shared workstations create a different session problem than personal endpoints because the next user is often another authorised person, not an attacker at the perimeter. The main failure mode is residual access, where an unlocked session, cached token, or remembered browser state lets the next person act as the previous user without fresh intent.
That means session security has to be designed around fast handoff and fast revocation. Short idle timeouts reduce the window for opportunistic misuse, while automatic screen lock breaks the most obvious path from physical access to active access. Re-authentication before privileged actions matters because a shared device can outlive the trust you placed in the last login.
Presence-based locking can add convenience, but it should be treated as an assistive signal, not a trust decision by itself. A proximity check, badge state, or local presence sensor can help decide when to relock or keep a session alive, yet the control still has to fail safe if the signal is missing, spoofed, or stale.
How session state becomes the real security boundary
On a shared workstation, the sensitive object is usually the live session rather than the device itself. Browser cookies, open admin consoles, terminal sessions, remote desktops, and cached credentials can all preserve authority after the person who opened them has walked away. If those artifacts remain valid, the workstation becomes a handoff point for privilege, not just a computer.
That is why teams should separate convenience from authority. A presence signal may determine whether the screen stays unlocked, but it should not determine whether an action that changes records, configures systems, or exposes data can proceed. Privileged workflows need a fresh authentication step because the risk is not just viewing data, it is continuing an existing authority chain without review.
This is also where session lifetime and session scope matter. The shorter the reuse window and the narrower the privilege carried in the session, the less damage a missed lock or delayed handoff can cause. Shared endpoints should therefore be designed to minimise what survives between users, especially in applications that keep long-lived browser sessions or local auth state.
What teams should verify before they trust the control
Workstation lock policy is only useful if it is actually enforced across the full path to sensitive actions. Teams should verify that the screen locks on inactivity, that privileged applications require re-authentication after lock or timeout, and that users cannot bypass the control by switching apps, using saved sessions, or relying on a local admin shell left open by someone else.
The best operational test is to simulate a handoff. Leave a session open, let the workstation go idle, wake it using the normal user path, and confirm what still works without fresh credentials. If the next user can still reach admin tools, approved workflows, or high-value data, the issue is not the lock screen, it is session persistence.
For environments that rely on proximity or badge-assisted presence, teams should also validate the failure cases. Ask what happens when the badge reader is unavailable, the sensor misreads presence, or the local device loses the signal. The correct answer is a conservative lock, not silent continuation.
Risk and Threat Considerations
Shared workstations are exposed to accidental privilege transfer, opportunistic misuse, and session theft if active state is left behind between users. The risk is highest when a workstation is used for regulated workflows, admin consoles, or browser-based access to sensitive systems, because one missed lock can expose both data and action authority.
Failure mechanism: The control fails when local presence is treated as equivalent to re-authentication, or when cached browser and application sessions remain valid after a user steps away. In that case the next person inherits an active session without having to prove who they are again.
Impact: An unauthorised or mistaken action can be taken under the previous user’s session, including data exposure, configuration changes, privilege misuse, or record alteration. The longer the session survives and the more privileged the open toolset, the larger the blast radius.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Fresh sign-in is needed before privileged actions on shared workstations. |
| IA-5 — Authenticator Management | Shared workstations depend on session and credential handling that limits reuse. | |
| AC-11 — Session Lock | Automatic locking directly addresses unattended shared workstation sessions. | |
| Recommendation — Require re-authentication before privileged actions and after session handoff. Shorten session lifetimes and prevent stale credentials from being reused across users. Enforce automatic session lock on inactivity and validate it across all user paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Shared workstation sessions need tight control over who can continue privileged access. |
| Recommendation — Restrict continuing access on shared endpoints to the minimum necessary after handoff. | ||
| NIST SP 800-63 | AAL2 — IAL/AAL guidance for reauthentication and session security | Re-authentication strength matters when a shared workstation resumes privileged work. |
| Recommendation — Use stronger reauthentication for privileged session resumption and sensitive actions. | ||
Practitioner Guidance
What to prioritise: Lock the workstation quickly, but put the stronger control at the point of action. The most important design choice is to require fresh authentication before privileged operations, because that is where the business impact concentrates.
What to verify: Confirm that inactivity lock, application session timeout, and privileged re-authentication all work independently. If one layer fails, the others should still prevent silent continuation of authority.
Common mistake: Treating badge or proximity-based presence as a full session control. Those signals are useful for user experience and convenience, but they should never be the only safeguard protecting cached credentials or open admin tools.
Practitioner takeaway: On shared workstations, the security goal is not merely to lock the screen, it is to prevent authority from surviving user handoff longer than it should.
Related resources from NHI Mgmt Group
- Guide: Healthcare Identity Security Guide
- How should agencies secure CJIS access on shared workstations without slowing operations?
- How should organisations secure shared workstations without slowing production down?
- How should manufacturers secure shared workstations that access CUI systems?
- How should teams secure shared remote sessions without losing productivity?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org