Shared-use device

What Shared-Use Devices Are

Shared-use devices are endpoints that multiple people use across different sessions, such as clinical workstations, nurses’ stations, kiosks, tablets, or mobile devices. Their security challenge is that the hardware no longer identifies the person in control, so the environment must preserve attribution, isolate sessions, and prevent one user’s activity from carrying over to the next.

That makes shared-use design different from a one-person endpoint. The device may be trusted as an asset, but the current user, active session, and recorded actions all need separate control and validation.

Why Shared-Use Devices Need Extra Security Controls

The core problem is attribution failure: if a shared device keeps a user signed in, preserves cached data, or leaks session state, the next person can inherit access or leave actions tied to the wrong individual. In regulated environments, that creates both privacy exposure and audit ambiguity.

Shared devices also compress risk. A weak sign-out process, local credential storage, or shared application session can turn a convenience endpoint into a high-trust pathway for patient records, internal systems, or other sensitive workflows. The device itself is not the identity boundary, the session is.

For a broader treatment of locking down kiosks and shared endpoints across platforms, see Kiosk and Shared Device Security Guide.

Session Isolation and Attribution on Shared Endpoints

On shared-use devices, the security model should assume that each session is temporary and separable. That means the previous user’s tokens, browser state, application cache, downloads, clipboard history, and local files must not remain available to the next user unless there is an explicit workflow for retention and re-authentication.

Strong attribution depends on linking each action to the right person, not just the right device. In practice, that usually means distinct sign-in events, enforced sign-out between users, and controls that clear or compartmentalise the session when the user is done. Where the workflow depends on passwords or stronger authenticators, shared endpoints also need user-friendly sign-in methods that do not force unsafe workarounds, such as credential sharing.

NHIMG’s Shared and Generic Accounts Governance Guide helps explain why shared credentials and shared account patterns weaken attribution and control.

When organisations want smoother sign-in on frontline or clinical shared devices, passwordless methods can reduce friction without sacrificing accountability. See Passwordless for Frontline and Shared Devices Guide for the authentication patterns that fit shared-device use cases.

Operational Patterns, Hardening, and Auditability

Shared-use devices usually need a tighter operating model than personal endpoints. Common patterns include kiosk mode, assigned access, managed guest sessions, single-app restrictions, automatic profile clearing, and strict limits on local storage. The goal is to make the device fast to reset and hard to misuse.

Auditability is equally important. Logs should show who signed in, when the session started and ended, what app or record context was opened, and whether the session was terminated cleanly. Without that evidence, investigations become guesswork and access reviews lose credibility.

Shared devices also need lifecycle governance, because the risk is not only the current session but the accumulated configuration drift over time. A device that starts as a controlled clinical workstation can become exposed if local exceptions, unmanaged apps, or ad hoc account handling are allowed to pile up.

For device-mode patterns such as kiosks, locked-down tablets, and shared PC configurations, Kiosk and Shared Device Security Guide provides the practical control model.

Risk and Threat Considerations

Shared-use devices create risk when one user’s session, credentials, or cached data can survive into the next session. In high-trust environments, that can expose sensitive records, blur accountability, and enable unauthorised actions that appear to come from the wrong person.

Failure mechanism: Residual session state, shared accounts, or incomplete sign-out lets the next user inherit access, replay actions, or view data that should have been cleared.

Impact: Organisations can lose audit integrity, trigger privacy breaches, and create a practical path for misuse of clinical, operational, or administrative systems.

Practitioner Guidance

What to watch for: Treat a shared-use device as a session-control problem first and a hardware problem second. The key governance question is whether each user’s actions can be cleanly attributed and fully separated from the previous user’s context.

Governance implication: If the device supports sensitive workflows, define who owns sign-in, sign-out, session clearing, local data handling, and audit review. Those responsibilities should be explicit, because shared endpoints fail when everyone assumes the device boundary is enough.

Practitioner takeaway: The safer the shared device, the less it behaves like a persistent personal workstation and the more it behaves like a controlled, resettable access terminal.

Related resources from NHI Mgmt Group

• How should teams use access analytics in shared-device environments?
• How should security teams use step-up verification for hidden vault items in shared or unattended device scenarios?
• Should organisations use shared or dedicated device clouds for testing?
• How should security teams use shared signals in IAM response?