How do organisations make shared-device actions attributable to one person?

How shared-device attribution actually works

Attribution depends on separating the person from the device. The device can be shared, but the account, session and audit trail must not be. The practical control is to make the activity start after an individual identity is confirmed, then preserve that identity through the session so later actions can be tied back to one named user rather than to a generic workstation.

That means the organisation needs a consistent identity event at the start of use, plus a session boundary that is clearly owned by one person. If two people can act through the same login, attribution becomes weak even if the workstation is physically controlled.

Shared-device designs work best when the identity layer is explicit, not implied. The user should authenticate, the session should be bound to that user, and the system should record enough context to show who acted, when they acted, and from which device or terminal the action came.

Controls that make the audit trail defensible

The strongest pattern is individual sign-in for every person, combined with a session start that records the user identity and the device context. For frontline and kiosk-style environments, that can be implemented with badge tap, SSO, passwordless sign-in, or session switching, as long as each transition creates a clear ownership change in the record. NHIMG’s Passwordless for Frontline and Shared Devices Guide covers the common sign-in patterns used in those environments.

Where shared workstations are part of a broader kiosk or managed-device estate, the audit problem is not only authentication but also session clearing, account separation and post-use reset. A device can be reused safely only if the previous user’s state does not bleed into the next user’s activity trail. The Kiosk and Shared Device Security Guide is the best internal reference for those device-side controls.

When organisations still rely on team accounts or shared sign-in paths, they should treat attribution as a governance problem, not a convenience feature. Shared accounts obscure who performed the action, so the compensating control must be stronger session logging, tighter approval rules, and removal of unnecessary shared logins. NHIMG’s Shared and Generic Accounts Governance Guide explains why this becomes a control issue as soon as a shared identity can reach production data or systems.

Why shared-device attribution fails in practice

Attribution breaks when the organisation assumes the device is the control boundary. In reality, a shared terminal is only useful for accountability if the session boundary is stronger than the hardware boundary. If users can stay signed in, hand off a session informally, or reuse cached credentials, the audit log may show a device event without proving which person performed the action.

The failure mode is usually a mismatch between physical access and logical accountability. Two users can sit at the same device, but if the system cannot prove a unique identity for each action, the trail is only partly trustworthy. That is why identity proof at login, session timeout, explicit sign-out and per-user event logging matter more than the workstation itself.

Shared-device environments also become fragile when the sign-in method is convenient but not individualised. A generic PIN, a universal kiosk password or an untracked handoff may keep the line moving, but it weakens non-repudiation and makes later investigations harder. The more users share the device, the more important it is that the audit trail preserves user separation automatically rather than relying on manual discipline.

Risk and Threat Considerations

Shared-device environments create a real attribution risk because the easiest operational shortcuts are also the ones that blur accountability. If a workstation can be used without a clear personal sign-in and clean session handoff, the organisation may lose the ability to prove who performed a sensitive action, which can affect investigations, fraud review, disciplinary action and incident response.

Failure mechanism: The control fails when the shared device authenticates the workstation or group, but not the individual user, or when the session is reused, cached or handed off without a new identity event. In that case, the audit trail records activity on a terminal, but not trustworthy person-level attribution.

Impact: Investigators may be unable to separate legitimate activity from misuse, and attackers or careless insiders can exploit the ambiguity by acting through a shared session or by denying authorship later. That weakens detection, weakens accountability and can make high-value actions effectively unattributable.

Practitioner Guidance

What to verify: Confirm that every shared-device action produces a person-specific login record, not just a device record. The evidence should show the user, device, timestamp and session boundary, and it should be possible to distinguish one user’s actions from the next user’s without manual reconstruction.

What good looks like: A new user cannot inherit an old session, and every sensitive action can be traced to a named identity through the full audit chain. If that is not true, the design is still operating like a shared account, even if the hardware is locked down.

Practitioner takeaway: Treat shared devices as a session management problem, not a hardware problem, and only trust attribution when the identity boundary is stronger than the physical device boundary.

Related resources from NHI Mgmt Group

• What is the difference between using one metaverse person object per connected directory and using a shared object model for multiple exports?
• What breaks when frontline IAM still assumes one person and one device?
• Who is accountable when a shared clinical device exposes patient data?
• Why do shared workstations make CJIS access control harder?