Accountability should sit with the organisation that owns the access model and the administrators who approve it. If shared usernames are allowed, the team must preserve compensating controls such as identity mapping, session logging, and reviewable audit trails. Without those controls, organisations cannot reliably assign responsibility for actions taken inside remote sessions.
Who owns responsibility when a workstation is shared by multiple people?
Accountability does not disappear just because a workstation is shared. The organisation that permits the access model remains responsible for the control environment, and the administrators who approve or operate it remain responsible for preserving evidence of who did what. In identity and access practice, the key issue is not whether one human logs into one device, but whether actions can still be attributed to a uniquely identifiable user or role.
shared workstation access becomes a governance problem when the access path no longer preserves individual attribution. That is especially important where remote access, privileged actions, or regulated workflows are involved, because the organisation must still be able to demonstrate who initiated the session and what authority they used. OWASP Non-Human Identity Top 10 is relevant here because it reflects the same accountability pressure that appears when identity is reused, pooled, or insufficiently governed. In practice, many security teams discover the lack of attribution only after an incident review, rather than through deliberate design.
How shared access should be traced in practice
Shared access is workable only when the surrounding controls preserve a defensible chain of responsibility. The practical test is whether the organisation can reconstruct three things after the fact: which person used the session, what they were authorised to do, and what they actually did. If any one of those is missing, the access model has moved from accountable sharing to unassigned control.
In real environments, this usually means the shared account itself is not treated as the source of accountability. Instead, accountability is established through adjacent controls such as unique operator sign-in before session launch, privileged access workflows, ticket or approval linkage, time-bound access, and immutable session records. Where the workstation is used for administrative or sensitive tasks, the session record needs to be strong enough to survive a dispute, an audit, or an investigation. That typically includes timestamped logs, origin details, action records, and a way to map the session back to an approved user or team. NIST guidance on security and privacy controls, including audit and accountability expectations, remains directly relevant to this problem space and supports the need for traceable system use.
- Use a unique human identity for the approval or launch step, even if the runtime session is shared.
- Record session metadata that links the activity to a named operator, shift, or role.
- Preserve audit trails in a way that makes later review feasible, not just technically possible.
- Separate approval authority from execution authority where shared access is unavoidable.
The guidance breaks down when the workstation, the application, or the remote session layer cannot preserve reliable attribution, because then the organisation is left with access but not accountability.
Where shared access stops being a tolerable exception
Tighter access sharing often reduces friction for operations, but it increases the burden on logging, supervision, and review, so organisations have to balance convenience against evidential value. The important distinction is between controlled sharing and anonymous reuse: the first can be governed, while the second usually cannot be defended after the fact.
There are a few edge cases where teams should be especially cautious. Shift-based operations, emergency break-glass access, and third-party support sessions sometimes justify shared endpoints or pooled workstations, but only if the accountability chain survives the exception. If the business cannot identify the operator without relying on memory, informal handoff, or a shared mailbox, then the model is not merely imperfect, it is non-attributable. That becomes more serious when the access also includes privileged functions, sensitive data, or regulated actions.
Organisations also need to distinguish between shared device access and shared identity access. A shared terminal in a controlled environment can still be accountable if each user authenticates individually before use. A shared username used by several people without compensating controls is a different condition altogether, because it erases the evidence needed for ownership, review, and discipline. Where the organisation cannot prove attribution, the issue is no longer operational convenience, it is a control failure.
In practice, shared access should be treated as an exception that must be time-bound, logged, and reviewable, because once attribution disappears, responsibility can no longer be assigned with confidence.
Risk and Threat Considerations
Shared workstation access without individual attribution creates a material accountability and investigation risk. It weakens non-repudiation, complicates incident response, and can allow misuse to blend into legitimate operations because the organisation cannot reliably distinguish one operator from another.
Failure mechanism: The access model reuses a common account or session path without preserving identity mapping, so logs show activity but not a defensible human owner. That undermines auditability and makes privileged or sensitive actions difficult to attribute after the event.
Impact: Organisations may be unable to assign responsibility, validate approvals, or prove who performed a sensitive action. That can delay containment, weaken disciplinary action, and create compliance exposure where traceable access is expected.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication, and Access Control | Shared access hinges on preserving accountable identity and access boundaries. |
| DE.CM-8 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Session logging and review are needed to detect untraceable or inappropriate use. | |
| Recommendation — Enforce unique identity attribution before allowing shared workstation use. Monitor shared sessions so each action remains reviewable to a named operator. | ||
| CIS Controls v8 | 6.8 — Unsuccessful Login Attempts and Audit Logging | Audit trails are central when shared accounts must still be attributable. |
| 5.1 — Establish and Maintain an Inventory of Accounts | Shared access becomes harder to govern when account ownership is unclear or pooled. | |
| Recommendation — Retain detailed logs that support post-incident attribution and review. Track every shared or approved account with a clear owner and purpose. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Shared credentials or identities need explicit ownership to remain governable. |
| Recommendation — Assign a accountable owner to every shared access path and credential. | ||
Practitioner Guidance
What to prioritise: Preserve attribution before you optimise convenience. If the workstation or remote session cannot name the operator at the point of use, the control objective has not been met, even if the system is technically functional.
What to verify: Confirm that every shared-access workflow still leaves behind evidence that can answer three questions: who initiated the session, who authorised it, and what actions were taken. If review relies on verbal confirmation or informal team knowledge, it is too weak for accountability.
What good looks like: The organisation can reconstruct a complete session history from approved identity, access approval, and immutable logs without depending on guesswork. The shared workstation is then a convenience layer, not a blind spot.
Practitioner takeaway: Shared access is only defensible when attribution survives the sharing model; once the organisation loses that chain of evidence, it has also lost the ability to own the actions taken through it.
Related resources from NHI Mgmt Group
- Who is accountable when a user can sign in but still cannot access the required API?
- Who is accountable when a shared device still contains the prior user's access?
- What breaks when security teams cannot map AI chat sessions back to individual user identities?
- How should security teams run access reviews for non-human identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
