Look for automatic lock, reauthentication after inactivity, and clear session end behaviour that prevents one operator’s access from carrying into the next task or shift. If a workstation can stay active while its user is absent, the organisation cannot confidently tie actions to the right person or prove when authority ended.
What “strong enough” means for shared workstations
For shared workstations, strong session handling is not just about ending a browser session, it is about making sure the next person cannot inherit the previous person’s access state. The control is strong enough only when inactivity triggers lock or reauthentication, active sessions end cleanly, and cached access, open applications, or seamless badge tap flows do not let an absent user’s authority continue unchecked.
That standard matters because shared devices create a higher chance of task handoff, interrupted sessions, and accidental reuse. A workstation that stays open too long may still “work,” but it is not trustworthy if it cannot reliably separate one operator’s actions from the next operator’s actions.
What to test on the workstation itself
Start with the behaviour you can observe directly: does the workstation lock on inactivity, does it require reauthentication before resuming sensitive work, and does it force a fresh session at the end of a shift or task? Those three checks tell you whether the device resets trust between operators or merely hides a still-live session behind a screen saver.
You should also verify what happens after common disruption points, such as workstation sleep, network loss, application timeout, and user switching. If a user can walk away, return later, and continue exactly where they left off without any meaningful revalidation, the session model is too weak for a shared environment.
For environments with regulated or high-impact workflows, that same test should be applied at the application layer, not only the operating system layer. The right question is whether the sensitive action requires current, attributable presence, not whether the desktop happens to be unlocked.
Why session ending has to be explicit, not assumed
Shared workstations fail when “logout” is treated as an optional convenience rather than a security boundary. A strong design makes the end of authority visible: the session expires, the workstation locks, tokens or cached credentials are invalidated where appropriate, and the next operator must prove who they are before continuing.
That is especially important when one workstation is used across many shifts or by multiple roles. If session state survives too long, the real control point moves from the user to the device, and the organisation loses confidence that each action can be tied to the right person at the right time.
Current guidance for application and workstation session control is consistent on this point. Session handling should support short idle limits, reauthentication for sensitive actions, and predictable session termination so that access does not silently outlive the person who received it.
What strong session handling looks like in practice
A strong shared-workstation model gives the operator a clear start, a bounded active period, and a clean end. The start is authenticated; the active period is bounded by inactivity and task context; the end removes the practical ability to continue under the same trusted state. That is what separates a controlled handoff from an informal sharing arrangement.
On a well-run system, the next operator cannot inherit a browser tab, an open patient record, an admin console, or a privileged app session without being challenged again. If the workstation can do that consistently across core workflows, the session handling is probably strong enough for shared use.
For a deeper reference on authentication, session, and access-control expectations, see OWASP ASVS, and for implementation guidance across session management, the OWASP Cheat Sheet Series is a useful companion. In healthcare and other shared clinical environments, NHIMG’s Healthcare Identity Security Guide also addresses shared workstation behaviour in a practitioner setting.
Risk and Threat Considerations
Shared workstations are vulnerable when an active session outlives the person who opened it. That creates exposure for impersonation, unauthorized access, mistaken attribution, and abuse of unattended systems, especially where multiple staff members move through the same device during a shift.
Failure mechanism: The workstation retains a live or resumable session after inactivity, sleep, or user departure, allowing the next person to continue under the previous user’s authority or cached context.
Impact: Actions may be misattributed, sensitive data may be exposed, and privileged workflows can be continued without a fresh proof of identity or a clear end to the prior user’s authority.
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 ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V7 — Session Management | Shared workstation strength depends on session timeout, lock, and reauthentication behavior. |
| V6 — Authentication | Fresh proof of identity is needed when workstation access must not carry to the next operator. | |
| Recommendation — Enforce short idle timeouts and reauthentication before sensitive session resumption. Require reauthentication at task or shift boundaries on shared devices. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Shared workstations for staff depend on verifying the current operator before access continues. |
| IA-5 — Authenticator Management | Session strength depends on credential/session lifecycle that prevents stale access reuse. | |
| Recommendation — Verify each operator before allowing access after inactivity or handoff. Set credentials and session artifacts to expire or rotate before reuse across users. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared workstation session handling is an access-control boundary that must be enforced. |
| Recommendation — Define and enforce access rules that prevent one user’s session from carrying to the next. | ||
Practitioner Guidance
What to verify: Treat the workstation as strong only if you can demonstrate three outcomes in testing: idle lock occurs consistently, reauthentication is required before sensitive access resumes, and session end really ends access rather than merely hiding it. If any one of those fails, the shared model is incomplete.
Decision rule: If the device is used by multiple operators or across shifts, require a fresh authentication event at handoff boundaries and for any sensitive task continuation. If the workflow cannot tolerate that interruption, the problem is the workflow design, not the session control.
Practitioner takeaway: For shared workstations, the standard is not “the screen locks eventually,” it is whether authority reliably stops when the person stops using the device.
Related resources from NHI Mgmt Group
- How do you know whether endpoint controls are strong enough for a secrets manager?
- How do teams know whether password hashing is actually strong enough?
- How do you know whether AI-generated integrations are trustworthy enough for security use?
- How do you know if your authentication model is actually strong enough?