How should shared-device environments handle identity verification at login?

Why shared-device login needs fresh verification every time

Shared-device access is only safe when the environment treats every sign-in as a new trust decision. The device may be common, but the account session should belong to one verified person at a time, with no assumption that the previous user’s identity still applies. That means the login process must establish both who is present and whether this device is fit for that session.

That is why shared-device design usually pairs strong authentication with device posture checks. If the sign-in is on an unmanaged, rooted, or otherwise risky endpoint, the system should be able to force additional verification or deny the session rather than inheriting a prior trust state.

What the session should bind to after login

After identity is established, the session should be bound to the specific user account, not to the shared browser state, cached credential, or device-local profile. On shared endpoints, the practical goal is to make the session portable only within the verified user’s own authorization boundary, then end cleanly when that person leaves.

That binding is what prevents one person from inheriting another person’s open application, approved transaction, or authenticated browser session. The control is not just authentication at the front door, it is also containment after entry, so the authenticated user cannot ride on stale state left behind by someone else.

For shared-device programs, the safest pattern is to minimise local persistence entirely. Short-lived sessions, automatic sign-out, and profile isolation all reduce the chance that a later user can reuse residual access or that a stolen device can expose active sessions.

Controls that keep shared access from becoming shared compromise

The login flow should be designed around friction where risk is higher and simplicity where it is not. Use MFA as the baseline, then add step-up checks for unusual location, new device posture, impossible travel, or other risky sign-in signals. In practice, that means the system can still be usable for frontline or kiosk scenarios without making every session equally permissive.

Shared-device security also depends on removing the easy failure modes that create cross-user access. Avoid cached passwords, shared browser profiles, and reusable local accounts, because each of those can collapse the separation between one verified person and the next. Where the environment needs account switching, the sign-out and cleanup path must be as reliable as the sign-in path.

NHIMG’s Kiosk and Shared Device Security Guide goes deeper on locking down shared endpoints, session clearing, and platform-specific shared-device modes.

Risk and Threat Considerations

Shared-device environments are vulnerable when authentication proves a person once but the device continues to behave as if that proof still applies to the next person. Residual browser state, shared accounts, and weak sign-out handling can turn normal workstation reuse into account takeover, data exposure, or unauthorised action by the wrong user.

Failure mechanism: The system leaves behind authenticated session material, reusable credentials, or local account state that a later user can inherit, so the device stops distinguishing one person from the next.

Impact: The wrong person may access applications, records, or approvals under another user’s identity, and compromise of the endpoint can expose multiple users instead of one.

Practitioner Guidance

What to verify: Confirm that the login flow is enforcing fresh authentication for each user, that session teardown is complete on sign-out or inactivity, and that no local profile or browser state survives across users in a way that preserves access.

Decision rule: If the device is shared by shift workers, kiosk users, or front-line staff, prefer short sessions and automatic reset over convenience features that retain state. If the environment cannot reliably clear state, treat the device as unsuitable for persistent authenticated access.

Practitioner takeaway: The key design choice is not just stronger login, it is eliminating anything that allows one person’s verified session to outlive that person’s presence on the device.

Related resources from NHI Mgmt Group

• Identity verification
• How should security teams handle identity verification on shared devices in frontline environments?
• How should security teams handle identity verification during login for regulated applications?
• How should security teams handle identity verification when trust changes after login?