How can IAM teams improve accountability on shared kiosks and workstations?

Why shared kiosks need identity-bound accountability, not just device trust

Shared kiosks and workstations break the easy assumption that “the device equals the user.” In a communal environment, the hardware can be healthy, approved, and heavily controlled while the real accountability problem remains unresolved: who actually performed the action. That means IAM must preserve evidence at the point of action, not just at sign-in.

The practical distinction is between access and attribution. A shared account may be enough to unlock the session, but it is not enough to defend a refund, override, or records lookup after the fact. Accountability depends on tying high-risk actions to a verified worker, a controlled session, and a reviewable event trail.

This is why shared-device environments often need step-up verification, re-authentication for sensitive actions, or supervised session handoff. The control objective is not to eliminate shared hardware, but to prevent the audit trail from collapsing into “someone on that kiosk did it.”

What session evidence should capture on communal endpoints

Good session evidence answers three questions: who, when, and under what authority. For communal endpoints, that usually means preserving the worker’s verified identity, the session start and end, the action taken, and enough context to distinguish one operator from another even if they used the same workstation.

That evidence can come from linked authentication events, badge or workforce verification, session binding, re-authentication prompts, or supervisory approval flows. The important point is that the record must survive normal operational churn, such as shift changes, roaming staff, or a device that serves many users each day.

Teams should treat the audit trail as a control, not a reporting artifact. If the only durable record is the kiosk’s shared account, the system may be usable but not accountable. If the record binds the person to the action, the kiosk becomes supportable even in regulated or dispute-prone workflows.

How IAM teams should design for shared-device accountability

The best design is usually layered. Start with worker-level verification at session entry, then require stronger proof before privileged or irreversible actions, and finally make sure the action log keeps the user-session-action chain intact. On highly sensitive tasks, the device should be the least trusted element in the chain.

That design often pairs well with identity governance and least-privilege access. Shared workstations should not become a shortcut for broad standing access, because the more authority carried by the session, the more important it is to prove who exercised it. A shared device can be acceptable; a shared privilege model usually is not.

For teams building this into operating practice, NHIMG’s NHI Ownership and Accountability Guide is useful because the same accountability principle applies wherever a session or identity can act without clear ownership. The broader lifecycle view is reinforced in the NHI Lifecycle Management Guide, which treats ownership, visibility, and governance as part of the control surface rather than an afterthought.

Risk and Threat Considerations

Shared kiosks create an attribution gap that attackers and insiders can exploit, especially where approvals, refunds, overrides, or records access are high value. If the environment cannot prove who performed the action, it becomes easier to deny abuse, harder to investigate anomalies, and more likely that unauthorized use blends into normal operations.

Failure mechanism: The system authenticates the device or shared account, but not the individual performing the high-risk action, so the audit trail loses person-level evidence.

Impact: Investigations become inconclusive, disputes are harder to resolve, and excessive access on a communal endpoint can be abused without a defensible record of responsibility.

Practitioner Guidance

What to verify: Before trusting a kiosk control, confirm that the log can link each sensitive action to a unique worker identity, not just to a workstation or shared login. If the action cannot be attributed after the fact, treat the control as incomplete for accountability purposes.

Decision rule: If the action can change money, access, records, or other material state, require a stronger identity check at the moment of action than you require for casual use of the device. If the process cannot support that distinction, narrow what the kiosk is allowed to do.

Practitioner takeaway: Shared hardware is acceptable only when the accountability model stays person-specific; once the audit trail stops at the device, the control has failed where it matters most.

Related resources from NHI Mgmt Group

• Why do HR and IAM teams need shared accountability for lifecycle automation?
• Why does shared accountability improve cyber resilience in organisations with many technical teams?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?