Identity control on a reused endpoint where multiple people access the same workstation or terminal across a shift. The core challenge is preserving attribution, session separation, and policy enforcement when the device is not tied to one person or one role for the full workday.
Expanded Definition
Shared device identity describes the identity and access pattern used when a workstation, kiosk, handheld terminal, or other reused endpoint is shared by multiple people across a shift. The device itself becomes the access surface, so governance must preserve attribution, isolate sessions, and apply policy without assuming one device equals one person. In NHI operations, this often sits beside NIST Cybersecurity Framework 2.0 principles for access control and auditability.
Definitions vary across vendors on whether the identity is tied to the device, the shift, the role, or a temporary credential bundle. No single standard governs this yet, so the term is best treated as an operational pattern rather than a formal identity class. The practical goal is to ensure that a shared terminal can enforce RBAC, support JIT access where appropriate, and keep the device from becoming a standing access proxy for every user who touches it. The most common misapplication is treating the shared workstation as a generic logged-in account, which occurs when teams reuse one session across multiple operators and lose per-user attribution.
Examples and Use Cases
Implementing Shared Device Identity rigorously often introduces sign-in friction and session-handling overhead, requiring organisations to weigh faster floor operations against stronger attribution and control.
- Retail or warehouse kiosks where a worker scans a badge, receives a shift-bound session, and the terminal logs every action under that person rather than a permanent shared login.
- Healthcare nursing stations where clinicians rotate through a cart or workstation and the device must separate charting sessions, especially when access is governed by NIST Cybersecurity Framework 2.0 access safeguards.
- Factory tablets used by multiple operators, where a local session is paired with a short-lived credential and device posture checks to prevent inherited access from the previous user.
- Security operations consoles where analysts use a shared screen or terminal but must still preserve named accountability for actions, approvals, and incident changes.
- Shift-based environments that adopt patterns discussed in the Ultimate Guide to NHIs and the Top 10 NHI Issues, especially when shared endpoints interact with service accounts, badges, or API-backed workflows.
In practice, shared-device design often needs to coordinate with PAM, reauthentication prompts, and automatic logoff to avoid one user inheriting another user’s access context. The strongest patterns also borrow lessons from incident writeups such as the JetBrains GitHub plugin token exposure, where exposed credentials made session boundaries irrelevant once the secret was available.
Why It Matters in NHI Security
Shared Device Identity matters because the device can become a hidden concentrator of privilege, secrets, and audit risk. If attribution is weak, a single terminal can blur accountability across many operators, making it hard to determine who approved a transaction, launched an API call, or changed a policy. That matters in NHI-heavy environments because device workflows often touch service accounts, tokens, and other Non-Human Identities that should never be broadly reusable. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, a sign that shared terminals can easily become blind spots when they are paired with unmanaged secrets or stale sessions.
That visibility problem becomes worse when shared devices are also used to access consoles, vaults, or agent tooling without strong session separation. For organisations trying to align with Zero Trust Architecture, the issue is not just login control but continuous verification of the operator, the device state, and the action being taken. Breach analyses in the 52 NHI Breaches Analysis show how quickly exposed credentials and weak boundaries can turn convenience into compromise. Organisationally, this becomes operationally unavoidable only after a shared kiosk, terminal, or shift workstation is tied to an incident and investigators can no longer reconstruct who did what.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared terminals create identity reuse and session-boundary risk covered by NHI access guidance. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and traceable permissions are central to reused endpoint control. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of user, device, and session even on shared endpoints. |
Assign one verified operator context per session and remove reusable shared credentials from shared devices.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
