Shared-Device Access

An access pattern where multiple users authenticate through the same endpoint or workstation, often seen in healthcare and operational environments. It weakens simple one-user, one-device assumptions and requires stronger identity proofing, session control, and audit evidence to preserve accountability.

Expanded Definition

Shared-device access describes an access model where multiple people authenticate from the same kiosk, workstation, thin client, or shared terminal. In NHI and IAM operations, the device is not the identity, so policy must rely on stronger proofing, session context, and audit trails rather than a simple one-user, one-device assumption. That distinction matters because healthcare carts, call centers, manufacturing floors, and emergency operations often prioritize continuity over individual endpoints. Definitions vary across vendors on whether the term includes shared browser sessions, pooled virtual desktops, or only physical devices, so organisations should define the boundary explicitly. For governance, the practical baseline is alignment with Zero Trust principles and device-aware access controls as described in OWASP Non-Human Identity Top 10 and the broader guidance in Ultimate Guide to NHIs.

The most common misapplication is treating a shared terminal as proof of a trusted user session, which occurs when access logs capture only the device and not the authenticated person.

Examples and Use Cases

Implementing shared-device access rigorously often introduces workflow friction, requiring organisations to balance faster throughput against tighter session isolation, step-up authentication, and more detailed logging.

• In a hospital ward, nurses use the same workstation, but each badge tap or re-authentication step must create a distinct audit event so medication access can be traced to an individual.
• In a warehouse, a picking terminal is shared across shifts, so short-lived sessions and automatic lockout help prevent one worker from inheriting another worker’s access context.
• In a customer service centre, operators log into a pooled desktop environment, but role-based access control and OWASP Non-Human Identity Top 10 style secret handling remain necessary when service tools or automation accounts are used from the same endpoint.
• In field operations, a rugged tablet may be shared among technicians, so session revocation and device posture checks need to work even when the hardware is temporarily reassigned.
• In crisis response, a shared command-room terminal may access sensitive systems, and organisations should use the lessons from 52 NHI Breaches Analysis to keep shared access from becoming a weak point for credentials and secrets.

For identity proofing and session assurance, practitioners often pair shared-device workflows with patterns informed by the Ultimate Guide to NHIs — Key Challenges and Risks, especially where privileged tools or service credentials may appear on the same terminal.

Why It Matters in NHI Security

Shared-device access becomes risky when it blurs accountability between the human operator, the endpoint, and any NHI or secret used through that endpoint. A shared terminal can mask privilege misuse, create misleading attribution, and make incident response slower because investigators must reconstruct both the session holder and the device history. This is especially important when agents, service accounts, or API keys are accessed from pooled workstations, because the endpoint may be shared while the credential itself is not. The governance challenge is to preserve traceability without breaking frontline workflows. NHIs already outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs. That visibility gap gets worse when multiple users share endpoints and sessions are not cleanly separated.

Organisations typically encounter the consequences only after a suspicious access review, credential theft, or breach investigation, at which point shared-device access becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does device trust matter for CI/CD access decisions?
• How should organisations use device trust in privileged access decisions?
• Who is accountable when a shared clinical device exposes patient data?
• How should public safety agencies govern CJIS access across shared workstations and legacy applications?