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

Use phishing-resistant, passwordless authentication that works at the desktop or kiosk level, not a phone-dependent second factor. The control should support strong biometric enrollment, device-bound credentials, and role-specific access so users can authenticate without shared secrets or reusable keys. That reduces help desk friction, key sharing, and the risk of lost or stolen authenticators.

Why This Matters for Security Teams

Restricted shared-workstation environments are often treated as a simple access problem, but authentication design becomes a control boundary when mobile devices are prohibited. If users fall back to shared PINs, static passwords, or proximity workarounds, the workstation itself becomes the weakest link and auditability suffers. NIST’s control baseline for authentication and access enforcement, including NIST SP 800-53 Rev 5 Security and Privacy Controls, supports stronger identity proofing and session control, but only if the chosen method fits the physical environment.

For organisations that handle high-risk systems, this is not just an IAM convenience issue. The same patterns that drive NHI Mgmt Group’s ultimate guide to non-human identities also apply here: credentials must be bound to a specific context, limited in scope, and resistant to reuse. When authentication depends on a phone that is not allowed on the floor, teams either weaken policy or create shadow exceptions. In practice, many security teams discover the operational cost of that mismatch only after users start sharing badges, bypassing the process, or calling the help desk for manual overrides.

How It Works in Practice

The practical answer is to use phishing-resistant, desktop-native authentication that does not depend on a separate mobile authenticator. In most environments, that means workstation-level passkeys, platform biometrics, smart cards, FIDO2 security keys kept on-site, or kiosk-appropriate badge-plus-biometric flows. The key requirement is that the credential is device-bound or workstation-bound, so a successful login proves the user is present at the terminal and not simply holding a reusable secret.

Good implementations also separate authentication from authorisation. A user may prove identity at the shared workstation, but access should still be role-specific, time-limited, and tied to the application or task. That reduces lateral movement if a session is hijacked. Controls aligned to ISO/IEC 27001:2022 Information Security Management and NIST-style access management work best when paired with session timeouts, re-authentication for sensitive actions, and local account hygiene.

• Use one primary factor that works at the terminal, not a phone-dependent second factor.
• Prefer phishing-resistant credentials over SMS, OTP apps, or shared passwords.
• Bind the credential to the workstation, smart card, or managed security key.
• Apply least privilege so login does not equal broad application access.
• Design a lost-device or failed-biometric recovery path that preserves auditability.

This approach also reduces credential sharing, because users no longer need to borrow a manager’s phone or rely on a common PIN. It maps cleanly to the kinds of identity failures seen in secrets-driven incidents, including the Twitter Source Code Breach and the Schneider Electric credentials breach, where weak credential handling expanded blast radius. These controls tend to break down in legacy shared-terminal fleets because older operating systems, thin clients, and disconnected kiosk workflows cannot always support modern phishing-resistant authenticators consistently.

Common Variations and Edge Cases

Tighter authentication often increases friction, so organisations have to balance user throughput against assurance. That tradeoff is especially visible in factories, labs, healthcare stations, and clean-room style environments where gloves, masks, or hygiene rules make phone use impractical and biometrics less reliable. Current guidance suggests that a single control should not be forced into every shift pattern; best practice is evolving toward a menu of approved methods with equivalent assurance, rather than one universal workflow.

Edge cases usually come down to exception handling. Shared admin workstations may need step-up authentication for privileged tasks, while standard users need only a quick local login. Offline environments may require cached, short-lived credentials, but those should still be revocable and tightly scoped. If biometrics are used, organisations need a fallback that does not degrade to shared secrets. If smart cards or security keys are used, they should be individually assigned, tracked, and replaced through a formal recovery process.

For policy design, the most reliable rule is simple: if mobile devices are banned, do not replace them with weaker convenience controls. Use a workstation-native method that is resistant to phishing, supports strong enrollment, and preserves accountability. In environments with intermittent network connectivity or heavily shared kiosks, this guidance breaks down when local identity proofing and session revocation cannot be enforced centrally.

Related resources from NHI Mgmt Group

• How should security teams handle authentication for shared retail devices?
• How should healthcare organisations secure shared mobile devices without slowing clinicians down?
• How should organisations implement passwordless authentication in shared-device environments?
• How should healthcare organisations govern shared-use mobile devices safely?