How should organisations handle authentication in restricted shared-workstation environments where mobile devices are not allowed?

Why shared workstations need a different authentication pattern

Restricted shared-workstation environments change the authentication problem from “prove who the user is” to “prove it quickly, safely, and without depending on a personal phone or a reusable secret.” The practical goal is to preserve strong assurance while still fitting kiosk, shift-based, or regulated floor operations, which means the sign-in method has to survive device sharing, rapid turnover, and limited user-owned hardware.

That usually pushes organisations toward passwordless sign-in at the desktop or kiosk layer, paired with device-bound credentials and role-specific access. The authentication method must work on the shared endpoint itself, not via a phone-based approval step that can be bypassed, forgotten, or simply unavailable during work.

For teams designing the control, the key question is whether the authentication factor is bound to the workstation session and the intended user, rather than to a shared password or a second device the user may not have on the floor. Passwordless for Frontline and Shared Devices Guide is the most direct pattern for this operating model because it focuses on sign-in flows built for shared tablets, handhelds and PCs.

What good authentication looks like on a shared desktop or kiosk

Good design starts with a strong local authentication experience, then constrains what that authenticated user can do. In practice, that means biometric enrollment or another phishing-resistant method that is bound to the workstation session, not a phone prompt, SMS code, or cached password. The point is not to add friction, but to remove weak fallback behaviour that shared environments often create.

The shared device itself also needs clear session separation. Users should authenticate into a role or task context, complete work, and then leave no usable session behind for the next person. That is why shared-device mode, automatic sign-out, and local session clearing matter as much as the authenticator choice. Kiosk and Shared Device Security Guide is useful here because it ties authentication to the realities of kiosk lockdown, shared accounts and session cleanup.

When passwordless is implemented well, the workstation can authenticate a person without exposing a reusable secret that other users can observe or reuse. Passwordless and Passkeys Guide is relevant for the assurance model because it explains how passkeys and FIDO2 support phishing-resistant sign-in and device-bound credentials.

How to keep shared-workstation authentication from becoming a new weak point

The main failure mode is usually not the authenticator itself, but the exception handling around it. If an organisation allows password fallback, shared PINs, repeated enrolment shortcuts, or helper workflows that bypass the local control, the workstation becomes a convenience layer over a weaker identity system. The result is often predictable: people share access paths, support teams reset too much, and auditability drops.

Another common issue is treating the shared workstation as the only control boundary. Authentication has to be matched by authorization, because the person who signs in on a kiosk may only need access to a narrow task set, not the full application surface. Role-specific access limits blast radius if a session is misused or left open. The desktop is only secure when the workstation, the session and the permissions are designed together.

Where organisations want a broader identity pattern for workforce access, Workforce Identity Security Guide helps connect phishing-resistant MFA, passkeys, SSO and account recovery to the shared-device context. For assurance standards, NIST SP 800-63 Digital Identity Guidelines is the most relevant external reference because it anchors phishing-resistant authentication and authenticator assurance concepts.

Risk and Threat Considerations

Shared workstations raise the stakes of weak authentication because one poor sign-in pattern can expose many users, many sessions, and many downstream systems. If the environment relies on passwords or phone-dependent second factors, attackers and insiders can exploit shared visibility, session reuse, help-desk recovery paths, or stolen authenticators to gain access that looks routine.

Failure mechanism: Weak or shared authentication methods make it easier for a later user, an observer, or a phisher to reuse access paths, while stalled sessions and broad roles increase the damage from a single successful sign-in.

Impact: The organisation can lose attribution, create cross-user access leakage, and make theft or misuse of a workstation session materially more damaging than the original login event.

Practitioner Guidance

What to prioritise: Start by removing phone-dependent and secret-based fallback paths for the shared-workstation population. If the user cannot reliably carry a personal device, the workstation authentication flow itself has to carry the assurance burden.

What to verify: Check that the chosen method is phishing-resistant, supports device-bound credentials, and ends with a clean session transition. Verify that the next user cannot inherit cached access, remembered secrets, or a partially open application state.

Decision rule: If the workstation is shared across shifts or roles, prefer a local passwordless method with narrow authorization over any design that depends on reusable secrets plus recovery exceptions. If the control cannot survive a lost phone, it is the wrong control for this environment.

Practitioner takeaway: In shared-workstation environments, the authentication design must be usable without being portable, and strong enough that convenience does not reopen the very sharing problem the control is meant to prevent.

Related resources from NHI Mgmt Group

• Guide: Healthcare Identity Security Guide
• How should security teams handle authentication for shared retail devices?
• Why do shared mobile devices create identity risk in clinical environments?
• How should security teams handle identity verification on shared devices in frontline environments?
• How should security teams handle authentication when users sign in from unmanaged mobile devices?