When should organisations prioritise individual user accounts over shared kiosk logins?

When separate identities matter more than convenience

Prioritise individual accounts whenever the kiosk is being used for work that creates a record, changes a record, or could trigger an incident review. The more the kiosk touches regulated data, customer-impacting actions, or admin-like functions, the less defensible a shared login becomes. A single shared account may be simpler at the counter, but it breaks the link between a person and the action.

That distinction matters because attribution is not just an audit preference, it is part of how organisations decide who approved a change, who viewed a record, and who should answer for misuse. If two or more people can act under the same identity, the organisation may still know what the kiosk did, but not who did it.

Where shared logins are still used, the practical question is whether the workflow can tolerate that loss of accountability. For low-risk, low-consequence lookups, a shared kiosk may be acceptable. For sensitive records, exception handling, or anything that could require later investigation, separate identities should be the default.

Why shared kiosk logins become a security and governance problem

Shared logins weaken accountability, but they also weaken containment. If a password, token, or session is reused by multiple people, compromise of that one credential can expose every action that identity can perform. That is why shared access is often acceptable only when the business can also accept weaker traceability and a larger blast radius.

Operationally, shared logins create grey areas around responsibility. Shift changes, contractors, temporary staff, and cross-department use all make it harder to prove who initiated an action and whether the action was appropriate. That can slow investigations, complicate disciplinary review, and make access reviews less meaningful because the account does not represent one person.

For a broader treatment of the boundary between human and machine-style access, Human vs Non-Human Identity is useful because the same lifecycle and governance questions often appear when access is shared, delegated, or reused across multiple actors. In practice, the same governance failure can show up in a kiosk, a service account, or a support workflow.

Shared access also increases the chance that weak local habits become systemic. If staff begin writing down kiosk passwords, reusing them in adjacent systems, or treating the account as a convenience account, the security model shifts from controlled access to informal access. The issue is not only whether the kiosk is locked down, but whether the identity model still supports review, revocation, and accountability.

How to decide when individual accounts should replace shared access

Use individual accounts first when any of the following are true: the action must be attributable to a person, the kiosk can touch sensitive records, the workflow crosses shifts or departments, or the action could be material in an investigation. That decision is strongest when the kiosk is not just a terminal but a point of access to customer, patient, financial, or operational data.

The best practical test is whether you would be comfortable answering three questions after an incident: who did it, what did they access, and whether they should have been allowed to do it. If the answer to any of those depends on guesswork, shared credentials are the wrong default.

When organisations need a concrete policy baseline for account governance and least privilege, the account-management perspective in Top 10 NHI Issues and the lifecycle focus in NHI Lifecycle Management Guide help frame why reusable identities create governance debt. The lesson transfers cleanly to kiosks, even when the users are human, because the same control weakness is the inability to tie access back to one accountable subject.

When teams must keep a shared kiosk for usability reasons, make the exception explicit rather than accidental. That usually means limiting what the kiosk can reach, shortening session lifetimes, logging every action that matters, and keeping the number of people who can use the account as small as possible. Shared access should be a conscious exception, not the system design.

Risk and Threat Considerations

Shared kiosk logins create a straightforward exposure: one credential can serve many people, so misuse or compromise is harder to detect and harder to attribute. That becomes more serious when the account can view sensitive data or perform actions with operational consequences, because the organisation loses both accountability and a clean investigation trail.

Failure mechanism: A shared identity collapses individual responsibility into one reusable session or password, which makes insider misuse, opportunistic abuse, and post-compromise review much harder to separate by person.

Impact: Investigations become slower, access decisions become less defensible, and a single exposed credential can create broader access than the business intended.

Practitioner Guidance

What to verify: Confirm whether the kiosk account can reach records, systems, or actions that would matter in an audit or incident review. If yes, treat individual attribution as a control requirement, not a usability preference.

Decision rule: If the workflow can affect sensitive data, approvals, or customer impact, use named accounts even if the sign-in process becomes more cumbersome. If the kiosk is only for low-consequence, low-traceability tasks, shared access may be acceptable with tight limits.

Practitioner takeaway: The point of separate identities is not elegance, it is accountability. If you cannot reliably answer who did what, the kiosk model is already too permissive for the work being done.

Related resources from NHI Mgmt Group

• Should organisations prioritise GMSAs over user-managed service accounts?
• When do service accounts become a higher risk than ordinary user accounts?
• Should organisations prioritise external exposure or internal credential governance first?
• When should organisations prioritise workload identity controls over more user-focused IAM work?